Subject: [MLS] confirming cipher suites decisions

From: Sean Turner <[email-masked]>
Date: Thu, 6 Feb 2020 17:08:00 +0100

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

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Wed, 12 Feb 2020 15:59:52 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi!

    

    

    

    Cheers,
    
    Nick and Sean
    _______________________________________________
    MLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Feb 2020 12:04:15 -0500

I agree that these considerations are good to get documented, but at least
given the current state of thinking, it seems fine to proceed with the
strategy in the current PR.

On Wed, Feb 12, 2020 at 11:00 AM Hale, Britta (CIV) <[email-masked]>
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:
>
>
> 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
>
>
>     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.
>
>     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:
>     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: 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

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Wed, 12 Feb 2020 17:10:03 +0000

It is not clear whose current state of thinking you are referring to, Richard, but perhaps we should give a week to Sean's original 20th of February timeline so that the working group members have the opportunity to discuss and speak for themselves.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Richard Barnes <[email-masked]>
Sent: Wednesday, February 12, 2020 9:04:15 AM
To: Hale, Britta (CIV) <[email-masked]>
Cc: Sean Turner <[email-masked]>; Messaging Layer Security WG <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

I agree that these considerations are good to get documented, but at least given the current state of thinking, it seems fine to proceed with the strategy in the current PR.

On Wed, Feb 12, 2020 at 11:00 AM Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

All the best,

Britta

On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi!

    Cheers,

    Nick and Sean
    _______________________________________________
    MLS mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls

---

From: Sean Turner <[email-masked]>
Date: Thu, 13 Feb 2020 09:49:18 -0500

> On Feb 6, 2020, at 11:08, Sean Turner <[email-masked]> wrote:
> 
> Hi!
> 

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

---

From: Paul Grubbs <[email-masked]>
Date: Fri, 14 Feb 2020 15:47:58 -0500

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 <[email-masked]> wrote:

> > 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.
> >
> > 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.
> >
> > 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:

---

From: Benjamin Beurdouche <[email-masked]>
Date: Sat, 15 Feb 2020 09:19:43 +0100

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 <[email-masked]> 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?
>

---

From: Dennis Jackson <[email-masked]>
Date: Sat, 15 Feb 2020 12:27:07 +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:
> 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.
> 
> 
>> 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 <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>     > On Feb 6, 2020, at 11:08, Sean Turner <[email-masked]
>>     <mailto:sean@sn3rd...com>> wrote:
>>     >
>>     > Hi!
>>     >
>>     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.
>>     >
>>     > 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:
>>     > 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: 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:
>>     [email-masked] <mailto:[email-masked]>

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Tue, 18 Feb 2020 20:00:49 +0000

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)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    
    All the best,
     
    Britta 

        Hi!

        

        

        

        Cheers,
        
        Nick and Sean

---

From: Konrad Kohbrok <[email-masked]>
Date: Wed, 19 Feb 2020 07:09:09 +0100

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Feb 2020 12:43:33 -0500

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 <[email-masked]> wrote:
> 
> Hi Britta,
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Feb 2020 13:24:07 -0500

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 <[email-masked]> 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:
> >> 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)" <
> [email-masked] on behalf of [email-masked]> wrote:
> >>
> >>    Hi,
> >>
> >>    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" <
> [email-masked] on behalf of [email-masked]> wrote:
> >>
> >>        Hi!
> >>
> 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
> the MTI.  The rationale was that those implementation that need to be NIST
> 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.
> >>
> provided to be conservative about allocating new code points. The consensus
> at the interim was that the suites provided were minimal and provided good
> please let the WG know by 2359 UTC 20 February whether you disagree with
> these choices and why.
> >>
> but if we only come to consensus on some of these we can still incorporate
> what we do agree on.
> >>
> >>        Cheers,
> >>
> >>        Nick and Sean

---

From: Sean Turner <[email-masked]>
Date: Wed, 26 Feb 2020 11:28:20 -0500

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 <[email-masked]> wrote:
> 
> I will not be able to make the call tomorrow, so to summarize my opinion on this:
> 
>   * 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
>   * So the only difference in spec is whether endpoints check Credential.SigAlgorithm == CipherSuite.SigAlgorithm
> 
>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 26 Feb 2020 19:24:33 +0100

I would strongly prefer one signature scheme for the lifetime of the group.
B.

> On 26 Feb 2020, at 17:28, Sean Turner <[email-masked]> wrote:
>

---

From: Cas Cremers <[email-masked]>
Date: Wed, 26 Feb 2020 19:48:31 +0100

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

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Wed, 26 Feb 2020 18:51:33 +0000

Thank you Benjamin for speaking up. If we go forward with either option it is good to have a documented basis for doing so on the mailinglist, and until now we have arguments which support individual schemes, or "no strong preference". As there were no objections to the stated reasons supporting individual schemes, the rough consensus until now was arguably for that; putting forward a clear preference gives us grounds for not dismissing the group option. Ease of implementation without error, efficiency, or security are all reasonable arguments for choosing one of these or the other - having an existing PR to follow should not be our decision metric. So it is good to see a clear statement on the mailinglist. 

Given the points outlined in the document, the positives and negatives of both suggest that the individual signature option may be better for security. However, if there is even one strong argument for having a single group scheme, that is not a comparable under the individual option, then that may be a fair basis for the single group scheme choice. 
Can you describe the security (or efficiency/implementation) factors that lead to your preference?

Britta 

On 2/26/20, 7:25 PM, "MLS on behalf of Benjamin Beurdouche" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 26 Feb 2020 20:17:00 +0100

I have a few worries, so quick thoughts:

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

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.

Ben

> On 26 Feb 2020, at 19:51, Hale, Britta (CIV) <[email-masked]> wrote:
>

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 26 Feb 2020 20:37:48 +0100

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.
That is, my preference is not to add new signature algorithms as a group evolves and new members are added.

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. 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.

-Karthik

> On 26 Feb 2020, at 19:48, Cas Cremers <[email-masked]> wrote:
> 
> Hi,
>

---

From: Cas Cremers <[email-masked]>
Date: Wed, 26 Feb 2020 20:41:03 +0100

Hi,

I agree with Karthik's suggestion; in practice this may simply be the
intersection of the algorithms that the initial members support.

Best,

Cas

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 26 Feb 2020 20:47:37 +0100

It is what we currently do, the problem is not creation or the initial members, it is the newcomers.
B.

> On Feb 26, 2020, at 8:41 PM, Cas Cremers <[email-masked]> wrote:
> 
> Hi,
>

---

From: Cas Cremers <[email-masked]>
Date: Wed, 26 Feb 2020 20:51:59 +0100

Sure, I meant taking up the suggestion as fixing this set for newcomers.

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Wed, 26 Feb 2020 19:53:25 +0000

Actually this is different from the single-scheme option, as there the choice is entirely restricted and any newcomer has their signature security dictated. In this option there are choices for newcomers - not complete freedom of scheme selection, but some freedom.

This sounds like a good compromise to me as well. Giving newcomers options may reduce downgrade issues among other things, while this also sets limits on the scheme selection. Even if there are only a couple signature schemes in offered algorithms, many of the concerns surrounding the original single-scheme option would be alleviated. 

Britta

On 2/26/20, 8:48 PM, "MLS on behalf of Benjamin Beurdouche" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Konrad Kohbrok <[email-masked]>
Date: Thu, 27 Feb 2020 09:36:18 +0200

I also think this is a good compromise. I'm curious to see what the dynamic will
be in a federated environment when one or more signature schemes turn out to be
weak (or no one wants to use pre-quantum crypto anymore) and what people's
policy on group-reboots will be in that scenario. I don't think there is
precedence for such a system and we can't predict too much of that now, so it's
good to go for a compromise.

Konrad

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 27 Feb 2020 10:03:35 +0100

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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello All,
> 

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.

> 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.

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>

B.

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Thu, 27 Feb 2020 09:57:54 +0000

Benjamin,

The issues you describe are primarily TLS-type problems, where uncontrolled, large-scale agility and interop issues exist. 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. 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.

Britta

From: Benjamin Beurdouche <[email-masked]>
Date: Thursday, February 27, 2020 at 10:03 AM
To: Cas Cremers <[email-masked]>, "Hale, Britta (CIV)" <[email-masked]>, Konrad Kohbrok <[email-masked]>
Cc: Karthikeyan Bhargavan <[email-masked]>, ML Messaging Layer Security <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

On 26 Feb 2020, at 20:37, Karthik Bhargavan <[email-masked]<mailto:[email-masked]>> wrote:

Hello All,

B.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 27 Feb 2020 11:47:10 +0100

Hi Britta,

> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <[email-masked]> 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
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.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 27 Feb 2020 11:48:36 +0100

> On 27 Feb 2020, at 11:47, Benjamin Beurdouche <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Britta,
> 
>> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Benjamin,
>>  

S/should be selecting/can select/

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Thu, 27 Feb 2020 11:50:03 +0000

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 <[email-masked]>
Date: Thursday, February 27, 2020 at 11:48 AM
To: "Hale, Britta (CIV)" <[email-masked]>
Cc: Cas Cremers <[email-masked]>, Karthikeyan Bhargavan <[email-masked]>, ML Messaging Layer Security <[email-masked]>, Konrad Kohbrok <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

On 27 Feb 2020, at 11:47, Benjamin Beurdouche <[email-masked]<mailto:[email-masked]>> wrote:

Hi Britta,

On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:

Benjamin,

B.

---

From: Raphael Robert <[email-masked]>
Date: Thu, 27 Feb 2020 19:02:17 +0100

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) <[email-masked]> wrote:
> 
> Benjamin, 
>

---

From: Karthik Bhargavan <[email-masked]>
Date: Fri, 28 Feb 2020 06:54:50 +0100

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 <[email-masked]> wrote:
> 
>> On 27 Feb 2020, at 12:50, Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Benjamin, 
>>  
>> From: Benjamin Beurdouche <[email-masked] <mailto:[email-masked]>>
>> To: "Hale, Britta (CIV)" <[email-masked] <mailto:[email-masked]>>
>> Cc: Cas Cremers <[email-masked] <mailto:[email-masked]>>, Karthikeyan Bhargavan <[email-masked] <mailto:[email-masked]>>, ML Messaging Layer Security <[email-masked] <mailto:[email-masked]>>, Konrad Kohbrok <[email-masked] <mailto:[email-masked]>>
>> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Fri, 28 Feb 2020 07:21:58 +0000

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 <[email-masked]>
Date: Friday, February 28, 2020 at 6:55 AM
To: Raphael Robert <[email-masked]>
Cc: "Hale, Britta (CIV)" <[email-masked]>, Benjamin Beurdouche <[email-masked]>, Cas Cremers <[email-masked]>, ML Messaging Layer Security <[email-masked]>, Konrad Kohbrok <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

Best,
Karthik

On 27 Feb 2020, at 19:02, Raphael Robert <[email-masked]<mailto:[email-masked]>> wrote:

Raphael

On 27 Feb 2020, at 12:50, Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:

Benjamin,

---

Britta

From: Benjamin Beurdouche <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 27, 2020 at 11:48 AM
To: "Hale, Britta (CIV)" <[email-masked]<mailto:[email-masked]>>
Cc: Cas Cremers <[email-masked]<mailto:[email-masked]>>, Karthikeyan Bhargavan <[email-masked]<mailto:[email-masked]>>, ML Messaging Layer Security <[email-masked]<mailto:[email-masked]>>, Konrad Kohbrok <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MLS] confirming cipher suites decisions

Hi Britta,

Benjamin,

B.

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Fri, 28 Feb 2020 07:31:04 +0000

There is arguably a third “case”, which may be where most of the practicality questions are arising from:

  1.  The group creator wants more control of the security of the signature scheme only.

     *   The group creator chooses the MTI ciphersuite.
     *   The group creator chooses a subset of initial group members’ supported algorithms (which may or may not include the MTI).
Again, for the sake of argument, consider the following alternative to b:

Here, the ciphersuite choice and signature scheme choice are not comparable: 3a indicates that we want full flexibility, while 3b/3c indicate more focus on security - not that the MTI is less secure, but that the group creator wants a non-MTI scheme for some particular reason. Otherwise this would reduce to case 1).

That point aside, in case 3) a newcomer would be able to join based on ciphersuite alone. Then the real debate is then on the probability of the newcomer supporting a single non-MTI scheme versus a set of schemes. I am not sure that this is a point worth focusing on, as it is clearly a special case of 2) in terms of the intent and motivation of the group creator (i.e. if the group creator is more focused on the security and other aspects than allowing anyone to join, then issues in 3) seem largely to be a moot point).

Britta

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Friday, February 28, 2020 at 8:21 AM
To: Karthik Bhargavan <[email-masked]>, Raphael Robert <[email-masked]>
Cc: Benjamin Beurdouche <[email-masked]>, Cas Cremers <[email-masked]>, ML Messaging Layer Security <[email-masked]>, Konrad Kohbrok <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

Britta

Best,
Karthik

Raphael

Benjamin,

---

Britta

Hi Britta,

Benjamin,

B.

---

From: Raphael Robert <[email-masked]>
Date: Fri, 28 Feb 2020 12:34:55 +0100

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) <[email-masked]> wrote:
> 
> 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.
>  
> 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).
> The group creator chooses a single non-MTI signature scheme.
>  
>> On 27 Feb 2020, at 19:02, Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Fri, 28 Feb 2020 12:18:12 +0000

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

________________________________
From: Raphael Robert <[email-masked]>
Sent: Friday, February 28, 2020 12:34:55 PM
To: Hale, Britta (CIV) <[email-masked]>
Cc: Karthik Bhargavan <[email-masked]>; Benjamin Beurdouche <[email-masked]>; Cas Cremers <[email-masked]>; ML Messaging Layer Security <[email-masked]>; Konrad Kohbrok <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

Raphael

On 28 Feb 2020, at 08:21, Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:

Britta

From: Karthik Bhargavan <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2020 at 6:55 AM
To: Raphael Robert <[email-masked]<mailto:[email-masked]>>
Cc: "Hale, Britta (CIV)" <[email-masked]<mailto:[email-masked]>>, Benjamin Beurdouche <[email-masked]<mailto:[email-masked]>>, Cas Cremers <[email-masked]<mailto:[email-masked]>>, ML Messaging Layer Security <[email-masked]<mailto:[email-masked]>>, Konrad Kohbrok <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MLS] confirming cipher suites decisions

Best,
Karthik

Raphael

Benjamin,

---

Britta

Hi Britta,

Benjamin,

B.

---

From: Raphael Robert <[email-masked]>
Date: Fri, 28 Feb 2020 19:05:41 +0100

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) <[email-masked]> wrote:
> 
> Get Outlook for Android <https://aka.ms/ghei36>
>> On 28 Feb 2020, at 08:21, Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Karthik Bhargavan <[email-masked] <mailto:[email-masked]>>
>> To: Raphael Robert <[email-masked] <mailto:[email-masked]>>
>> Cc: "Hale, Britta (CIV)" <[email-masked] <mailto:[email-masked]>>, Benjamin Beurdouche <[email-masked] <mailto:[email-masked]>>, Cas Cremers <[email-masked] <mailto:[email-masked]>>, ML Messaging Layer Security <[email-masked] <mailto:[email-masked]>>, Konrad Kohbrok <[email-masked] <mailto:[email-masked]>>

---

From: Jon Millican <[email-masked]>
Date: Fri, 28 Feb 2020 19:50:29 +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 <[email-masked]> on behalf of Raphael Robert <raphael=[email-masked]>
Date: Friday, 28 February 2020 at 10:07
To: "Hale, Britta (CIV)" <[email-masked]>
Cc: Karthik Bhargavan <[email-masked]>, Cas Cremers <[email-masked]>, Benjamin Beurdouche <[email-masked]>, ML Messaging Layer Security <[email-masked]>, Konrad Kohbrok <[email-masked]>
Subject: Re: [MLS] confirming cipher suites decisions

Proposal A:

Proposal B:
 - Ciphersuite + LSS

Raphael

On 28 Feb 2020, at 13:18, Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 28, 2020 12:34:55 PM
To: Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>>
Cc: Karthik Bhargavan <[email-masked]<mailto:[email-masked]>>; Benjamin Beurdouche <[email-masked]<mailto:[email-masked]>>; Cas Cremers <[email-masked]<mailto:[email-masked]>>; ML Messaging Layer Security <[email-masked]<mailto:[email-masked]>>; Konrad Kohbrok <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MLS] confirming cipher suites decisions

Raphael

Britta

Best,
Karthik

Raphael

Benjamin,

---

Britta

Hi Britta,

Benjamin,

B.

_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
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=>