Draft: draft-ietf-mls-protocol

Commentary: That looks like a good change and clarification . I a couple small changes in in - line comments above . 
 Thanks for the review and thanks for hashing through this . 
 The latest edit looks good and that works . 
 Reopening due to incomplete discussion and inaccuracy . The claims presented are incorrect in response by demonstrate a misunderstanding of the roles of these keys and uses , and constitutes a change to the fundamental uses thereof . The authenticationsecret is NOT a public value nor was it ever introduced as such . If an application is using it as a public value , that onus is on the developers , and I advise against using Cisco 's implementation as a standard for MLS . As shown in the name and all original discussion , the authenticationsecret is intended as a secret value ( or else ' public ' in the same way that the group secret is ' public ) . It is used for further derivation to support authentication . This should be corrected , and such foundational changes without WG discussion should be avoided . 
 Clearly we have a disagreement here but maybe let 's hold off on attributing misunderstanding . It seems like you are claiming that in order for MLS to be secure , the needs to be protected to the same level as the . What is this based on ? If that is true , then we should probably remove the altogether . The " out - of - band " protocol in which it would be confirmed would have to be part of the MLS security analysis , thus no longer out - of - band . 
 that is not the claim at all - different uses imply different compromise risks . This should not be a new concept to understand . As demonstrated in the terminology , the authenticationsecret is linked to authentication , not confidentiality . MLS , per specification , outsources authentication ( the AS is not explicitly defined and all entity authentication within MLS relies on it ) . Even though it is definitionally out - of - scope and therefore out - of - band ( certificates , authentication verification are entirely out - of - band of the protocol spec ) , we do not say that signature secret keys can be " public " - yet you are asserting that an authenticationsecret which can support epoch - level authentication would be public . The authenticationsecret is private in the same way that the exportervalue is : based on key schedule derivation , compromise of these keys should not undermine MLS , but secrecy of them can be leveraged . So , unless you are now proposing removing mention of certificates , etc . from the core protocol , there really is n't a logical basis for removing ' out - of - band ' authentication mechanisms . 
 What I 'm trying to get at here is : What is the negative consequence if an is known by someone other than the members of a group ? For example , leaking a signature private key would enable the attacker to impersonate the corresponding member . Leaking the would allow the attacker to decrypt all of the group 's messages . What is the bad consequence of an becoming public ? 
 I am also assuming that this push to use epoch - level authentication values as public codes is based on Cisco 's implementation choice . I would be curious to know why there is such insistence that all implementations also go about using authentication in the same way . If an implementation chooses to use it as a secret value to then derive an authentication code based on yet other information , why is that a problem ? 
 Publishing the authenticationsecret as a public value has a similar effect as publishing the exportervalue as public - it is not an issue for MLS per protocol spec , but it would definitely be an issue for the application if it is then used for something secret thereafter . One reason not to specify these as public values is that they are derived following the conditions placed on keys and therefore could be used as secret values if desired by an application . Forcing or annotating them as immediately public , or as final ' codes ' , when such a use as a secret key is an out - of - scope potential is artificial and unnecessary . 
 I 'm not pushing anything , I 'm just trying to get the protocol to be clear . If this thing needs to be secret , then it needs to be secret , and we need to document that so that people keep it secret . Thanks for elaborating more on your concerns . I see what you 're saying -- basically the same point that and I discussed . I think the core of the disagreement here is what we mean when we say that a value is " public " or " secret " . I mean something very specific : That the security guarantees of MLS will not be harmed if a public value is provided to the attacker , and they will be harmed if a secret value is provided to the attacker . Importantly , " public " does not mean that the value must be published , or that the security guarantees of an application using MLS will not be harmed if you publish the value . It seems to me that in that specific taxonomy , the is " public " and not " secret " . Do you disagree ? 
 BTW , the notion of something being " public " at one layer but " secret " at another is not new . For example , values exported from TLS are n't secret in the sense that publishing them would compromise TLS . You could authenticate your TLS connection by exporting a value and shouting it through megaphones across a crowd . But the main way people use them in practice is as secrets in some other protocol . Every WebRTC call uses  keys that are exported from TLS , and many people would be very sad if these " public " values were published . 
 If it would help , I would be happy to add some text to the Security Considerations clarifying this distinction . Basically , draw a clear boundary around which values have to be kept confidential to the client in order to realize the security properties of the protocol . But I still think is a clearer name . Does n't mean you have to use it in any particular way in your application ; does n't prevent it being used as a shared secret ; but also does n't imply that the MLS library has to worry about its secrecy . 
 Within the bounds of that particular taxonomy there is not an issue . However , while you may be following a given taxonomy , that is not a general one , one that would be widely understood by implementors , nor is it specified in the protocol spec . It is not an unreasonable taxonomy , but it certainly not a general one . If you are looking for MLS usage spec to align to your taxonomy then I do think that there should be a clarification section . BTW as a point case on more standard terminology use , the TLS 1.3 spec uses the exact phrasing for exporters as " exportermastersecret " , from which the actual exporter may be derived . This aligns very closely to the authenticationsecret , from which an authentication code later may be derived . TLS is generic in ' exporters ' after an exportermastersecret is derived . Thus there is alignment of the term ' secret ' to things that can be used for keys ( have sufficient entropy ) , not as an alignment to public / secret at different layers . I am strongly opposed to the use of authenticationcode , and see no clear definition for that in your customized taxonomy . As such , it would follow the more standard interpretations , such as message authentication codes , etc . which are indeed explicitly public values . Codes are normally an end - state in themselves , not keys . Perhaps it is a clearer name for the Cisco implementation design , but it is not a clear name for something that can / should be used for further derivations as may be more generally applicable . Following the TLS norm for exporters , the name would be " authenticationmastersecret " . The shortened " authenticationsecret " was a good name . If you are going to provide a write - up for the custom taxonomy , then an adjustment to " authenticationexporter " could perhaps be made . 
 The notion of a having boundary to the protocol and values that may or may not safely be exported across the boundary is not exotic or customized . You see it in FIPS 140 - 2 , PKCS , and WebCrypto , and in tools like ProVerif and Tamarin . The only choice I 'm making is in the specific words , in particular reserving " secret " for " something that should not be exposed outside the protocol implementation because it would compromise the protocol " . I hope you agree that is different from say in this regard . It would be OK for an MLS implementation to have an API for an application to access the , but it would not be OK to have an API to access the . I 'm not wedded to , I just want something other than . If you want to align with the exported values ( to which I agree it is similar ) , we could call it an . 
 The distinction between those documents and tools , and the MLS spec is that those tools clearly define the boundaries and terminology , vs. just anyone making terminology assumptions without them being specified in the document . Not to be pedantic , but if you want to assume specific meanings for terms relative to a threat model for MLS only , versus a general usage ( " exporter secrets " being secrets used in other things ) , then you really do need to specify those assumptions within the specification itself and not various side discussions . Such specification is part of what a standard is meant to do . Within other documents this is clearly defined - i.e. , what is known as a threat model - such as one sees in ProVerif and Tamarin . Assuming that you are going to add such a taxonomy , and that it follows that described by you in , then the correct term would be " authenticationkey " . To quote you what you said there , which correctly aligns to a reasonable usage of the authenticationkey . pointed out that there is a lack of consistency in the usage of " keys " vs " secrets " throughout the document - something that still has not been addressed and should not be dropped from the issue for edits . Regardless of what taxonomy is being used or even assumed , there is no consistency in it in the spec . You seem to be commenting on adjustments only for the " key " and " secret " uses that appear as variables , but the commentary within the spec interchangeably use these terms for the same thing . Whatever is used should be applied consistently . It is not reasonable to assume that developers will correctly guess reasons for terminology separations particularly when they are inconsistently enforced . 
 On your latter point about usage of " keys " vs " secrets " throughout the document — Sorry if I misinterpreted your intent here . If you 're seeing places where there are inconsistencies , it would be helpful if you could highlight those more specifically , or ideally send a PR to fix them . 
 had a call about this today and hashed out a couple of things : We should be clear in general about what we mean by secrets / keys , in that we generally use them interchangeably , but sometimes use one or the other to indicate how a specific value is used The need for secrecy of the value labeled depends on the context in which it is used . So we should provide some text to suggest that there are different ways to use it , and use a fairly neutral name . suggested , which I like a lot . I have attempted to implement these in
Paragraph (version B):
In general, symmetric values are referred to as "keys" or "secrets"
interchangeably.  Either term denotes a value that MUST be kept
confidential to a Client.  When labelling individual values, we
typically use "secret" to refer to a value that is used derive
further secret values, and "key" to refer to a value that is used
with an algorithm such as HMAC or an AEAD algorithm.
Paragraph (version A):
The main MLS key schedule provides a per-epoch "authentication_code".
If one of the parties is being actively impersonated by an attacker,
their "authentication_code" will differ from that of the other group
members.  Thus, members of a group MAY verify out of band that their
"authentication_code" values are all the same, in order to ensure
that they share the same view of the group.
Paragraph (version B):
The main MLS key schedule provides a per-epoch "epoch_authenticator".
If one member of the group is being impersonated by an active
attacker, the "epoch_authenticator" computed by their client will
differ from those computed by the other group members.
Paragraph (version B):
This property can be used to construct defenses against impersonation
attacks that are effective even if members' signature keys are
compromised.  As a trivial example, if the users of the clients in an
MLS group were to meet in person and reliably confirm that their
epoch authenticator values were equal (using some suitable user
interface), then each user would be assured that the others were not
being impersonated in the current epoch.  As soon as the epoch
changed, though, they would need to re-do this confirmation.  The
state of the group would have changed, possibly introducing an
attacker.
Paragraph (version B):
More generally, in order for the members of an MLS group to obtain
concrete authentication protections using the "epoch_authenticator",
they will need to use it in some secondary protocol (such as the
face-to-face protocol above).  The details of that protocol will then
determine the specific authentication protections provided to the MLS
group.