
More Privacy, Less Latency – Improved Handshakes in TLS v1.3 - ttaubert
https://timtaubert.de/blog/2015/11/more-privacy-less-latency-improved-handshakes-in-tls-13/
======
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.

~~~
r1ch
I'm hoping once QUIC matures that Google will release some open source Apache
/ nginx modules to support it. Development without any commercial incentive
seems to happen very slowly otherwise.

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

~~~
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.

~~~
quesera
> 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.

Destination IP will be the same for all sites on the server, SNI tells you
exactly which site was asked for. Not meaning to be pedantic, sometimes the
distinction isn't clear.

But in order to encrypt the SNI name, you'd first need to verify a certificate
tied to a bare IP address. You'd also need to trust DNS completely. RTT would
inflate significantly.

The CA system is a mess, but DNS is worse. Tying certs to bare IPs would
create a deployment nightmare as well.

SNI is imperfect, but it is a big improvement over the previous status quo,
which was single-IP per https host, which obviously did nothing to obscure the
site hostname either.

~~~
jimktrains2
> But in order to encrypt the SNI name, you'd first need to verify a
> certificate tied to a bare IP address.

Why wouldn't a DH exchange be enough?

~~~
quesera
You're right, DH might be enough, depending on goals.

The DH exchange would be MITMable, but not passively collectable. TLS is
(ideally) neither, so DH wouldn't provide an equal level of privacy.

Still, it would be a beneficial extension of the protocol. At the cost of an
additional TCP RT.

~~~
jimktrains2
Right, however, the MITM attack would also come at the cost of causing the
rest of the connection to fail. You could also do fun stuff like sending the
sha256-mac of the hostname using the DH key as the MAC key. There are lots of
fun ideas!

------
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.

~~~
keeperofdakeys
Where is "somewhere", the kernel only has a finite amount of memory. It's
still a denial of service, whether it occurs in the kernel, or a user-space
program. The point is that in order to service legitimate clients, the initial
request must be buffered somewhere.

For the 1rtt case, the request isn't sent till the TLS connection has been
established. The attackers would have to keep track of these TLS connections,
so this doesn't seem like a DoS vector.

For 0rtt the attackers might not need to keep track of state, allowing them to
simply send TLS 1.3 requests, and overload the server's memory. My question is
whether this is a legitimate concern.

