More Privacy, Less Latency – Improved Handshakes in TLS v1.3

[emielm]

0rtt is going to make a huge perceived difference on high latency (mobile) links. Don't forget however that the syn/ack tcp connection setup also still has an additional 1rtt overhead. For this reason, I'm still rooting for Google's QUIC to get towards standardization and mainstream adoption.

[netheril96]

QUIC is indeed nice. As a Chinese who frequently browses Google with a VPN and therefore high latency, the difference between loading Google in Chrome and in other browsers is palpable.

But I have not seen any adoption of QUIC either in clients or servers, outside the Google's circle.

[kardos]

Regarding more privacy: have they found a way to keep the SNI information private?

[praseodym]

SNI is the "server_name" extension in the ClientHello message, which is not encrypted. So no, looks like there are no changes to this in TLS 1.3.

Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.

[AndyMcConachie]

I don't think this is possible. I can have different TLS configs for each vhost I set up on a single HTTP instance. And until the SNI is sent the server has no way of knowing which vhost to use.

Also SNI needs to match the hostname specified in the X.509 part of the cert. Certs are issued based on DNS names which need to correspond to SNI.

I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.

[keeperofdakeys]

I'm wondering if the 0-RTT mode brings any issues with DDoS attacks. Since the request is sent in the initial TLS request, the server must buffer it, or create a response before it finishes the handshake. Admittedly it's not UDP, so you still need to successfully perform a TCP handshake (ie: verify the reverse path).

[stingraycharles]

Wouldn't proper application design just wait to read the actual content / request from the socket? As in, this will most likely be buffered somewhere in the kernel TCP stack, and not in the application, making the situation comparable to 1rtt from a DoS perspective.

[viraptor]

TLS is really just higher version of SSL. Your comment reads like there's some significant difference between them. Tls actually fixed known ssl issues, so whether you like it or not, originall SSL is just insecure. I'm not sure what you mean by running TLS for SSH - they're quite separate.

[dgoldstein0]

all the problems you call out are implementation bugs, not specification bugs. If people can't implement it right, it's not the spec's fault - though we should definitely strive for "easy to implement". "Freezing TLS" doesn't really make sense either - you'll probably be able to use TLS 1.1/1.2 for years to come, and it takes a LONG time for a new version of the protocol to roll out and gain support. If a TLS implementation wanted to focus on bugs and quality instead of implementing new features, they totally could.