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. Most of my TLS/DTLS/QUIC use cases involve infrastructure mTLS, where identity protection and optimizations such as resumption, 0-RTT, and small certificate messages are not critical. In those environments, SLH-DSA certificate chains would be acceptable. 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. 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. draft-housley-tls-using-mls-handshake states: >then the stale keying material can safely be discarded. I believe this requires much stronger language. Suggestion: Stale keying material, including previous Handshake Secret, Master Secret, and application traffic secrets, MUST be destroyed (zeroized) as soon as possible. Cheers, John Preuß Mattsson From: Ilari Liusvaara <[email protected]> Date: Thursday, 12 March 2026 at 22:15 To: [email protected] <[email protected]> Subject: [TLS] Re: Comments on draft-housley-tls-using-mls-handshake On Tue, Mar 10, 2026 at 11:52:29PM +0000, John Mattsson wrote: > Ilari Liusvaara wrote: > >E.g., a new mechanism that can change client identity would be insecure > >with HTTP/2 and HTTP/3. > > I agree that none of the mechanisms should allow changes to the client > or server identity. > > Ilari Liusvaara wrote: > >What I meant is that there does not seem to be much simpler way to do > >what EKU does. > > A major problem with the current EKU draft is that mutual > reauthentication requires changes to the application layer. And if > application-layer modifications are possible, it is simpler to > establish subsequent overlapping connections, similar to > reauthentication in IPsec. > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.strongswan.org%2Fdocs%2Flatest%2Fconfig%2Frekeying.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C9678aa1242934ca92be708de807c75c8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639089469208257022%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ko4%2FcAR%2BpgywzpAHhjR4OFU7OBSyIbuuQ4mfhi09m6s%3D&reserved=0<https://docs.strongswan.org/docs/latest/config/rekeying.html> It could be possible to add signatures from both peers using previous long-term key (if any). The only situation I can come up with where that would help is attacker bleeding the session keys, and then becoming a MITM, rewriting any rekeys. 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. > >As to why I think the threat model is dubious: It seems to be aimed at > >risk of old secrets being exposed, which I think is very rare. Re- > >authentication would at least help against bleeding-type attacks, but > >AFAIK those are rare compared to RCE-type attacks (or compromising the > >whole TCB). > > > >As to keeping long-term key in TEE, but application traffic secrets > >outside it... Keeping application traffic secrets in TEE is not > >feasible, due to TEE limitations and latency. > > > >It is also not feasible to use hardware memory protection, because the > >memory overheads are prohibitive (even without the current RAM > >shortage). > > My view on the threat model: > > It is common to protect the signature key more strongly than the > session keys. This can be achieved in several ways, such as using > an HSM, TPM, TEE, or privilege separation. Therefore, it is reasonable > to assume that session keys might be compromised while the signature > key remains secure. Yes, doing that is not hard. > I assume that an MLS implementation could, and maybe should, > protect the private KEM keys more strongly than the session > keys. I think this requires security considerations in the > drafts. The private KEM keys live for very short period anyway. And details on how rekeying works are actually relevant here. Protecting the KEM keys requires four-message rekey, it does not work with three-message rekey. But protecting session keys is not an option due to the existing rekey mechanism in RFC8446. > draft-tian-quic-quicmls-00 states: > >MLS provides authenticated key agreement > > My understanding is that for the initial shared secret established > via KeyPackage and Welcome, MLS provides key transport rather than > key agreement. MLS in TLS/QUIC provides key agreement for the derived > secrets. I think the drafts should clarify this distinction and > explain that ClientHello.random remains important for ensuring the > intended security properties. Briefly looking at draft-tian-quic-quicmls-00, it looks to work in somewhat different way from draft-housley-tls-using-mls-handshake. I still do not get how draft-housley-tls-using-mls-handshake is supposed to work (even ignoring any negotiation issues). And yes, MLS provides key transport, not key agreement. -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]
