Keys and Secrets

[br-hale]

Reopening #630 due to incomplete discussion and inaccuracy.

The claims presented are incorrect in response by @bifurcation demonstrate a misunderstanding of the roles of these keys and uses, and #636 constitutes a change to the fundamental uses thereof.

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

[bifurcation]

Clearly we have a disagreement here @br-hale, but maybe let's hold off on attributing misunderstanding.

It seems like you are claiming that in order for MLS to be secure, the authentication_secret needs to be protected to the same level as the epoch_secret. What is this based on?

If that is true, then we should probably remove the authentication_secret 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.

[br-hale]

@bifurcation 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 authentication_secret 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 authentication_secret which can support epoch-level authentication would be public. The authentication_secret is private in the same way that the exporter_value 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 isn't a logical basis for removing 'out-of-band' authentication mechanisms.

[bifurcation]

What I'm trying to get at here is: What is the negative consequence if an authentication_secret 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 encryption_secret would allow the attacker to decrypt all of the group's messages.

What is the bad consequence of an authentication_secret becoming public?

[br-hale]

@bifurcation 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?

[br-hale]

Publishing the authentication_secret as a public value has a similar effect as publishing the exporter_value 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.

[bifurcation]

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 @kkohbrok and I discussed in the PR.

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 authentication_secret is "public" and not "secret". Do you disagree?

[bifurcation]

BTW, the notion of something being "public" at one layer but "secret" at another is not new. For example, values exported from TLS aren'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 SRTP keys that are exported from TLS, and many people would be very sad if these "public" values were published.

[bifurcation]

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 authentication_code is a clearer name. Doesn't mean you have to use it in any particular way in your application; doesn't prevent it being used as a shared secret; but also doesn't imply that the MLS library has to worry about its secrecy.

[br-hale]

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

BTW as a point case on more standard terminology use, the TLS 1.3 spec uses the exact phrasing for exporters as "exporter_master_secret", from which the actual exporter may be derived. This aligns very closely to the authentication_secret, from which an authentication code later may be derived. TLS is generic in 'exporters' after an exporter_master_secret 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 authentication_code, 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 "authentication_master_secret". The shortened "authentication_secret" was a good name. If you are going to provide a write-up for the custom taxonomy, then an adjustment to "authentication_exporter" could perhaps be made.

[bifurcation]

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#11, 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 authentication_secret is different from say epoch_secret in this regard. It would be OK for an MLS implementation to have an API for an application to access the authentication_secret, but it would not be OK to have an API to access the epoch_secret.

I'm not wedded to _code, I just want something other than _secret. If you want to align with the exported values (to which I agree it is similar), we could call it an authentication_value.

[br-hale]

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 #630, then the correct term would be "authentication_key". To quote you what you said there,

"key" is something that gets fed into another algorithm, e.g., HMAC

• which correctly aligns to a reasonable usage of the authentication_key.

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

[bifurcation]

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.

[bifurcation]

@br-hale 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 authentication_secret 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. @br-hale suggested epoch_authenticator, which I like a lot.

I have attempted to implement these in #639