[mtgx]

Which is why it should have never been implemented in TLS 1.3.

I believe the argument against not doing it was that some companies will just implement their own protocols instead. Eh, I think the chances of that happening were pretty slim. Now most of the problems we'll see with TLS 1.3 will likely be related to 0-RTT.

Also, wasn't that basically the same argument for implementing MITM in TLS 1.3? That if they don't do it the banks and middlebox guys will just stick to TLS 1.2 or whatever?

And who cares about a little bit of an extra HTTPS delay, when just adding Google analytics and Facebook Pixel to your site can increase the delay by over 400 ms? Some poor performance tracking tracking scripts add 800 ms on their own.

[wereHamster]

0rtt is still useful for static assets, and generally everything that is public. I have a handful of static websites (literally static, as in consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no longer used to only protect private pages (eg. access to your private emails, the admin section of a CMS). It's also used for privacy reasons on completely public websites.

[cesarb]

Wouldn't that be a bit of a privacy leak? If 0rrt works, it was a request for a static asset.

Of course, TLS is not only for privacy reasons, but also for integrity reasons (preventing injection of malicious Javascript and similar attacks). For that purpose, 0rtt for static assets works fine.

[minitech]

> Wouldn't that be a bit of a privacy leak? If 0rrt works, it was a request for a static asset.

Response size and timing probably already leak this.

[nfoz]

This honestly really bothers me.

We're encrypting everything, we have "Let's Encrypt", we have browsers telling users that their connections are "secure".

Meanwhile your DNS lookups are public (which leaks what site you're accessing) and size+timing analysis leaks which static assets you've retrieved. Which gives away for example what article you're reading on what news site. Which the site itself is telling google, facebook and other malicious third-parties anyway...

How is anyone supposed to understand digital privacy? Everything sucks, and I'm not even sure what could be done to make it suck less.

[adrianN]

I think for the average user, the authentication part is a lot more important than the encryption part unless they're entering passwords. I want to be relatively sure that the site I'm visiting hasn't been replaced by something serving malware. I don't care as much about people knowing which articles I read.

[zaarn]

For DNS lookups we're having people testing out DNS-over-HTTPS which would solve this entirely, lookups would be opaque to anyone but the DNS server involved.

For timing and size you can usually do something about it as a site owner (HTTP/2 for example will multiplex connections so it makes timing and size comparisons much harder)

[thisacctforreal]

Even without encrypted DNS lookups, HTTPS leaks the FQDN (i.e. exact subdomain) of what you are connecting to through Server Name Indication.

SNI was added to allow servers to know which SSL certificate to send to the browser, previously you would need to have one IP address per SSL certificate.

[nfoz]

Just to be clear, 0rtt is only for "revisits", and for revisits of static assets the client is likely to have the asset cached still. So the only benefit is if the "static" asset has changed, or the client's cache is cleared. Which seems less useful.

[jensvdh]

The content of your page may be encrypted but the DNS lookup isn't

[zackbloom]

There's work now with DNS-over-HTTPS to prevent that.

[thisacctforreal]

As well as SNI

[ori_b]

Tls connection reuse already works for that. And pipelining in http.

[bastawhiz]

> And who cares about a little bit of an extra HTTPS delay, when just adding Google analytics and Facebook Pixel to your site can increase the delay by over 400 ms?

That's how you might feel if you live with fast broadband internet. A lot of the world is stuck with high latency, low-bandwidth connections. Applications that are incredibly lean will still be slow if the server is in San Jose and the client is in, say, Uganda.

[ryanworl]

I run a very large number of web performance tests and GA and the Facebook pixel do not add 400ms either alone or together of user-perceptible speed decreases. They will take some small amount of main thread time for parse and compile, but they are loaded async and generally not performance problems on the (hundreds) of pages I have profiled.

Intercom and other live chat solutions are typically the biggest offenders on modern pages. They serve 10-20x the script as GA and the Facebook pixel.

[mikeytown2]

GA and FB-P both effect the document complete time; but your right, there are way way worse scripts out there.