Re: [MLS] confirming cipher suites decisions

Dennis Jackson <dennis.jackson@cs.ox.ac.uk> Sat, 15 February 2020 12:27 UTC

Return-Path: <dennis.jackson@cs.ox.ac.uk>
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 85CAC120045 for <mls@ietfa.amsl.com>; Sat, 15 Feb 2020 04:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 uc9NlIeH_7EQ for <mls@ietfa.amsl.com>; Sat, 15 Feb 2020 04:27:10 -0800 (PST)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) (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 D14A7120048 for <mls@ietf.org>; Sat, 15 Feb 2020 04:27:09 -0800 (PST)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <dennis.jackson@cs.ox.ac.uk>) id 1j2wXM-00048Z-q5 for mls@ietf.org; Sat, 15 Feb 2020 12:27:08 +0000
Received: from 61.ip-51-38-113.eu ([51.38.113.61] helo=[192.168.2.2]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <dennis.jackson@cs.ox.ac.uk>) id 1j2wXL-000278-Fd for mls@ietf.org; Sat, 15 Feb 2020 12:27:07 +0000
To: mls@ietf.org
References: <CAKDPBw8OC74H7zAkk9e1mkm6UtB6L76Lh5qmjv-DNjep1LmApA@mail.gmail.com> <4AA9B7B2-60EC-4AB4-85CA-FA5EA9F64D3F@inria.fr>
From: Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
Autocrypt: addr=dennis.jackson@cs.ox.ac.uk; prefer-encrypt=mutual; keydata= xsFNBFbAmb8BEADCLixsrAJyvknI95ZIZNVeDJbYvldeXpw7iyhrdUdRK69USU5S9EESulYh k1KlxDB5VfG8CCA/WzG1IonONdXmgLFa1NcmdVvkFjbXf5mbGYG+9pTkieM+UHikniAizIOi ibdTWEEc2opOAvpVypek4SSsfCoXfXqj0j5AXSapHiVzhhWuaXhKVuFdLtYwJDU/x0FXgStm erFMIOeZ5FLFnjkkNyEa1t3XCcf7bfgw8J86UmWzgkVLmtBYbDK0ZAFjtFep5Kps11iTDIa3 xYXzuqgkWwkg7b1mhn5gQUl/kKZqQbuG+Sk+BydjH8e1PJkO6p2eAprO0AoucRuuBl1pmg/F bf/WJC6/XD3AV87ERAdXbb9cH+vrRT8GpiNX5r+7OuXavc3/LNU9stqsdshXwdZlDyPyDIG2 Llj6hB4eS0tEpat3otcPDkXUjXjyOUQ6jKTNSZ+xTBtVTXznflDCGdn9GV0q+4ZbdRZ5tfXM DXM+uMqVxjvh2IjCrka7zf1rRWg1WZu+NrzAUrvPMPddDJfd8JNrIcvV+DIBxPVsUTJLEGt9 PW8LkQb5FrG7T6a813JYNoAtL4w7296UYmUpV1Kvv8otO+uH860x5Ci83ZCXb7gKr9Rankn5 Jcg+shWnDFgSq6uM/u3MmyRV2iw7aCSgcgfy4EPTojJdy3KjzQARAQABzS9EZW5uaXMgSmFj a3NvbiA8ZGVubmlzLmphY2tzb25AZXhldGVyLm94LmFjLnVrPsLBfwQQAQgAKQUCVsCZxQYL CQgHAwIJEGEFp3WM0kasBBUIAgoDFgIBAhkBAhsDAh4BAAoJEGEFp3WM0kasrt0QAIRAaRXL CZHIuU6UUIra1F7zYupS6w32AEC3FGPZ/a6e4Gsllbx0+6FuStAVUsvXRF0x+qE4akZb7+3c oE4V5SASZ36SI6HYT8cxbV2qe2k+wr94E9Nx8TihiLQXImFDH6b4LghqwSn+dKyZjITbbhlj F7/B7Sg5c53afx9oyRBgOyzhY64RSJwJOFpZ4txouPkdJ88FpQggHmvyfIfcnhdR3kbUTyck T9K3xMYpvfT37bj9dS0W635IRcmb+HxacGHyATUyMCIFv95A3kwXjtZGltQ8sSy3rJrCFvxt Q4O34/+B8TxYPZ+vNuKwA7DdkMNXmv2+aJ1kFemXuOv4+WjKs/QFpSmO/ca/Bl3AXi8S90ok 18IXy9507t2KH4EcipC43nqVE0rwXks+toJWp+l/+uYOeKNfU7l6Om3Svwz8pNYO64PCDla9 y+uycGtD+CqQA/CVr2FLd2D5fHZwC4G7o2i5wBJsQ10n6Jhln0MGf5HCjGOLqX3hGEHKv8/b 6u74yaQSKdbXpX+/kQVQzcmvSi2Ah60fI3ZXC8XJjDpJ9/0hBqnnxygdMLHzfzuLftTMBIuI MpNydfNBhvr0iBOQzrNK5MWJZ432kXbH8KkeofrhDmMQj4MCYPLmLGYnnJsWf7Y2rdFuN24j IHXdrjSE8zVkabpeyzRaXt6b1EfPzsFNBFbAmb8BEADgQ9QZjcuxVm6YPU5tznzDQv8i7Ohu 65NzhcOwYaYx1x0rBIHuPB27z5X3UfWmwNXJm4GEexMmjmr9bPboFOxLQwnCvMx2XGlIN4Av hXY7J5CEApH/9xytrMXGwUq5F9lLto47n72btdIP2mr5ArkxyFImAB4UFOZApESOzWL1yCpm j2Nipt2CFSedMfuBpRP1lWZPMB6b4rMQyJwYqM4lIwCKk7dGrebRNTm2ZLJdnjRzQsJaNeVh NoSiGAriSm+e8AgSmjiqP4EsP8jdg19x2lPzxfvKwopJCg4Rw63nxcBpKgX98x5ay4hyK/jj VWfIvXcTMoOUxEcY3d72eIWvu/HK/BvNxwvJUgRKT2JqHlOCfL1n/JIwZWotFJs8mURd0nmZ apXcaO8yYWKt8SLAxilbkgp+vNk3KBLEeVkv2Y3NGaB/2CKXVcvBUbuOXSdiFMx1crMzHzVi qG+2bEPSQl4l8qZiBerreZsL/HXQjHRuiXab4NX69HKAATWyUq1DPLhRJXZkRaQXWzcecUgi YzaPkLkxzl1rjt/xhUZrsfP5Fk5Xxd/nb339j8NwihDaMrIHDn5WEoXIzr/9N7EOgH8U5tiZ 4eXaiUqFZz1qXA8j6p95OM6GVtCEqqKyPMnoSW309wtCeYhF++XPLyVn1FIyIcjtAqR8QEzV t490MQARAQABwsFpBBgBCAATBQJWwJnHCRBhBad1jNJGrAIbDAAKCRBhBad1jNJGrPwmEAC2 RRYwuOvVFhNIw+uZOnc0Zl81JuW/QYYe0vtO9PWQXB1P+Gzb0aOuPQV99kTpEoMQaWz0Avot j+DfADlZCxdorTCrBvwwF4g9a8U+9VBuquJ83cBum6ROXg4IE7AlsdL8Y7VXcDBouXiXdT/6 TNHtSyezNaziSLMT2UEnQBgVvEHTFs8XqIjfYKYreess9+RcFfDbFfTWc4vFPH0Tth1Wk/dF 7Vz3poFN+WbgIAZR9NnnGBAxbquAnwUFzegtyS30xPSoHleSYoYjWSRHKk3uEgVEFw/F6B47 xLd+kFQ6inkXR6XbhNXHoolOS2kuaUh9SwRDQvEKo21STW/d4wKgqZ6TLxZsVxQCtFXgMpcM ArV7cLymgxp6FGB+XyyPPpK4fVVekIws0+k0y1kQrgVT4LSMaAnIdL03VRmOrxBrwWdgqu7I +BOkoQCyqWjm8HonymGJopfGet6fweoh/NB2u3zcz6tpdzv4WqKzilhLj298inFTNyq8pSJK AMYp6aozD3D1Tl0ERB4s1bTy44pKPIQ1Th7U5v8iKKYikQ8DksQiFJ84/0I31Ny6Uaq+jSDX ZecH6DkAC2bWiEyRvfdPXshHesqSGW8ghO5jWqJ9nPs6AZteHgbmhQdc0E6FcdqpEjNAIJFs FQUDT07IkEtYAYfodwz8N4zQjs2Dnm4yXw==
Message-ID: <feaecaf6-c682-0475-b64c-325a6f2fc4dd@cs.ox.ac.uk>
Date: Sat, 15 Feb 2020 12:27:07 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <4AA9B7B2-60EC-4AB4-85CA-FA5EA9F64D3F@inria.fr>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Oxford-Username: exet4027
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/t05oLxrIoCUPWPXbDLG5Zi3AqYM>
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: Sat, 15 Feb 2020 12:27:12 -0000

Hi Benjamin,

Signatures are not committing (in general) [1]. E.g. with Ed25519,
you can pick a public key such that you can produce a signature which is
valid for any message.

Best,
Dennis

[1] https://eprint.iacr.org/2019/779


On 15/02/2020 08:19, Benjamin Beurdouche wrote:
> Hi Paul,
> 
> Yes, thanks for reminding us of this. This is something we need to think
> about seriously indeed...
> 
> My intuition is that since we also have signatures we should be safe.
> But I agree that we have to evaluate carefully the differences between
> the committing and non-committing modes.
> 
> B.
> 
> 
>> On Feb 14, 2020, at 9:48 PM, Paul Grubbs <pag225@cornell.edu> wrote:
>>
>> 
>> Hey all, quick question - all the AE schemes used in these cipher
>> suites are non-committing (meaning they misbehave in weird ways when
>> keys may be adversarially known or chosen). Not including a cipher
>> suite which uses a committing AE (cAE) scheme may make reasoning about
>> the protocol's behavior difficult in some settings. Since the latency
>> increase of committing AE would not be terribly high (one such scheme
>> is AES128-CTR-then-HMAC-SHA384 with HKDF-derived encryption and
>> authentication keys, which is reasonably close to what Signal uses),
>> might the inclusion of a cAE cipher suite be worth discussing?
>>
>> On Thu, Feb 13, 2020 at 9:49 AM Sean Turner <sean@sn3rd.com
>> <mailto:sean@sn3rd.com>> wrote:
>>
>>
>>
>>     > On Feb 6, 2020, at 11:08, Sean Turner <sean@sn3rd.com
>>     <mailto:sean@sn3rd...com>> wrote:
>>     >
>>     > Hi!
>>     >
>>     > tl;dr: confirming MTI suite selections and rationale for
>>     avoiding proliferation
>>     >
>>     > During the F2F Interim in January, the WG discussed cipher
>>     suites-related issues. Namely, whether a per-group signature
>>     scheme should be driven by the chosen cipher suite, what were the
>>     MTI (Mandatory To Implement) cipher suites, and what the actual
>>     algorithm should be.
>>     >
>>     > There was rough agreement that there should be one signature
>>     scheme per group and that should be driven by the cipher suite.
>>     There are, at least, three things to consider: 1) if a potential
>>     group member does not support the algorithm, then they will not
>>     become a member or the group will need to downgrade; 2) when the
>>     group needs/wants to update, it is a flag day; and, 3) the cipher
>>     suites will have a similar combinatorial issues as the TLS cipher
>>     suites prior to TLS 1.3. The agreement was “rough” because 1)
>>     likely has some important implications.
>>     >
>>     > The MLS cipher suites defined were as follows:
>>     > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519
>>     > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256
>>     > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519
>>     > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448
>>     > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521
>>     > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448
>>     >
>>     > At the interim, the consensus was to make the non-NIST suites
>>     the MTI.  The rationale was that those implementation that need to
>>     be NIST compliant will do so regardless of the choice made by the WG.
>>     >
>>     > In looking at the actual cipher suites, it was noted that the
>>     256-bit schemes the SHA should be SHA-512. The rationale agreed
>>     was that SHA-384 is SHA-512 cut in half, so just do SHA-512
>>     because it is one less operation.
>>     >
>>     > To avoid the proliferation of cipher suites, guidance will be
>>     provided to be conservative about allocating new code points. The
>>     consensus at the interim was that the suites provided were minimal
>>     and provided good coverage for the known use cases:
>>     > - (X25519, AES-GCM, Ed25519) - Good for desktop
>>     > - (P-256, AES-GCM, P-256) - Compliance
>>     > - (X25519, ChachaPoly, Ed25519) - Good for mobile
>>     >
>>     > The chairs need to confirm the interim’s consensus on list, so
>>     please let the WG know by 2359 UTC 20 February whether you
>>     disagree with these choices and why.
>>     >
>>     > NOTE: The final text will obviously be reviewed, but is being
>>     composed as part of the following PR:
>>     > https://github.com/mlswg/mls-protocol/pull/279
>>     >
>>     > NOTE: We combined these cipher suite related consensus points,
>>     but if we only come to consensus on some of these we can still
>>     incorporate what we do agree on.
>>
>>     I finally got around to doing my homework related to PR279. My bit
>>     was the more procedural bits that instructs IANA to establish/use
>>     a Designated Expert pool:
>>     https://github.com/mlswg/mls-protocol/pull/307
>>
>>     spt
>>     _______________________________________________
>>     MLS mailing list
>>     MLS@ietf.org <mailto:MLS@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>