Re: [MLS] confirming cipher suites decisions

Jon Millican <jmillican@fb.com> Fri, 28 February 2020 19:51 UTC

Return-Path: <prvs=0327795aaf=jmillican@fb.com>
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 CEF033A1CD5 for <mls@ietfa.amsl.com>; Fri, 28 Feb 2020 11:51:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=HpR1G0cV; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IccEedQK
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 W4hPU12wiE2O for <mls@ietfa.amsl.com>; Fri, 28 Feb 2020 11:51:03 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5A43A1CD1 for <mls@ietf.org>; Fri, 28 Feb 2020 11:51:03 -0800 (PST)
Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01SJdIwi023639; Fri, 28 Feb 2020 11:50:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=resszYaENdT8llZB8JHanZLQLGFVu9oINygyRVJovck=; b=HpR1G0cVOcEeWhYYIkbLO4VHaYUo7niJQc7tnSNIG5i6hW1FpKTbjXbj0s6ZsmrQxwZZ wyhcykjNa7Ijb/7Cz+5kQFFrRYe8IB7+iPvrHPE/ZMGGVcqMMK+r0nty5zHc/NeXj7/Q PQ90ne5DtBu3aCGidWRvlyp7AYV/jZIcmFI=
Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2yepurw74x-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 28 Feb 2020 11:50:49 -0800
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 28 Feb 2020 11:50:30 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ga+WgJmXZ07903/MvRtbeI1066XQVLngJZJajf95LKO4Yxz/plC3Wxo7F0eVWyAAKara60J6fplj65f/hskg5DsJmzGlH681Vk++qCUFLbFeWrvCq5Ddt5UCVlV96ntKKR60PtBnVLnuUEK85271goX0k99o59xwbBBsQDgR3+aJ2I6Yjj1GsdORWp6U0heNWpeSBTG0YHR/DUfm65qhef618VpQlt8WsAfzsk+tpIzagvwJBuuFiQ+i57xmo05zr8HURL5OsZ6CCYGyBya05MowE4xOn7HY/egFFrxyZ2jdTnJDy3duXfIEYmzPndMypxTjetaM6KTkO1PDxRt+HQ==
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=resszYaENdT8llZB8JHanZLQLGFVu9oINygyRVJovck=; b=QwxykJC2/fx1Ddtl756Gn044MZkVMgwVv31CEy2BrVXGKOK8EGtgwz+u1/mhjVa0oIRXGSTo/xPh7VqNKQDQpZw/BdUECNha9KRqHQ/bjgtbOmpH6d1vfWuoctZIFq+opRyyOLe/nFRldgall2qL97gfYAgl9aFUY9fhd7mY6h29fNUjsE8xhIEbuac1IsvVxONbT9FL+YRkofX7ymscrpbpdFOr6k/VktQycDHuxVVPsttXANjR4/u6GyMddp+171BWlaGOVPbTTj5nwdsh/7SHJX7fN5sJsEaMcMwaMc2r0S1gOpw6dudDE4yYpfc4u1VZbbcwGPJ1qL2M2Oe+aQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=resszYaENdT8llZB8JHanZLQLGFVu9oINygyRVJovck=; b=IccEedQKptPg6UhgwwzAJnF0C0Os2LTTKwmga/+cml4ox0MCW+mDj25yCb/2LombheclZlzVBivEJ8LX2noYELor2AmQgpAysSRzzpGmsEQ4soUh5+aGregxYpgiqAuB6t+IgxQbMByyqdq3YEzFwBiWy7fNqoU8d6F8gF0Vaa4=
Received: from MWHPR15MB1152.namprd15.prod.outlook.com (2603:10b6:320:25::16) by MWHPR15MB1885.namprd15.prod.outlook.com (2603:10b6:301:4d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 28 Feb 2020 19:50:29 +0000
Received: from MWHPR15MB1152.namprd15.prod.outlook.com ([fe80::8447:952e:7aac:9fbd]) by MWHPR15MB1152.namprd15.prod.outlook.com ([fe80::8447:952e:7aac:9fbd%9]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 19:50:29 +0000
From: Jon Millican <jmillican@fb.com>
To: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>, "Hale, Britta (CIV)" <britta.hale@nps.edu>
CC: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, Cas Cremers <cas.cremers@gmail.com>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, ML Messaging Layer Security <mls@ietf.org>, Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
Thread-Topic: [MLS] confirming cipher suites decisions
Thread-Index: AQHV3QeoYov+2cXGtE2YuKiX5RJmUqgXwNwAgAmxT4CAAKn3gIAKMAGAgAALVYCAAXH8AIAAIHiAgAAGsoCAAA3FAIAA4SKAgAAPLQCAAA3EAIAAAGcAgAARK4CAAGgAgIAAxxYAgAAYWACAAEasgIAADBgAgABhFoD//5crAA==
Date: Fri, 28 Feb 2020 19:50:29 +0000
Message-ID: <109AB2E0-6BD3-4ADD-8A94-6FEF9AEF9C48@fb.com>
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> <F8067DB9-439A-47DE-BBC9-D87432E4EC73@wire.com> <BY5PR13MB3013D301CA5B74E09673705CFBE80@BY5PR13MB3013.namprd13.prod.outlook.com> <AA2AA705-A7A9-4AF2-ABB9-5EE8217760E9@wire.com>
In-Reply-To: <AA2AA705-A7A9-4AF2-ABB9-5EE8217760E9@wire.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:500::5:c521]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 60ee3a4c-5110-42c7-f992-08d7bc87769c
x-ms-traffictypediagnostic: MWHPR15MB1885:
x-microsoft-antispam-prvs: <MWHPR15MB18856B9D8038A32F888EAA34DAE80@MWHPR15MB1885.namprd15.prod.outlook.com>
x-fb-source: Internal
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0327618309
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39860400002)(136003)(189003)(199004)(81166006)(478600001)(186003)(66946007)(8676002)(66476007)(66556008)(81156014)(2616005)(76116006)(110136005)(71200400001)(86362001)(53546011)(4326008)(6506007)(54906003)(45080400002)(36756003)(316002)(33656002)(966005)(8936002)(5660300002)(6512007)(64756008)(2906002)(6486002)(66446008)(30864003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1885; H:MWHPR15MB1152.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: c4+hMwurHqGa79HreszEI6snsT7ZbnuUFJNUAmXo+nYTelKSZVQMOQz+JxsX7apgmPZmCtm5PD9AcZdEjhT9o9P7AcZCaKlLfOigq9NBotDvy2KnNnpbl72g1W1/vxaeOjutwNVayxnKkjvMogR4454d79s5lOZ20o6OyuGnJE431Ga0WVGlrO/aVh5uswUssFuT63zYgXq7tIjuxR4NyczF4n8RYzJY09E5pobHOBF4NCb9ROk1sXb8pPJyyPeXmXzZI9+jdSNhIaRPRbac4HF8R+8RDtLQHwlXuwZmDq2du+kioDm3z3DHZ7dKkwRwj8nmRvv4qkc6dy3cxfDRfEpB7RRWfY2dWaju+nkKXXU/Ap0f/F7GDtgTPl00J6fNhtuaIcQEOzz5bzc/LtClVW+wPX7IIQEDEsJM+kAfWAKH786D661OmTzpHGzkRB+aydEXXLByCQq2n9PntXs28kVNprKSWGQ6VZ1FZeoE78gqxQRvahAnig+hTLbj9FNBImQusqcKNpSseSrG/QCd+w==
x-ms-exchange-antispam-messagedata: ehLHpS83zqwzt63n7w56Z3Ml7s6FTP2EycqGFWI61ucJUzW9SgS1LRe2no9tMTEPfVEPmkjwzXhSZJKU5YMsj2HSY/J/X7YmCex1UE62p+a0bCMYW3atokGPRkqbiwkjzDfZTCZVyah7WqIQ2XzVb3YQWmAW7o4B7eIndDt2tv1XDP3gyFSTeAjD2cDYQlIA
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_109AB2E06BD34ADD8A946FEF9AEF9C48fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 60ee3a4c-5110-42c7-f992-08d7bc87769c
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 19:50:29.1321 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mRGuwnb5Jbk2QJSkVhlvMnDdmGqgpPePpOsx2UbjG4CxASYg7euw9xfIJvae2MgB5LDzM+BcwHCUkvhZqO4aXA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1885
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_07:2020-02-28, 2020-02-28 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 adultscore=0 spamscore=0 impostorscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002280139
X-FB-Internal: deliver
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/7ol5264pke0WlEOUBFojCOAMy7Q>
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 19:51:08 -0000

Hi all,

I’m just catching up on this discussion. From my perspective I don’t have particularly strong feelings on the choice here. I would say that, thus far, I have not encountered concerns about the lack of crypto agility in Signal – which we use very widely. For long-running conversations though, I definitely like the idea of an ability to upgrade crypto over time; as we should assume that threads can remain active for years.

To Britta’s point about nobody having yet raised performance concerns; this was actually one of my primary concerns reading through the thread. I recall reading about some experiments – I think by Google – where they improved TLS performance from by choosing cipher suites to be those which were most efficient on client devices. If we are to roll out MLS globally, to devices from high-end iPhones with good network bandwidth, 10-year old Android phones with expensive and slow connections, and also across web browsers – I can imagine that there may be situations where the performance characteristics of crypto choices meaningfully vary along various axes. In this sense, I would potentially be slightly tempted to lean towards an option where every client can use their own choice of crypto; subject to all clients in a chat actually supporting this choice (enabling deprecation for security purposes, because the most up-to-date client is able to remove support for newly-insecure options and force the whole group away from them).

However, that said, I’m conscious of the complexity of what we’re building already; and of the need for progress. Given the experience thus far with Signal, I’m also tempted to lean towards Proposal A in the name of greater simplicity. As has been mentioned multiple times, we can always iterate on this in future – and we would likely already get most of the benefits from a whole-group-upgrade mechanism.

Jon

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

I for one feel some further clarification on the context is needed, because the posts on the mailing list don’t fully reflect what we discussed extensively during the virtual interim calls and some nuances got lost.
First of all I think there was full consensus on the fact that degradation of the security of crypto primitives is something we deeply care about, because degradation jeopardizes the security properties of the group and an attacker could use it for downgrade attacks. The dissensus arose around the question on how exactly we want to address degradation.
In general, any of the crypto primitives in the ciphersuites can suffer degradation at some point. We need a sound mechanism to upgrade groups from one ciphersuite to another. Konrad announced that Britta and he are working on a proposal and I think that’s great news!
My understanding is that there is no dissensus around the fact that this mechanism is now more than ever firmly on the roadmap. Naturally such a mechanism would also allow upgrading the signature scheme if it was part of the ciphersuite.

So with that in mind we can further boil down the two choices:

Proposal A:
 - Single signature scheme as part of the ciphersuite
 - We treat the signature scheme like all other crypto primitives
 - We use the ciphersuite upgrade mechanism for all primitives, including signature schemes

Proposal B:
 - Ciphersuite + LSS
 - We treat the signature scheme as a special crypto primitive in that we allow individual members to no longer use unsafe schemes even before we upgrade the whole group’s ciphersuite
 - We use the ciphersuite upgrade mechanism for all primitives, except for the signature scheme

If memory serves well, this is how far we got in the calls.

My opinion was (and still is) that I favor Proposal A, because I wasn’t convinced we need to treat the signature scheme differently than other crypto primitives. I much more prefer to have a sound upgrade mechanism and put some pressure on the clients to abandon old and unsafe ciphersuites in general. I also think that in order to achieve ubiquitous federation we should limit choices to the minimum that is strictly necessary.

That being said, I fully acknowledge that if we look only at security, Proposal B sounds like the better choice because broken signature schemes might have less of an impact. If – given the extra context mentioned above – people feel we absolutely want this extra security potentially at the expense of interoperability I won’t stand in the way. I just wanted to make sure everyone is aware of what has been discussed previously before we resort to counting votes.

Raphael



On 28 Feb 2020, at 13:18, Hale, Britta (CIV) <britta.hale@nps.edu<mailto:britta.hale@nps.edu>> wrote:

This description provides a good, succinct outline of the two options with respect to a usability comparison. I think that we now are in a decent state of clarity regarding both how both alternatives would work in practice (thanks to Raphael) and how the security of the alternatives line up (extrapolated from the previous alternative of full signature scheme choice flexibility).
Consequently, both options appear to be well understood, so I do not believe that there is any argument there - if anyone does not understand either alternative then it can be clarified.
- We have a decent view of security concerns on this issue, as have been voiced by several people (4 strong votes for option B).
- The interop concerns are limited and mostly in the federated environment (2 strong votes for option A).
- No one has voiced efficiency concerns.
Any one of these is a decent reason too choose one alternative over another. Having an open PR is not.
We all want to make progress, have this decided, and move on. We should do it correctly. It seems ill-advised to back track and bypass where we are at in consensus.

Britta

Get Outlook for Android<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=IC1hZPTEUftui8HAPtI5Xk7tky390nMfyNkfBKdUoWY&s=mzQGmNZAmNqNy7fujd8RNJg6Gg3yu16QBTO28GA-H2U&e=>

________________________________
From: Raphael Robert <raphael@wire.com<mailto:raphael@wire.com>>
Sent: Friday, February 28, 2020 12:34:55 PM
To: Hale, Britta (CIV) <britta.hale@nps.edu<mailto:britta.hale@nps.edu>>
Cc: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr<mailto:karthikeyan.bhargavan@inria.fr>>; Benjamin Beurdouche <benjamin.beurdouche@inria.fr<mailto:benjamin.beurdouche@inria.fr>>; Cas Cremers <cas.cremers@gmail.com<mailto:cas.cremers@gmail.com>>; 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

If we put aside the strategic considerations for a minute, I think the two proposals boil down to the following:

Proposal A (the current one):

 - Ciphersuites contain a signature scheme
 - The group creator picks a ciphersuite upon group creation
 - The creator MUST only add members to the group that advertise the ciphersuite in their CIKs
 - The same rule applies to any AddProposal in the future
 - The ciphersuite is explicitly mentioned in the Welcome message
 - Members MUST only use the signature scheme of the ciphersuite to sign messages

Proposal B (as proposed by Britta et al.):

 - Ciphersuites do not contain a signature scheme
 - The group creator picks a ciphersuite upon group creation
 - The group creator picks a list of signature schemes (LSS)
 - The creator MUST only add members to the group that advertise the ciphersuite in their CIKs AND all elements of the LSS
 - The same rule applies to any AddProposal in the future
 - The ciphersuite AND the LSS are explicitly mentioned in the Welcome message
 - Members MUST only use the signature schemes that are part of the LSS to sign messages

In order to make progress, I would like to propose that we move forward with the current proposal simply because it is well understood and fully specified. However, we add the following two open issues to the protocol draft:

OPEN ISSUE: Security could be improved by allowing more flexibility with signatures schemes. If a signature scheme becomes insecure over time, members could be given the choice of choosing a more secure signature scheme as long at there is a guarantee that all other members are able to verify signatures under that new scheme.

OPEN ISSUE: Crypto primitives of the chosen ciphersuite could become insecure overtime and jeopardize the security of the whole group. Since TreeKEM doesn’t support mixing different DHKEM algorithms and different symmetric encryption algorithms, we need a way to upgrade an existing group to a new and more secure ciphersuite.

This would give us some more time to work on the open issues and come up with fully fleshed out proposals that we can discuss and ultimately all agree with.

Would this approach be acceptable to everyone?

Raphael



On 28 Feb 2020, at 08:21, Hale, Britta (CIV) <britta.hale@nps.edu<mailto:britta.hale@nps.edu>> wrote:

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<mailto:karthikeyan.bhargavan@inria.fr>>
Date: Friday, February 28, 2020 at 6:55 AM
To: Raphael Robert <raphael@wire.com<mailto:raphael@wire.com>>
Cc: "Hale, Britta (CIV)" <britta.hale@nps.edu<mailto:britta.hale@nps.edu>>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr<mailto:benjamin.beurdouche@inria.fr>>, Cas Cremers <cas.cremers@gmail.com<mailto:cas.cremers@gmail.com>>, 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

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=IC1hZPTEUftui8HAPtI5Xk7tky390nMfyNkfBKdUoWY&s=yrU-a-tK2oDiLTny_9Oi1GyieaIR29WHr8KrFVZMW8M&e=>