Re: [MLS] confirming cipher suites decisions

Cas Cremers <cas.cremers@gmail.com> Wed, 26 February 2020 18:48 UTC

Return-Path: <cas.cremers@gmail.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 880D23A1107 for <mls@ietfa.amsl.com>; Wed, 26 Feb 2020 10:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 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, FREEMAIL_FROM=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LHYyqSoUawvq for <mls@ietfa.amsl.com>; Wed, 26 Feb 2020 10:48:44 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 EFE593A10EC for <mls@ietf.org>; Wed, 26 Feb 2020 10:48:36 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id c13so3661812wrq.10 for <mls@ietf.org>; Wed, 26 Feb 2020 10:48:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yKDshBSN0Y8BnWkVN7JBM5kbLbg9DhfRmeHi6v7WG0w=; b=Zn9KP00Ig4J3ySRm14M7b+6TKHzL+hnddl4fl4JGfa73hXH/8Fax/uAXx58awEpsye vpVR1fwldxZX6I4ZQRUfz3x+45j59v76R4CAq3NivzADlmT+c7jwJi84M3bI/hHtOVSM kH5Ff7Oeiwz30jFxKakwPB+Jyv/dTv3xuISZEBoh3zTzZkqAp23tm5csupTItxNJMaJg LWsXug0PFsRr2gLE4dCVKKEmBhj+T2aG6dldSTS6FObg4jMy6n3KKmJwtmuSEpnOxobS YtI9qpFc36b9R1ff0GWEkL8zsihSMNqlUcqmC6IiJGVkii+AowkmJHFvAiYvxkjeexuy GLhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yKDshBSN0Y8BnWkVN7JBM5kbLbg9DhfRmeHi6v7WG0w=; b=P4KOvESM79ObFoS77XFUecU9QAXBKU2N5z8JTLQPaxR2E5hXwjF8pF1nc3/GHWqVMq a8/KIf0lsNvGO4mR7pn02thhDAQL/8jZ2kWhAb7V+qgX5OKo7vzfc9XpYU4GPjv027RO 79SpIxBdVdhux8T4b7TXkPS86eUPpSmJhfRSsNAR41JRepRFTMrzzzM9Z3BNvRuNILuC BL7SunpxXHGqAgl/n0J2roji7PoX0HxxV6hO+SzjbhIMKeRFFL9F2Btow0weWvSGGNwh EIYdtPKwL+Zp0W4iGJRrfqVGz9AoUhSGMrVCEaS4bswM11uBzGeFcGdf57P4XbxjrmF+ Pb6Q==
X-Gm-Message-State: APjAAAUH4R2dj8aGocvkhDl4kH8Vjwi1arehqLd7oH0G5o7iILEaz0qw MP9i9AhCIWV/zh6yIxxibkS0Jhg6
X-Google-Smtp-Source: APXvYqw/TJ9ZAXDYG6uI3j1LOPh4DJsS/t29yddA9G6bAcJm+7a6zud9pVYiVoQtkhbN+CqItTdMpg==
X-Received: by 2002:a5d:6191:: with SMTP id j17mr4537wru.427.1582742912724; Wed, 26 Feb 2020 10:48:32 -0800 (PST)
Received: from ?IPv6:2a02:810c:c1c0:542e:59f5:8c32:7743:205a? ([2a02:810c:c1c0:542e:59f5:8c32:7743:205a]) by smtp.gmail.com with ESMTPSA id q6sm4341138wrf.67.2020.02.26.10.48.31 for <mls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Feb 2020 10:48:32 -0800 (PST)
To: mls@ietf.org
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>
From: Cas Cremers <cas.cremers@gmail.com>
Autocrypt: addr=cas.cremers@gmail.com; keydata= mQGNBFyjFJQBDADNlXG/t7Nd15sfLSf+jaDMUZJvnz59PW5OYoubAWqqNGQBK6A6ahPb6ebX epYdBp/ilE+n1KP/evaV8dMaktooeptOB7D3neOvRox73o2JEjNTC+8OU90dNmGo9UxAVPS9 HuEuJsmvvssiWg97hZBeaPf2F/Hfg2U+RlAKIpR+c+wdc2lTRMqhQXN8OskzQZzlEP8LrMER 1ZT9q22/bdN7nKnpsXSEB8hj8y1dErZHA3+6m73srG7Q7Muw5Kr6zCF4OTXrXsajHHsEyZFj L7qm9BYyrWQ9yXb0l0vWb+i1tzTEK20NoSJiapk3/0prU54dgK3FqQM8SRm7R1wd5mFGN+4x c8pMd/CvHZfJmN4WT581dxaKFMsTFRXMefMKrzbKTgYLsa6tjpFL/sVf06PSkihk/Tc6qrf0 0nxs6pmGHycfC70zwqqqgFdyYQqTUqMforH5cLpms55O4ONCJ6fk+r0fuQO4qXSRK2z00Rpz mJi0WcKyfiHbB/guH5Rqdc8AEQEAAbQjQ2FzIENyZW1lcnMgPGNhcy5jcmVtZXJzQGdtYWls LmNvbT6JAdQEEwEIAD4WIQRIa4Hi/W0N8sfSgzj/8IKxn6kiTQUCXKMUlgIbAwUJAeEzgAUL CQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD/8IKxn6kiTZlWDACFkJBQwDlyCwbp8/hoo4MM awQiLC43SZs8YcTYhX11JVBYvFX3JaphqNdzO8rabtEurHY+R3HOXtHOmMrh+dvDqHIt9q9F dW2B0b7Cs2ayvsI/wRjjS6YTMv8ufGDyLc+DvPvabiEMhCHCA1JQ/qBbzIM9D6DqcJqySR1V /nZjWWAgODQ6BN5xaDXZ8IZGv3s0BIvoCV4E0G5oTQY+3I2pxK40A/0yQERkG+P3xYx71QXQ EPQNOTou/JdWtoehpS5WK8z1PEhWTyVfhin0VXr29cCnKi/d7GIVMmniiEBH9R7QqYPqyJEb DvyUifwaS3HkJtjt1zFURBzeHW+usFza+5cN70qeHVyljjeNrMUAFa0aV1MuCDi4NQOMWkYu 3kjNEqELH+YCi16helZLy1X+AgYjiuzy58/O+WqgqOpnOVWTSBy79XX59ca47vS7BBrmGZTr 5ZvVIXGBHFmSHm0Lkn7TOeszR3L+TZUt8vv50M/+7b0mh+jl6J4i4vb1LsS5AY0EXKMUlQEM AMnddlUgDeoW5jU0pmylA2jtexsT/0EiY+Z0h1cBjP4vWcPJua9K/dBJwPujfshRBSYw97+W Z8h9CoFyK8nWVhRLtALwa9PrlpJ0T2PKbspnb1FTu+eTMEM05YxRD5y0eTY7Q/vdauZ/r1x8 CCOimBZ63Djh5xBogXBUUOm+aLArWaL0/Y/3OUdu00ztrL/IRUF3bDvJch58D6vxvw6IDGMG TzUWGcV0WDyYleUZ1qBEYRsa7JTJ71uJLLRc8NRnaEsD2XkHDhcwHoqk+DIwhuWAdo+i0TGJ fmTcqT2U+3X3WCkEh2Oj4PTA1eb1suEDoicueFGm1tcJ5q9dVuY3weZVDycfMmpzHl3bPhP4 EVkfXvOjUgO0E5UnIo24NnmugBBslEW3+DEd38IUZPjmzYFU8v+OMShJ8siVS7+BTL/na3/g lBhrvNjFNG9p5Wxe+572lZuNa+7tphVb+ipnt2h+3RH/I83fekUODm/+CeVhwYMAhKRfLWhi sfpHogOkNQARAQABiQG8BBgBCAAmFiEESGuB4v1tDfLH0oM4//CCsZ+pIk0FAlyjFJUCGwwF CQHhM4AACgkQ//CCsZ+pIk0YGgv/YENZhZTtgBRVP9FeGTnpJ+YHwzfIXXExj/kbV0c/pSdQ j4vhKclmDRd/rX/IpEpvipfPNgJMfAbiq0uPYgmmoIlGecOQAzYWJxsMPNs5Coz0xDU2hRx+ OnY1ueusLvJN/msxxhdT0lnnQiaGKw5dntnu8dUjdG1vvESd2Mg5rmXalo3MfERF465PYz4r ewIyELT8oaCyqldDrNyNxn64fsDqoYx/md8yQQJJl//LHuVXTy7ylN/NiuF9FWO8z19Ttc/E JeHwCASU24+S4o5gj0A2HgUoxNDzhpxtUGfRH3shGnJ1KeqsRtgxwocd6XL8kaXzYmVOgOyW CN6pu6PpISxW82HogdcblVhvudLoZdO5enwHoWwxfqH6lc0O2jZ86eZb8NiFPi5hxXjEzm9d UBBj4bryCnq9z3UtBX+WUW1bkCCjjrtGVI/peZWP3TyNkgZ6Xwt/tj2Vpqf/2ujnDnWPnztB hoF/x6+xCfXBkpKQD8RbIoBO1sJ6VEDwpIks
Message-ID: <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com>
Date: Wed, 26 Feb 2020 19:48:31 +0100
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: <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/twTad1QpgQ0Sfv8ekl6JAqRkdnA>
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: Wed, 26 Feb 2020 18:48:55 -0000

Hi,

This is a tricky one. I think allowing multiple signature schemes per
group can improve security in subtle ways, especially in large groups
with potentially diverse clients.

I understand part of the "one scheme per group is simpler" argument, but
I am not sure it is simpler in practice, since it puts more weight on
the choice of the initiators of the group, and might complicate adding
group members afterwards. I don't think it is a blocking factor for any
analysis either.

So I have *a slight preference for allowing multiple signature schemes
per group*, from the perspective of facilitating large diverse groups in
the future, and the potential local security benefits.

But I definitely agree with Richard that this can be a small change
later, and doesn't seem to be some fundamental design choice that cannot
be reverted/relaxed/tightened later; I also care about progress, so
let's pick something for now.

Best,

Cas





On 2/26/20 7:24 PM, Benjamin Beurdouche wrote:
> I would strongly prefer one signature scheme for the lifetime of the group.
> B.
> 
>> On 26 Feb 2020, at 17:28, Sean Turner <sean@sn3rd.com> wrote:
>>
>> There seems to be rough consensus (stressing the rough) to go with one scheme per group. By rough consensus, I mean there seems to be a willingness by the group to live with this decision and nobody is super bent out of shape about it. Technically, that’s all we need to move forward, but there are some concerns concerns that since it’s such a small group and there are so few strong voices for the choice that we should give it just a bit more time. So, I am extending this call until 2359 UTC 2 March (i.e., Monday night).
>>
>> Also, there are really three ciphersuite-related decisions being made, as noted in the email below.
>>
>> spt
>>
>>> On Feb 25, 2020, at 13:24, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> I will not be able to make the call tomorrow, so to summarize my opinion on this:
>>>
>>> * I am OK with merging the current PR
>>>  * I have a slight preference for *not* including the sig alg in the ciphersuite
>>>  * The simplicity case for including it seems reasonable, but not dispositive
>>>  * In any case, I don't care strongly one way or another; I care more about progress
>>> * This is an easy change to revert if we change our minds later
>>>  * Credentials are going to indicate the signature algorithm anyway
>>>  * So the only difference in spec is whether endpoints check Credential.SigAlgorithm == CipherSuite.SigAlgorithm
>>>
>>>
>>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner <sean@sn3rd.com> wrote:
>>> Note that the main point of the telecon tomorrow is to address the cipher suite issue.  Please take the time to review:
>>> - the related PRs:
>>> https://github.com/mlswg/mls-protocol/pull/279
>>> https://github.com/mlswg/mls-protocol/pull/307
>>> - the messages in this thread
>>> - the issues Britta outlined:
>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing
>>>
>>> We would like to close this issue out tomorrow.
>>>
>>> Cheers,
>>>
>>> spt
>>>
>>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok <konrad.kohbrok@datashrine.de> wrote:
>>>>
>>>> Hi Britta,
>>>>
>>>> I think you sum it up very nicely. There is one (albeit somewhat speculative)
>>>> argument why a single ciphersuite per group might actually be beneficial in a
>>>> federation context. In the event that there is "global concensus" that a
>>>> ciphersuite needs to be deprecated, my expectation would be that a majority of
>>>> the federation nodes/application providers would move to ban those ciphersuits,
>>>> excluding anyone who would use _exclusively_ that ciphersuite. That would in
>>>> turn be a motivation for all other nodes/application providers to catch up as
>>>> well. This also means that nodes can't be made (by whatever authority) to use
>>>> weak ciphersuites exclusively and still expect to federate with other nodes that
>>>> have more sensible policies.
>>>>
>>>> That's mostly my guess of how the dynamics in such a federated environment
>>>> _could_ work, though. Anyone here with some actual experience/expertise they can
>>>> share of what the dynamics could be?
>>>>
>>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just seems a lot
>>>> simpler and even in the context of federation, I think that most
>>>> nodes/application providers would allow several ciphersuites to begin with,
>>>> where not all of them are weak, meaning no one would really be excluded too quickly.
>>>>
>>>> Cheers,
>>>> Konrad
>>>>
>>>>
>>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote:
>>>>> Under the topic of individual/single signature schemes there is the final issue of federation. In a federated context, groups are no longer under the control of a single application, meaning that we would lose some control in forcing good ciphersuite choices. This could lead to two issues:
>>>>>
>>>>> 1) MLS would move closer to facing the TLS problem of having old suites supported by edge cases, which in turn weaken the entire group's security. There is always the argument that groups would simply refuse joiners that do not support the current group cipher, but this is not very practical from a usability view. E.g. if everyone using application X refused group members who were using application Y, then the point of federation would be largely defeated. So, either some form of renegotiation is allowed (e.g. export psk) and downgrade becomes more likely, or federation does not work reliably. 
>>>>>
>>>>> 2) Healing would take longer. Since no one application has a master view and control over ciphersuites, upgrading long-lived groups using questionable ciphers could take a significant amount of time (all applications would need to do so in order for the group to upgrade) or alternatively result in kicking group members out of the group (again, possible, but questionable for usability except in extreme cases). Under an individual cipher choice, any one member can choose/upgrade their scheme, allowing for faster adaptability and potential benefits to PCS. 
>>>>>
>>>>> From the above, it seems that a single group cipher makes federation harder/slower/less secure, but I may not have a clear view on how federation would work in this context. Does anyone know whether the above are really concerns or not relevant due to other reasons? 
>>>>>
>>>>> (Note that this is thinking in the long-term context. Obviously we do not want to standardize any cipher choice that is sub-optimal; however any number of things may happen with protocol versioning and cipher breaks over the span of several years.)
>>>>>
>>>>> Under all the considerations that I have seen so far, the pros and cons on both sides place the individual signature cipher option in the lead. However that lead is small, hence why I have not been arguing for it. The issue of federation could be a deciding factor. If we want federation in the future it is of course better not to build inhibiting factors into MLS now that could undermine either usability or security in such contexts. To make a case to proceed with the single group cipher option, it would be great if someone could provide a convincing argument as to why it would be the best option for usability and security in the federated environment (or preclude a federated use-case altogether).
>>>>>
>>>>> ---
>>>>>
>>>>> Britta 
>>>>>
>>>>>
>>>>> On 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" <mls-bounces@ietf.org on behalf of britta.hale@nps.edu> wrote:
>>>>>
>>>>>   Hi,
>>>>>
>>>>>   Concerning the use of a single group signature scheme or individual signature schemes, it is probably worthwhile to expand on the consideration points and clarify what security implications we are accepting - in either case. I have listed out some issues in the following Google doc:
>>>>>
>>>>>   https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing
>>>>>
>>>>>   I am not making an argument for either case at this point, but pushing this out for discussion and to help us achieve more clarity as to the benefits and consequences of either choice. There are certainly more issues to consider (e.g. ease of implementation, efficiency, etc. in addition to security considerations) and other views - feel free to add them or discuss on the mailing list. 
>>>>>
>>>>>   All the best,
>>>>>
>>>>>   Britta 
>>>>>
>>>>>
>>>>>   On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" <mls-bounces@ietf.org on behalf of 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.
>>>>>
>>>>>       Cheers,
>>>>>
>>>>>       Nick and Sean
>>>>>       _______________________________________________
>>>>>       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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>