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]
