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://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]
