On Sun, Mar 08, 2026 at 09:32:03AM +0000, John Mattsson wrote: > > 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.
Unfortunately, there are more problems than that... > 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) Unfortunately, that is impossible. The exporter_master_secret of active connection can not be changed due such change causing inevitable TOCTTOU bugs. All the complexity in EKU with exporters is essential (and IIRC, some critical stuff is still missing). And while would be possible to change resumption_master_secret, that is not enough, as the FATT comment pointed out that the existing resume keys need to be revoked, which implies stateful resumption. > - 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. Doesn't this expose client certificate in plaintext if using mTLS? > - 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. Unfortunately, the mechanism allows updating credentials, which is a major problem for many applications (e.g., HTTP/2 and HTTP/3). The biggest reason why HTTP/2 totally bans TLS 1.2 renegotiation and TLS 1.3 post-handshake authentication is those mechanisms allowing updating credentials. The specification requires client to send a fatal error if the server sends a post-handshake certificate request, even if the client indicated that it supports post-handshake authentication. > - 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. MLS and TLS cipher suites should not be tied to each other, as that would cause great deal of complexity. For similar reasons as to why TLS 1.2 ciphersuite negotiation is much more complex than TLS 1.3 ciphersuite negotiation (I have implemented both). And MLS cipher suites encompassing key exchange and signature algorithms is a major issue. Authentication can not be retroactively broken, while key exchange can (see "store now, decrypt later"). So "strength matching" the two is fundamentally wrong. It gets worse: There is seemingly only space for one KeyPacakge, and since there is only one ciphersuite per KeyPackage, that means that client can only send one MLS cipher suite. So the client must guess the signature algorithm the server is using (and for mTLS, have certificate with the same algorithm). -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
