>What I do not understand about draft-housley-tls-using-mls-handshake >includes things like how the server is authenticated, and how the client >is re-authenticated (to avoid replay attacks).
My high-level understanding is that KeyPackage, Welcome, and Commit messages all include signatures by the sender. - The client is authenticated by sending a signed ephemeral public PKE key in CH, and then proves possession of the PKE encrypted secret with the Finished message. - The server is authenticated by sending a signature that covers a hash of the KeyPackage. - Commits reauthenticates the sender as they are bound to the MLS state and a specific epoch and therefore cannot be replayed. Correct me if I got anything wrong, I easily get confused by some of the details of MLS. A future version of draft-housley-tls-using-mls-handshake should clearly explain this in more detail. The draft should also clarify which certificate chain the TLS implementation exports to the application. The text "use MLS key management and authentication in lieu of the traditional TLS 1.3 key management and authentication." make it sound as though the TLS Certificate message serve no purpose. Does the Certificate message contain the MLS credential or are they independent? >Updating exporter_master_secret is impossible. > >What EKU does is introduce a new API that explicitly specifies the >epoch to use, and tracks the epoch to use for sending. draft-housley-tls-using-mls-handshake needs to explicitly specify its key schedule behavior. As written, it updates the Handshake Secret, which may result in an updated exporter_secret and resumption_secret depending on the implementation. Cheers, John Preuß Mattsson From: Ilari Liusvaara <[email protected]> Date: Friday, 13 March 2026 at 22:07 To: [email protected] <[email protected]> Subject: [TLS] Re: Comments on draft-housley-tls-using-mls-handshake On Fri, Mar 13, 2026 at 07:26:18AM +0000, John Mattsson wrote: > Ilari Liusvaara wrote: > >However, if client does not have long-term key, that does not prevent > >attacker from using keys bled from either endpoint for hijacking the > >connection. > > > >I suppose it would be technically possible for client to send a > >temporary key for authenticating key updates if it does not have a > >long-term key. > > I would be supportive of non-Web work that focuses exclusively on > mTLS. I appreciate that draft-housley-tls-using-mls-handshake mandates > client authentication. Historically, both the absence of client > authentication and the use of resumption have caused security issues > in TLS. What I do not understand about draft-housley-tls-using-mls-handshake includes things like how the server is authenticated, and how the client is re-authenticated (to avoid replay attacks). > I believe it is preferable for draft-housley-tls-using-mls-handshake > not to update the exporter_master_secret and resumption_master_secret, > instead retaining the values derived from the initial Handshake > Secret. Updating exporter_master_secret is impossible. What EKU does is introduce a new API that explicitly specifies the epoch to use, and tracks the epoch to use for sending. > As both you and the FATT report have pointed out, updating these keys > introduces unnecessary complexity and issues. To my knowledge, DTLS > over SCTP is currently the only use case requiring continuous key > export, and in the long term, that deployment model should be > replaced by QUIC. It is not unnecessary complexity. The question is if it is needed for the threat model. And the FATT report found that in the threat model used in EKU draft, not only resumption_master_secret needs to be updated, but old sessions need to be revoked, which means stateful resumption. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
