Re: [MLS] confirming cipher suites decisions

Raphael Robert <raphael@wire.com> Thu, 27 February 2020 18:02 UTC

Return-Path: <raphael@wire.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 AF3523A0E71 for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 10:02:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com
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 DAN6dyKpnxqu for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 10:02:22 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21703A0E6D for <mls@ietf.org>; Thu, 27 Feb 2020 10:02:21 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id j7so4522844wrp.13 for <mls@ietf.org>; Thu, 27 Feb 2020 10:02:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3bJNYStzUEUN3Fow2VU7aVa0YNRH76VcjRHkwq1dFiA=; b=wb3WUvA8Qte4fBsoYcUec98RNYO7SBsqWcI5tfLtdhH9wcayYfezBP4vvvoz6iwedZ F/5Hhrvz3M7h2T3ubbjqdffzCrZxk+wzvJzzZGF8kENnIid4GfI8nXfBDEyzuiwOdWP4 10Xa4zuPfqbEcln2J47q0JY1iQFdJb05O1SuTUxFcmoPgd/IZS/jkjQobreYEYxNQ9yS gG/BpZWGr+P3zdp4I3nU8S1UpG6oRJgVV1KbTZv9MnkAgJdCqJLiL7kmmcKchI0+81uT DgZsyW8KBTAv9WIPKgkQ3UTixs0CgyyFLvqp4NFOqSWH0pOq9950t4lywalMIq5c7WAW mTYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3bJNYStzUEUN3Fow2VU7aVa0YNRH76VcjRHkwq1dFiA=; b=P7nTXW0jp2lqcJHhrR0dbfTHoOocfXkn0LpWL/lX6n5q1i29uPuCBM7AwU2G9RCkw3 gPxwHIj0sR/c7k49PkUWPOWA4meI/T/j4b2X+QPrgYWzpHJdcza9WlXcoVk0QNr3wHBT +H4GKvNTsqNFlr6sGlJz2DNnFlVKhUyct2m9keaV+qvnO6AFck2jjh4jKyj00n0uqJvY QejJQBjLvbHb6pBCpTWiEwN1YAvd/k6RFv18bku4I+e/14undZS5icCa1EM0ICK0tIAw OSkQILLe8U8I/YoC7zuRK3zzA/bi6F7pYTFRJI5qjTiRuXIkb5y44x/wvX3scrv0ix0a btfw==
X-Gm-Message-State: APjAAAVUkduBxZLiCvJhyq0vpI2WP1x60lVeqrHecUnRpTG8cYeJO9yy oepl02LDUElTzihnHfKtqWIeYw==
X-Google-Smtp-Source: APXvYqzjQg1eyc1cjUGnynI+xyvRYA41F7LJUEAsMwv5xODxNEZuBH/y0i1ggGZscgnJstmHoeKlHA==
X-Received: by 2002:a5d:4f89:: with SMTP id d9mr36360wru.391.1582826540091; Thu, 27 Feb 2020 10:02:20 -0800 (PST)
Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id b10sm8505236wrt.90.2020.02.27.10.02.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 10:02:18 -0800 (PST)
From: Raphael Robert <raphael@wire.com>
Message-Id: <CDA0769B-1C9A-42E3-A720-B869E20A8EA0@wire.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1F6FF80B-19AF-4BE4-9040-5356D48782F7"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 27 Feb 2020 19:02:17 +0100
In-Reply-To: <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu>
Cc: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, Cas Cremers <cas.cremers@gmail.com>, ML Messaging Layer Security <mls@ietf.org>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
To: "Hale, Britta (CIV)" <britta.hale@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>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/R6mWU3vhcVrmoQGYFAXFP8hSr1Y>
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 18:02:25 -0000

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> 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>
> Date: Thursday, February 27, 2020 at 11:48 AM
> To: "Hale, Britta (CIV)" <britta.hale@nps.edu>
> 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>
> 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
> https://www.ietf.org/mailman/listinfo/mls