Firefox 61

Posted Jun 27, 2018 2:35 UTC (Wed) by josh (subscriber, #17465)
Parent article: Firefox 61

To me, the most notable features in 61 seem like the faster rendering via further Quantum CSS work, and on-by-default support for TLS 1.3.

TLS 1.3 draft 28 (in practice all drafts 23 onwards)

Posted Jun 27, 2018 8:56 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (2 responses)

I'm a little bit wary of the enthusiasm for the TLS 1.3 drafts in actual deployed software. Drafts are deliberately incompatible with the finished specification (a mechanism that will be elided from the final RFC explains how to make yourself incompatible) and so these won't interoperate with actual TLS 1.3 implementations, quite purposefully since the final TLS 1.3 could in theory be entirely different (after all we thought this was almost finished in 2016...)

For web browsers the turnover is very fast, I'm sure Firefox 61 will be a vanishingly small proportion of all browsers by Christmas, but I worry that some idiots in the middle will fixate on a particular draft (like 23 or later since that's when the wire format froze more or less) and then manage to ship products that don't work with the actual TLS 1.3 RFC but do work with drafts. And then what do we do?

TLS 1.3 draft 28 (in practice all drafts 23 onwards)

Posted Jun 27, 2018 20:21 UTC (Wed) by xnor (guest, #125308) [Link] (1 responses)

What are you talking about? The last draft has been approved months ago. Previous drafts are incompatible and therefore the protocol handshake will fail, and then the application has to fall back to TLS 1.2.
I've been using TLS 1.3 for months now both server- and client-side and I haven't had a single problem, not even when I was mixing different draft versions on both ends long before that.

TLS 1.3 draft 28 (in practice all drafts 23 onwards)

Posted Jun 27, 2018 21:54 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

The current draft, 28, was approved by the Working Group and is now in the RFC Editor's queue. Nevertheless, until it's actually published as an RFC draft 28 remains a _draft_, and retains the language I described e.g. in section 4.2.1.1

ALL draft versions are incompatible, including draft 28, with each other and with a final TLS 1.3, the deliberate intent is that if you "mix different draft versions" you end up with TLS 1.2 (or an earlier version).

If you aren't expecting this, you are probably going to be badly disappointed.