Subject: [Mls] Regarding Signatures

From: Nadim Kobeissi <[email-masked]>
Date: Mon, 5 Feb 2018 21:03:20 +0100

Hello everyone,
mls-protocol-00 says the following with regards to signing keys possessed by each participant:

"Identity Key:  A long-lived signing key pair used to authenticate the
      sender of a message.”

So far, I’ve been able to identify some missing details with regards to signatures in this protocol:

1. Cipher Suite Ambiguity:
Cipher suites seem to specify only Diffie-Hellman key agreement functions and hash functions, but not signature functions. A reference to ECDSA seems to exist under the P-256 cipher suite subsection, but it appears to be nevertheless decontextualized. More confusingly, the HandshakeType struct seems to specify an open-ended "SignatureScheme algorithm” element. Why does this exist outside the namespacing afforded by cipher suites, if at all?

2. Mention of Supporting Certificates for Signatures:
In Section 6.1, a future possibility for including a certificate for signatures is mentioned. This seems like a bad idea: do we really want to introduce X.509 and ASN.1 parsing when we have the opportunity to finally move away from it?

3. Gratuitous Signature Usage Causes Performance Issues and Conflicts with Deniability:
Signatures seem to be sometimes used gratuitously:
	A. The clearest instance of this is in 9.2, client-side enforced ordering, which suggests adding a signed envelope to *every message* simply in order to obtain client-enforced message ordering by signing a counter. This seems like overkill.
	B. To a lesser extent, this is also the case in all five handshake messages (Init, UserAdd, GroupAdd, Update, Delete), which, while a more sensible venue for signatures, does raise the question of whether handshake message authenticity can be maintained in some other way (chaining keys deriving a chain of authenticity from a signed AKE in the Init handshake message, which is currently unspecified? we should definitely think more about this, and I hope we don’t end up empty-handed.)

This is problematic, firstly, due to performance concerns, since signatures are the slowest primitives. Aside from that, though, the amount of signatures being employed as part of a regular session conflicts with an explicit goal of the protocol: mls-architecture-00 mentions deniability in section 3.2.2.5.

Signal Protocol has a wonderful construction where signatures are used to obtain an AKE. Then an HKDF is used to create a ratchet of chaining keys which chain the authenticity of the AKE down throughout the rest of the conversation. In an entire Signal session, only one signing operation is ever performed by each party. Perhaps something similar could be adopted here? Signatures have always been the most unwieldy primitive, and it might be fruitful to consider restricting them as much as possible within this protocol.

Regards,

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Tue, 06 Feb 2018 15:07:50 +0000

Thanks for the comments! On (3), I agree it makes sense to restrict the use of signatures where it's not otherwise problematic, but note that Signal only avoids them because it is two-party: the Sender Key variant includes an explicit signature on every message precisely because symmetric keys don't work for message origin authentication in the n-party case. (Which must mean that the performance isn't _too_ bad, given WhatsApp uses sender keys.)

That is, suppose A, B and C all share a symmetric key and A receives a message authenticated by that key. A can't tell whether B or C sent the message unless there is something else going on, either a signature or some pairwise symmetric key that only A and one other party knows.

There may well be a design that increases the level of deniability while not impacting other more-important goals (for example, by distributing a signature key in a deniable way), and I would be all in favour of that!

best,
Katriel

On Mon, 5 Feb 2018, at 8:03 PM, Nadim Kobeissi wrote:
> Cipher suites seem to specify only Diffie-Hellman key agreement 
> functions and hash functions, but not signature functions. A reference 
> to ECDSA seems to exist under the P-256 cipher suite subsection, but it 
> appears to be nevertheless decontextualized. More confusingly, the 
> HandshakeType struct seems to specify an open-ended "SignatureScheme 
> algorithm” element. Why does this exist outside the namespacing afforded 
> by cipher suites, if at all?
> 
> In Section 6.1, a future possibility for including a certificate for 
> signatures is mentioned. This seems like a bad idea: do we really want 
> to introduce X.509 and ASN.1 parsing when we have the opportunity to 
> finally move away from it?
> 
> 	A. The clearest instance of this is in 9.2, client-side enforced 
> ordering, which suggests adding a signed envelope to *every message* 
> simply in order to obtain client-enforced message ordering by signing a 
> counter. This seems like overkill.
> 	B. To a lesser extent, this is also the case in all five handshake 
> messages (Init, UserAdd, GroupAdd, Update, Delete), which, while a more 
> sensible venue for signatures, does raise the question of whether 
> handshake message authenticity can be maintained in some other way 
> (chaining keys deriving a chain of authenticity from a signed AKE in the 
> Init handshake message, which is currently unspecified? we should 
> definitely think more about this, and I hope we don’t end up empty-
> handed.)
> 
> This is problematic, firstly, due to performance concerns, since 
> signatures are the slowest primitives. Aside from that, though, the 
> amount of signatures being employed as part of a regular session 
> conflicts with an explicit goal of the protocol: mls-architecture-00 
> mentions deniability in section 3.2.2.5.
> 
> Signal Protocol has a wonderful construction where signatures are used 
> to obtain an AKE. Then an HKDF is used to create a ratchet of chaining 
> keys which chain the authenticity of the AKE down throughout the rest of 
> the conversation. In an entire Signal session, only one signing 
> operation is ever performed by each party. Perhaps something similar 
> could be adopted here? Signatures have always been the most unwieldy 
> primitive, and it might be fruitful to consider restricting them as much 
> as possible within this protocol.
> 
> Regards,
> 
> Nadim Kobeissi
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls