On Sun, Mar 08, 2026 at 10:12:23PM +0000, John Mattsson wrote: > Ilari Liusvaara wrote: > >> - 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? > > Indeed. This could perhaps be addressed by mandating ECH.
I do not think that works, since this is a crypto-level extension, and such extensions do not play nice with ECH unless inner and outer matches. Which would defeat the entire point. > >> - 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. > > Seems this could be mitigated by disallowing credential updates. Looks like any update includes a new credential. > >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). > > This seems problematic. The client and server would need to agree > beforehand, or the client would have to keep trying until it finds > a supported one. The draft should describe this and specify what > kind of error message is sent in case of a mismatch. Any mechanism that involves prior agreement or retrying is going to be very problematic to many clients. And relying on prior agreement is also problematic. I think it is considered too unrelaible outside some small closed systems. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
