Re: [Mls] Regarding Signatures

["Katriel Cohn-Gordon" <[e-mail]>]

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:
> 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
> 
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls