On Mon, Mar 18, 2024 at 06:46:51PM +0000, John Mattsson wrote: > Hi, > > I thought the old version was a quite good starting point. This new > version seems significantly worse. I think it has three major > problems: > > 1. It uses the application layer and therefore requires changes in the > application layer. For many uses of TLS, it is not acceptable to > change the application layer.
I expect that in many applications, it is not even possible to change the application layer. > 3. I don't see the need for HPKE. All discussions, specifications, > and deployments of PQC KEMs in TLS 1.3 and DTLS 1.3 uses the ordinary > "KeyShareEntry". Replacing the existing key exchange mechanism in TLS > with the public key encryption mechanism HPKE. This seems to add a > lot of code to an TLS implementation already doing quantum-resistant > key exchange in the initial handshake. Yes, using existing TLS mechanisms is much easier for implementations. > I think a solution to do post-handshake ephemeral-ephemeral key > exchange as well as mutual post-handshake authentication on the > TLS/DTLS/QUIC layer would be very welcome. I think ephemeral- > ephemeral key exchange as well as not using the application layer > should be requirements. Note that TLS-level post-handshake authentication has very nontrivial implications on application protocols. E.g., HTTP/2 explicitly bans TLS post-handshake authentication for very good reasons. For supporting application-layer authentication, there already are TLS exporter and exported authenticators. For EE key exchange, TLS is the relatively easy case. Everything in TLS is in-order and lossless. The only possible race condition is the crossed update, and it is easy to make both sides agree that happened. DTLS is much more difficult due to all the race conditions caused by reordering and packet loss. Which is something TLS does not have to deal with, and is especially problematic with the crossed update case. And while QUIC is based on TLS, it replaces some of the key parts this mechanism touches. Which means it has to have its own version. And looks like it has to deal with similar problems (reordering and packet loss) as DTLS does. > I think frequent rekeying with ephemeral-ephemeral key exchange is a > must for long-lived interfaces. This has for a long time been an > established requirement. Typical requirements are 1 hour of 100 GB in > IPsec and 1 hour or 1 GB in SSH. Note that there is no problem with > TLS 1.3 when you can frequently setup new connection with psk_dhe_ke. > Discussing with Eric Rescorla and Martin Thomson in the past, they > suggested that this was the way forward. It would be interesting to > hear if there are more use cases than RFC 6083 where frequently > setting up a new connection with psk_dhe_ke is problematic. I expect > there is. Any application that associates resources with connection poses major problems with setting up new connections. While I don't think anybody uses it with TLS, up until recently BGP (extremely important, to put it mildly) was infamous of recting very badly to connection loss. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
