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. >> - 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. >> - 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). I was a bit unclear. I just meant a recommendation to, for example, choose the same AEAD, without introducing any technical changes. >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. Cheers, John Preuß Mattsson
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
