[MLS] draft-ietf-mls-architecture-04 Review

[Divyank Katira <[e-mail]>]

Hello all,

Thank you for your efforts in developing MLS. Please find my review of draft-ietf-mls-architecture-04 below.

> Section 2.2 Authentication Service
> 
> “It is important to note that this signature keypair might be the identity keypair directly, or a different signature keypair for which the public key has been for example signed by the identity private key. ... <snip> ... This flexibility also comes at the price of a security tradeoff, described in the security considerations, between potential unlinkability of the signature keys across groups and the amount of time required to reinstate authentication and secrecy of messages after the compromise of a device.”

There is a slight inconsistency here. The text mentions a description in the security considerations section about a tradeoff between using different signature keys across groups in place of the long term identity key for unlinkability, and the time it would take to reinstate post-compromise. However, I found no such description there, particularly, in the ‘Client Compromise’ section.

> Section 3.1.5. Privacy
> 
> “A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS.”

This is marked as an open issue, and I agree with the comment in the document that the privacy statements seem strong. While MLS does make reasonable attempts to protect metadata through message padding and encrypting sender information, a service provider may still correlate senders and receivers of a message. A sender could be unmasked through traffic analysis, by using the group identifier in the common case of a group size of two, or through knowledge of group membership in the server fan-out model. I think that this section should acknowledge such practical limitations to the privacy properties of the protocol.

> Section 3.2.1. Connections between Clients and Servers (one-to-one)
> 
> “... the security of MLS will generally survive compromise of the transport layer, so long as identity keys provided by the AS are authenticated at a minimum. However, MLS ciphertext contains the Group Identifier, Epoch number and Content Type that may be used to improve attacks on the privacy of the group.”

This section on transport layer security compromise should also acknowledge that MLS allows certain handshake messages (external proposals, for example) to be sent as ‘MLSPlaintext’ which could reveal information such as group membership, and have a more direct impact on privacy of a group.

I have also submitted a pull request with minor editorial changes here https://github.com/mlswg/mls-architecture/pull/65 <https://github.com/mlswg/mls-architecture/pull/65>

Hope this helps!

Regards,
Divyank