Re: [MLS] confirming cipher suites decisions

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Thu, 27 February 2020 09:03 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 E38B53A1592 for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 01:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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=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 DHvorMuPhzOB for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 01:03:39 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 56F453A1591 for <mls@ietf.org>; Thu, 27 Feb 2020 01:03:39 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,491,1574118000"; d="scan'208,217,223";a="340571110"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 10:03:35 +0100
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EBD010A4-CD13-4383-A64B-C2BF552D3646"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 27 Feb 2020 10:03:35 +0100
In-Reply-To: <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr>
Cc: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, ML Messaging Layer Security <mls@ietf.org>
To: Cas Cremers <cas.cremers@gmail.com>, Britta Hale <britta.hale@nps.edu>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
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>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/sidyG_vQepKRfbmh9moby2itdGU>
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 09:03:42 -0000

From the last messages, I think my answer to Cas was misleading…

R1. Joining a group without supporting all the crypto is unacceptable
R2. Allowing a system where clients all advertise the MTI ciphersuite
and where the newcomers cannot join should be unacceptable.

Goal of MLS: we want everybody to be able to build a group and talk securely
to everybody else. No need for security if people can’t create groups because of
algorithm fragmentation.

> On 26 Feb 2020, at 20:37, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr <mailto:karthikeyan.bhargavan@inria.fr>> wrote:
> 
> Hello All,
> 
> I think we could go either way: multiple or single signature algorithm per group.
> However, I would prefer if we required *all* the algorithms that group members must support to be declared up-front at group creation.

This is currently the case that “that all the algorithm that group members must support
to be declared at group creation" and it is also the root cause of potential fragmentation.

If the creator takes the responsibility of explicitly picking something else than the MTI ciphersuite
they take the risk explicitly to break interop and break R2, but that is fine.

If we went for the scheme such as picking a list which contains more than the MTI, even at
group creation, *only clients supporting everything* would be allowed to join otherwise breaking R1.

To me this Is unacceptable.
That is why we want to restrict this set to a minimum: in my case to *one* ciphersuite.
The largest set the creator will pick, the more difficult it will be for new member to join the group.

> That is, my preference is not to add new signature algorithms as a group evolves and new members are added.

That was never an option.

> The rationale behind this thinking is that when a member joins a group, she can inspect the group’s parameters to decide whether she supports
> the algorithms needed to converse in the group. It would be weird if the group allowed a new member whose authentication credential or message signatures
> cannot be processed by existing members.

If the newcomer doesn’t support enough, but just the MTI, they may never join which is
unacceptable, as everyone else has to support the MTI, R2.

> And it would be hard to try to dynamically detect the algorithms that the group members support.
> Instead, declaring all *required* algorithms at group creation seems like a sane choice to me.

So again, requiring to support more, is not only a dangerous idea regarding implementations,
but is dangerous for interoperability and fragmentation.

Moreover this new proposal is not solving any of the current problems I have with the multiple
algorithms approach I had in my previous message:
-----

1. agility causes a lot of problems: I don’t think I need to remind people of the TLS story https://hal.inria.fr/hal-01114250 <https://hal.inria.fr/hal-01114250>

2. interop fragmentation: this is not a two party protocol where membership is set forever.
If a single member does not support one crypto scheme, this member might never be able to join an hybrid group.

3. security: I clearly don’t believe we should assume anything from the security of the protocol
in the case a cryptographic scheme is broken. I don’t want to get to a point where we have horrible downgrade stories
and I would clearly want to kill and restart the entire group

I think fragmentation is my main worry actually, and if we figure out that we were wrong,
adding more agility is likely to be more easy than removing it.

So my intuition is that we should proceed with one signature scheme for the lifetime of the group
and make sure we have a solid story to export and reconstruct a group, which we need anyway.

B.