
A Detailed Look at RFC 8446 (a.k.a. TLS 1.3) - jgrahamc
https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
======
CaliforniaKarl
One comment from the 0-RTT section concerns me a bit:

>This is a big deal, and once TLS 1.3 is widely deployed, the encrypted web is
sure to feel much snappier than before.

(If I understand correctly, "This" above refers to 0-RTT.)

Are web clients (such as web browsers, and agents like Cloudflare) using
0-RTT? I thought that 0-RTT was dangerous to use unless you were absolutely
sure that your use case would be immune to reply attacks.

In a place like Cloudflare, I could see 0-RTT being acceptable, because the
admin configuring Cloudflare for their site would know (and could specify)
which paths (like "/") would be safe to use with 0-RTT. But I did not think
web browsers could make such an assumption.

~~~
tialaramex
Browsers are being cautious here initially, e.g. certainly the Chrome "intent
to ship" post says they're doing ordinary 1RTT TLS 1.3 first

Each TLS application (e.g. HTTP) is expected to write up a "profile" if it
wants 0RTT which explains how to do it safely. The one for HTTP is currently
in draft. The most obvious thing is: truly idempotent operations are safe. GET
/favicon.ico looks pretty safe for example. If you log it, and bad guys can
cause you to log it more than once, well, OK, but so what?

On the other hand GET /database/delete/yes-really was already a bad idea
before 0RTT and there's an arguement that we should not help people shoot
themselves in the foot.

Since both sides need to agree to do it, if it turns out that the nice speed
up isn't worth the endless feet blown off by it we can expect web browsers to
just switch it off.

------
billpg
I was hoping to read an explanation of how encrypted SNI works. How can the
server know which key to use without knowing which domain is being asked for?

~~~
jgowdy
TLS 1.3 doesn’t currently have encrypted SNI. It’s a work in progress.

~~~
billpg
No wonder I couldn't find it.

------
ginsmar
Fantastic, good job.

