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.
0-RTT has to be supported by both sides in order to work. If a server receives a 0-RTT request under circumstances where it deems 0-RTT unsafe (such as one that modifies state), it can simply refuse to process the request and instead respond with the normal TLS handshake. If an attacker later tried to replay that request, the same thing would happen.
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.
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?
8 comments
[ 3.1 ms ] story [ 27.4 ms ] thread>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.
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.
[1]: https://tools.ietf.org/html/draft-rescorla-tls-esni-00