Re: [MLS] confirming cipher suites decisions

"Hale, Britta (CIV)" <britta.hale@nps.edu> Fri, 28 February 2020 07:31 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 918EB3A121E for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 23:31:09 -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 It-FpSWGa_1N for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 23:31:07 -0800 (PST)
Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6E93A121D for <mls@ietf.org>; Thu, 27 Feb 2020 23:31:07 -0800 (PST)
X-ASG-Debug-ID: 1582875066-0e39454964ced50001-bGA3T6
Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id BjCrZYP6ezBWlGDp; Thu, 27 Feb 2020 23:31:06 -0800 (PST)
X-Barracuda-Envelope-From: britta.hale@nps.edu
Received: from synergos.ern.nps.edu (172.20.4.116) 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 23:31:06 -0800
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.49) by synergos.ern.nps.edu (172.20.4.116) 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 23:31:06 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eN4QhZY8JRYq0yYMHNFKK7g0um6Quns3jXLbODpBmmVkX4ONqVq35jAA/7DnWvHH28Pax53iT0c/kpGvbMQh3R1gBlCppO3TTcKckEjCnd6yKxBCtJQEDJF7lu1tKwz+vZOjmhEKa4xYD0x08uRkuMgHjQxCV05MeaAJu2OKLzKzxcrsF8l+FSxJ+g4mci9vQ+sRUj9Aj0ePisaylfroW/yJDIT/HAKLFa4urgy1Ekbjd0d9GLEF2rHVD1gwZdX2Qh7T52y7+JcJZNkqxWFBNpYKH6qDgXbJP2CDyYU8cdyBvve3EljjYPy3HRsb65D6BahrKF373S3BcyCLMUsTww==
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=p9XoyVyu129lxo6SgTAs5pj9fCB+ceJAt8aBFC8BSuk=; b=JGjvUCkE4sjugnjWnTIm05FF/SlwdJNFHSsuUchTPrJFiAL6nmIeS7XH8wqn+3KDX6KgImKx/yuUvEEQSufuoRBEVubFYo4JoFyo9Qy9cQzYJ40fzkeOF8IjB/la4xw4XDXqloTV68iTMbzkQTnLojlNlJHGG5LBQz6fPZoULztXBb5kEsjxjIe2P1cOiV6kz0PUhrSVlOBlKhd2FRSJNkZBtuD7QAF9PsjyaBVpUxlPD6I2Ca2BOVOvoBZT1RnAmnOG7e3UrT+qz8ai8Q2RQx3YovZ5KhDiqKojhBAVXO2a+QxR52pYL8GKsdaW6BvnIWyVjH0aUYUYFYhWLwkyMA==
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 BY5PR13MB3586.namprd13.prod.outlook.com (2603:10b6:a03:1ae::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.5; Fri, 28 Feb 2020 07:31:04 +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; Fri, 28 Feb 2020 07:31:04 +0000
X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:1ae::22]
X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:1ae::22
From: "Hale, Britta (CIV)" <britta.hale@nps.edu>
To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, Raphael Robert <raphael@wire.com>
CC: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, Cas Cremers <cas.cremers@gmail.com>, 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//+LDgCAAO4egIAAxxUA//+SO4AAAFFngA==
Date: Fri, 28 Feb 2020 07:31:04 +0000
Message-ID: <9DD8A71E-B8A8-4141-810B-BCE5F8DDDED3@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> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <CDA0769B-1C9A-42E3-A720-B869E20A8EA0@wire.com> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu>
In-Reply-To: <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu>
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: [88.203.39.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9f015fab-d17b-47f2-bde2-08d7bc202b5f
x-ms-traffictypediagnostic: BY5PR13MB3586:
x-microsoft-antispam-prvs: <BY5PR13MB3586B3CBFCB1541356908265FBE80@BY5PR13MB3586.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0327618309
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39850400004)(376002)(396003)(346002)(366004)(199004)(189003)(6512007)(26005)(81156014)(6506007)(53546011)(81166006)(64756008)(75432002)(66446008)(66476007)(8936002)(66556008)(71200400001)(91956017)(76116006)(8676002)(86362001)(186003)(66946007)(2906002)(33656002)(4326008)(478600001)(5660300002)(36756003)(6486002)(54906003)(110136005)(316002)(786003)(2616005)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3586; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: oAQLzHx8Qewi/TEB7ko5DaMeu3oyreMHf7a1lxpmTyGnPK/mUDkZc0ZIvLclwFzDR/bM/GOzU8TPftjlBKbvZ6jof2w4sq+WDtu5q64LbHBNBnzVULLdigyNLQETzN9VU2xIiqtMxWPh+KZix5rtBC+v3eVfU0mto/wqRW+gm6IsvnV2FAgmTHgu1c3zR2GMavkjGCleopISYowwGAFKAlOE8aRA+gBGhYKVMFbJCE2Jv9cPeyXv6NzGGEqCxmPrKx0iJ228cmfhQkc9VJ51qENk4kcdlOAPKs+T9INuVmN8zw5pflK61Z0breea2j0leZ8yC4HFAwGVb43uxG5XSE75EqjRGrGQ8FTIPVOjPBndXFJikWu0ngZTXSHfNFmXRA3M008RgoOGpnB/8QOJRLg8MJvb7ySDOkDScdI1EhuzV8l/4LuxBrUAH4u+id3pOXaVGXQ0tW121+xZr+ZPBUy0jbkM5T0xIzNBUhhhu3vxseaoRzyWOyut2PIuchH72qvkGjK4QYfNSZomBUq80A==
x-ms-exchange-antispam-messagedata: 7IHqW7PXF8hx0owDR/wO7J1md/n/amj2HLAqfcdhV0eCOIR01gGwbXFwNaclstJavCrWVYYtIm4uzjxW+eYNTbwz3qZmyhbISHFvxPVyI+LRNLCDQTaflFEVedJLq9WAbiLdWEWh1SPHxdAb2stDVw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_9DD8A71EB8A84141810BBCE5F8DDDED3npsedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f015fab-d17b-47f2-bde2-08d7bc202b5f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 07:31:04.7825 (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: lTAXuSCYhW6Jpj787s9sind/femYhUyBS5/eVO9nAeoWelQY9SJRRYeKL1PWXDME6xC4LSBobH9Ws2zEYUtfDA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3586
X-OriginatorOrg: nps.edu
X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117]
X-Barracuda-Start-Time: 1582875066
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: 39322
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.80314 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/6uT8JWQ4zl-q81bPeZX01DqhGQc>
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: Fri, 28 Feb 2020 07:31:10 -0000

There is arguably a third “case”, which may be where most of the practicality questions are arising from:


  1.  The group creator wants more control of the security of the signature scheme only.

     *   The group creator chooses the MTI ciphersuite.
     *   The group creator chooses a subset of initial group members’ supported algorithms (which may or may not include the MTI).
Again, for the sake of argument, consider the following alternative to b:

     *   The group creator chooses a single non-MTI signature scheme.

Here, the ciphersuite choice and signature scheme choice are not comparable: 3a indicates that we want full flexibility, while 3b/3c indicate more focus on security - not that the MTI is less secure, but that the group creator wants a non-MTI scheme for some particular reason. Otherwise this would reduce to case 1).

That point aside, in case 3) a newcomer would be able to join based on ciphersuite alone. Then the real debate is then on the probability of the newcomer supporting a single non-MTI scheme versus a set of schemes. I am not sure that this is a point worth focusing on, as it is clearly a special case of 2) in terms of the intent and motivation of the group creator (i.e. if the group creator is more focused on the security and other aspects than allowing anyone to join, then issues in 3) seem largely to be a moot point).

Britta



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

In terms of negotiation, I think we can closely correlate the issues and practical ramifications in choosing a signature scheme list with the ciphersuite negotiation that already takes place.
Let us assume that every member would not only have a list of supported ciphersuites in their CIK, but also of signature schemes. The action of the group creator is then comparable in the following a/b cases for ciphersuites/signature schemes:


  1.  The group creator wants to ensure any newcomer can join the group:
     *   The group creator chooses the MTI ciphersuite.
     *   The group creator chooses the MTI as the single element in the set of possible signatures.



  1.  The group creator wants more control and is not particularly concerned about newcomers in the long-term:
     *   The group creator chooses a non-MTI ciphersuite from the initial group members’ lists.
     *   The group creator chooses a subset of initial group members’ supported algorithms (which may or may not include the MTI).
For the sake of argument, consider the following alternative to b:

     *   The group creator chooses a single non-MTI signature scheme.

The issues for newcomers in case 2b is not very different from 2c (which is ultimately the case if we only support one scheme). Basically, the newcomer supports the scheme/set of schemes or he does not. In 2a, 2b, and 2c, algorithms are dictated by the set of initial members, so we are not looking at a significant usability difference there.

For choosing the signature scheme list, any proper subset of the intersection of the initial group members’ list would be possible (hence why we have freedom to choose {MTI} in case 1b). However, we could make it simple and use the actual intersection.

As far as lists changing over time: in terms of what a member can support the answer is an affirmative. In the same way the supported ciphersuites can change over time, the supported signature schemes can as well. However, in terms of what is used in the group, this should not change: once fixed at group initiation the list is static for the lifetime of the group. Once a member has chosen a signature scheme from the list, the choice is static for the lifetime of the group. The group should thus not be adaptable to changes in the offered algorithms of the CIKs.

Britta



From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Date: Friday, February 28, 2020 at 6:55 AM
To: Raphael Robert <raphael@wire.com>
Cc: "Hale, Britta (CIV)" <britta.hale@nps.edu>du>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>fr>, Cas Cremers <cas.cremers@gmail.com>om>, ML Messaging Layer Security <mls@ietf.org>rg>, Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming cipher suites decisions

I am not sure about the practical ramifications of groups where members use different algorithms.

Still, I think it is feasible to eventually have a design where the group creator proposes a set of algorithms as “must implement” for the group.
Each new member must support (i.e. implement) “all” the algorithms in this list in order to join the group.
However, the member has the option to use whichever supported algorithm she prefers for messages she sends.

While all of this is a reasonable long-term goal, perhaps we should start with a version where the creator only chooses one algorithm in each category, leaving no choice to the members.
We can document this choice as a future extension point, and change it as we understand the federation scenario and deployment constraints a bit better?

Best,
Karthik




On 27 Feb 2020, at 19:02, Raphael Robert <raphael@wire.com<mailto:raphael@wire.com>> wrote:

I agree with what Karthik said, and I think that that was the underlying assumption all along (at east for me). The negotiation has to happen ahead of time, namely when

 - (1) an existing member proposes to add a new member, or when
 - (2) an external party proposes to add a new member.

In the current proposal with a fixed signature per group the decision taking is rather simple: If the new member advertises support for the group's ciphersuite in their CIKs, they can be added to the group.

I would like to see the decision taking fleshed out for the alternative approach that supports multiple signatures.
We need to make sure that members can verify signatures, which means we need a list of acceptable signature algorithms that every member agrees upon before a new member is added. Signature algorithms can be advertised in another extension in CIKs, but it is not entirely clear to me how clients agree on what the list of acceptable signatures is. Would it be the lowest common denominator, meaning the intersection of the algorithms advertised in the CIKs? If so, it means the list gets largely determined by the early joiners. Also, can the list change over time? That would be contrary to the idea that all negotiations should happen ahead of time.
There might an easy solution here, I just don’t see it right now.

Raphael



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

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<mailto:benjamin.beurdouche@inria.fr>>
Date: Thursday, February 27, 2020 at 11:48 AM
To: "Hale, Britta (CIV)" <britta.hale@nps.edu<mailto:britta.hale@nps.edu>>
Cc: Cas Cremers <cas.cremers@gmail.com<mailto:cas.cremers@gmail.com>>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr<mailto:karthikeyan.bhargavan@inria.fr>>, ML Messaging Layer Security <mls@ietf.org<mailto:mls@ietf.org>>, Konrad Kohbrok <konrad.kohbrok@datashrine.de<mailto: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.




_______________________________________________
MLS mailing list
MLS@ietf.org<mailto:MLS@ietf.org>
https://www.ietf.org/mailman/listinfo/mls