Re: [MLS] confirming cipher suites decisions

"Hale, Britta (CIV)" <britta.hale@nps.edu> Thu, 27 February 2020 11:50 UTC

Return-Path: <britta.hale@nps.edu>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B473A0A0A for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 03:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPlB0VEuqwpX for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 03:50:08 -0800 (PST)
Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 146BB3A09FD for <mls@ietf.org>; Thu, 27 Feb 2020 03:50:08 -0800 (PST)
X-ASG-Debug-ID: 1582804207-0e39454964c89d0001-bGA3T6
Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id sC7Usf8qDsyE36k6; Thu, 27 Feb 2020 03:50:07 -0800 (PST)
X-Barracuda-Envelope-From: britta.hale@nps.edu
Received: from skywalker.ern.nps.edu (172.20.4.117) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 27 Feb 2020 03:50:07 -0800
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.171) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Thu, 27 Feb 2020 03:50:06 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QjKZ5nqJmYtvkR2YmO4yPx5soJDzCa4Xma6SgT6ttY68FurFiiE9XeUbTJFMzRWFR777/uoOh9NZ5sw7oxzdu/INVx1mE4Z8vWr97OYqBqk8q55Kgu/OJvAg2juXnSVhBdMOA1z6xA3tRo97g4KpahKF/GTVvWkctyekbS2qRVy6VGz6gTyW4FuUI7M8lYNsIIu3Ci70DMkjE0XxMj7kLzWw/ZwPJXSz8eYY9MfT3LqvhdwvtSANvkM+5nSofZW3PMXBveuqJ3AgemMMtuf3/Qef+/aXBBLIBdqRwwjnZbAd/xr4hqerByhkyG78CrAMWGxOFtS6/gBXrUqQ8VMHPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xk/5uv9cXg08zpQU+5wLQ5a16aKbp9lZ7xtv/S+xxS0=; b=mYafDpXIGJvtOlZDWr87J5H9Y/ypMqmfPyLeam4TizOUz7GOBG9nrzWn1LwlrQyRHIXyVb6PLtANOnjyEEiIwxqEVETsxqNb2LrhUCixlR4KSA4I9lJsCPXnzuq58FehTWKDjU1QqZgeuUihgR/KF20ghpxO0TCZXTosn+FeVBGgRdTQ4ksqo6y/bTPYnXE8gJ5ddoL31RIy0L0pMEsJOlFHmqcO2nXRpGWogqLxrckQTkAXh6qZi5XoXvhsDaQjPH06WjWi1xpkE8JGUxF+1J3LvLD3SBYUHlNafUCJ0eLUyzrKLfAF4gCK7EDrb6Oxh5oqtN5NNEjz5FLMZjfRQw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none
Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3714.namprd13.prod.outlook.com (2603:10b6:a03:22b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.5; Thu, 27 Feb 2020 11:50:03 +0000
Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 11:50:03 +0000
X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:22b::18]
X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:22b::18
From: "Hale, Britta (CIV)" <britta.hale@nps.edu>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
CC: Cas Cremers <cas.cremers@gmail.com>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, ML Messaging Layer Security <mls@ietf.org>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Thread-Topic: [MLS] confirming cipher suites decisions
X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions
Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYCAAJPkAIAAAGYA//+LDgA=
Date: Thu, 27 Feb 2020 11:50:03 +0000
Message-ID: <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu>
References: <D107086A-ED6C-48D8-8BC3-B3AE7E424F85@sn3rd.com> <D2B8EAF9-9109-4247-B714-13306724F712@nps.edu> <B02410C5-F6C3-4580-AA92-C48687731919@nps.edu> <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <CAL02cgS813EWDm8g=_P18XHVJJJErgit4OWP7fDCMPzkQcJQQw@mail.gmail.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <A6881857-406E-45E9-BEC7-823E15633619@nps.edu> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr>
In-Reply-To: <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu;
x-originating-ip: [195.158.89.246]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e1463e04-1f00-419c-8b0e-08d7bb7b2ede
x-ms-traffictypediagnostic: BY5PR13MB3714:
x-microsoft-antispam-prvs: <BY5PR13MB37147AF73425253E1C94BA8CFBEB0@BY5PR13MB3714.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39840400004)(136003)(366004)(346002)(189003)(199004)(186003)(26005)(81166006)(6486002)(91956017)(5660300002)(2616005)(54906003)(36756003)(33656002)(76116006)(786003)(66946007)(81156014)(316002)(75432002)(64756008)(478600001)(8936002)(6916009)(4326008)(2906002)(53546011)(6512007)(86362001)(66446008)(8676002)(66556008)(71200400001)(6506007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3714; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NnQRY/N+enn8DC9wdiK/OcyzaWV0JjhhwR2x+dq6opaHLEw31uatoKsxqw5kUME9EcebVVAo7a4NqOVZD1q4dhLTthftgyUMzr/0qEuR3j6JisfZzmcuERRW4zF8HmFyLANWIIvGrgTflpa5Xv6hNqE1SsnxQ5zO0vexe4e1Jb69XR0b0MWP74lbEAkNqTW8kckqopdoskVDodqKeGyZ5nnP9GyTd0OSdLUGnl5iT6P49dC2IPBswGLqhj/W5qMGEydygSBIfDOFzvsb9s4nXBC2lR+Yc4Q8F63aWc3zc89Cpx7dee7d6kCjOUfj0YCnGyUE7ZH6vvBlLe8S2lGxZNkdc4ERrTE5p9Iiz8vvIoj8iwkF84K694ur0ovI58pwLt8q5GMeQlvm0Cskouvg7/GDjWf4ns184yAYmOyJombbn0UjSvE45SAw3IHaN7Js
x-ms-exchange-antispam-messagedata: uRn3F9EIVPO1POdmWPt3aPX9Dr5sjJZdHN38Fwve51Agvs1wFO8kyhpz7h2KYQ0i56GMGBBRg40EpH5WwA8MJLGRQS+M+T+o2ymd6dIpBoktjC6D0PtwTekUfhg0PM/c4f05EHWfi6tG8Q1uhdpFtw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_57308ED129F448D78AB9D88AC49803C5npsedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e1463e04-1f00-419c-8b0e-08d7bb7b2ede
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 11:50:03.7063 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5p1anfxqeZrLDkcwwatw624fb2WlT69pUNdEoqcjoWjfiT3Vb4uihpQDw/xPPfI9GYBFZRqPYpH/s6T1Q03cKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3714
X-OriginatorOrg: nps.edu
X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117]
X-Barracuda-Start-Time: 1582804207
X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at nps.edu
X-Barracuda-Scan-Msg-Size: 11164
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80294 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/7g9wDN2xGl4ierI0IzJCnHbz900>
Subject: Re: [MLS] confirming cipher suites decisions
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 11:50:10 -0000

Benjamin,

The point of comparison with TLS is that interop is significantly less of an issue when everyone in the group is using the same client program.

In terms of interop, your concerns become a discussion point mainly in the federation case – and that is an important case that we should plan for. But, as I said and you re-iterated, if the use case really expects interop issues from allowing choice, then nothing prevents the selection of a single scheme for the set of allowable schemes.

As to the reasons behind allowing multiple algorithms, the document on the mailinglist has already outlined several – these are security reasons for supporting individual algorithms. The interop objections fall on the usability side, so the current discussion is really about usability vs. security concerns. However, at the intersection of these two options is the idea of allowing a set of possible algorithms as Karthik suggests. This is a good compromise.

I would definitely not suggest that you consider multiple MTIs at this stage. If that is something you want, it is best to raise it as a separate issue.

---

Britta


From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Thursday, February 27, 2020 at 11:48 AM
To: "Hale, Britta (CIV)" <britta.hale@nps.edu>
Cc: Cas Cremers <cas.cremers@gmail.com>om>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>fr>, ML Messaging Layer Security <mls@ietf.org>rg>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming cipher suites decisions




On 27 Feb 2020, at 11:47, Benjamin Beurdouche <benjamin.beurdouche@inria.fr<mailto:benjamin.beurdouche@inria.fr>> wrote:

Hi Britta,


On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <britta.hale@nps.edu<mailto:britta.hale@nps.edu>> wrote:

Benjamin,

The issues you describe are primarily TLS-type problems, where uncontrolled, large-scale agility and interop issues exist.

Yes exactly, and I think two-party short lived connections for TLS are easier to handle
than will be the long-lived multi-party connections of MLS.


As has been stated in the working group as a supporting argument to many changes over the different drafts, within the messaging/MLS space we are looking at significantly more client-specific control.

Yes, and we keep being careful that it is the case when writing the drafts,
but this doesn’t mean that we should be willing to risk interoperability.


It is not unreasonable for a newcomer to support a selection of signature schemes. If the group creator really wants full interop, they can always define the set of available schemes to consist only of the MTI.

I think at reverse, if you are willing to break interop, you should be selecting something

S/should be selecting/can select/


else than the MTI when creating the group. And again, in what I say, nothing prevents
you to pick the NIST ciphersuite for compliance and use only that.
But I don’t see the interest of mixing algs and put at risk implementations and interoperability.

Out of curiosity, where you somehow arguing for multiple MTIs here ?

B.