Hi, Thanks to Konrad, Britta, Russ, et al. for driving this set of drafts. I find this approach much easier to analyze than Extended Key Update. It leverages the formally verified MLS for keying and authentication of the TLS record layer, while the TLS handshake is used for ciphersuite negotiation. Any potential problems would be in the composition between MLS and TLS 1.3.
A few comments and suggestions, please correct me if I misunderstood something: - The draft should explicitly explain that a Commit message updates the exporter_master_secret and the resumption_master_secret. As an alternative to updating, one could even specify: TLS-Exporter(label, context_value, key_length) = MLS-Exporter(label, context, length) - When doing resumption, it is unclear which tickets or resumption secrets can be used. This is mostly an implementation consideration regarding how many resumption_master_secrets need to be stored. The resumption secret does not appear critical for security, as security is based on the two Commits. It may be possible to set the resumption secret to zeros without reducing security. - The draft should clarify that, during resumption, the first Commit is sent unencrypted unless ECH is employed. Encrypting the key exchange ensures that an attacker must compromise epochs sequentially, strengthening security. - Normal MTLS 1.3 performs authentication in flights 2 and 3. This draft moves it earlier (flights 1 and 2). The draft should describe this change. - The draft should emphasize that it introduces much-needed in-band reauthentication to TLS 1.3. As highlighted in RFC 4478, reauthentication is a valuable property on its own and is likely critical for achieving strong rekeying guarantees. Forcing rekeying and reauthentication to be used together, as this draft and MLS do, appears to be a particularly sound design choice. - The draft should provide more detail on FS and PCS. Compared to RFC 8446, there are now new asymmetric keys that live for some time and might be compromised. Compromise of these asymmetric keys affects both past and future session keys until a Commit in the opposite direction is performed. - Are the MLS and TLS ciphersuites independent of each other, or should the TLS ciphersuite be at least as strong as the MLS ciphersuite? The draft should explicitly distinguish between “MLS cipher suite” and “TLS cipher suite” rather than using the generic term “cipher suite,” to avoid ambiguity. - The security considerations could be expanded. Cheers, John Preuß Mattsson On 2026-02-05, 20:03, "[email protected]" <[email protected]> wrote: Internet-Draft draft-housley-tls-using-mls-handshake-00.txt is now available. Title: Using the MLS Handshake in TLS 1.3 Author: Russ Housley Name: draft-housley-tls-using-mls-handshake-00.txt Pages: 13 Dates: 2026-02-05 Abstract: This document specifies an extension to the Transport Layer Security (TLS) Protocol Version 1.3 that allows TLS clients and servers to use the Message Layer Security (MLS) Protocol handshake to establish the shared secret instead to the traditional shared secret establishment mechanism. The MLS protocol provides straightforward mechanism to update the shared secret that can be initiated by either the client or the server during the TLS session, and each epoch provides forward security and post-compromise security. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-housley-tls-using-mls-handshake/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-housley-tls-using-mls-handshake-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
