Negotiating 0-RTT means that the server has 1.3 everywhere. #502
Conversation
The text that @davidben proposed that covered 0-RTT and backward compatibility took the position that a server might not support TLS 1.3 when it was attempted. That leads to all sorts of mess, particularly given that most 1.2 and earlier servers are totally incapable of handling 0-RTT messages. In NSS, it's a fatal error and I would expect others to be similarly strict given the smackTLS work. This is a simpler set of rules: * If the server advertises support for 0-RTT that means that it commits to supporting TLS 1.3 for the duration. * If the client attempts 0-RTT, then it should abort if it sees a ServerHello with 1.2 or earlier. This is stricter than what we currently have, but it's crisper. That is, unless people imagine modifying their TLS 1.2 implementations to be able to ignore 0-RTT data,
|
What's the smackTLS work's relevance here? Our two versions of the text have no difference to the TLS stack itself. In both cases, the TLS stack treats a 1.2 ServerHello as a fatal error. The only difference is I'm proposing the latter fail with a specific error code that higher-level logic can use to trigger a fallback. I really dislike fallbacks, but the alternative seems worse to me. It's not just servers. One might bring a work device with MITM proxy home. Or perhaps toggle antivirus on and off. Or other weird behaviors. (MITM proxies are also terrible, but they're a reality, unfortunately.) It's true the failures, if any, will be rare, but they will be non-deterministic which is the worst kind of failure. (Of course, unless we change the version negotiation, we'll end up with a version fallback anyway. My intent here was that the 0-RTT fallback not be the same as the version fallback. Getting rid of the old version fallback was tricky due to lots of confounding factors.) |
There were some implementations that would happily pass cleartext records if they arrived before the handshake completed.
Oh, I didn't get that from reading it. This PR makes it much clearer though. I do agree about the specific error code though and had intended to implement a new code for this. As for fallback, I expect that browsers will be stuck doing that sort of shameful thing, but we have to ask how much we want to encourage that by blessing it. If you are suggesting that 0-RTT will lead to a new form of intolerance, I suppose that is true, and I guess that it is more easily detectable with the specific error code. I guess where we disagree is over how much to write in the spec about fallback. |
...lovely. Good job, everyone. Although such a server would still read as expected, right? The 1.2 ServerHello will come in before any arbitrarily weird
Yeah, the current text doesn't make that very clear. The specification doesn't "know" that TLS stacks usually aren't responsible for making connections (maybe you're doing something crazy like an HTTP CONNECT proxy) and so any kind of retry necessarily must be external.
shrug Whatever works I suppose. |
Yeah, they will probably just fail on the second flight like any other 1.2 server. |
|
(I also would not lose any sleep over breaking those servers.) |
|
+1. The new text is much clearer than my version. (And, yeah, I hate that we have to do this too. :-( ) |
The text that @davidben proposed that covered 0-RTT and backward
compatibility took the position that a server might not support
TLS 1.3 when it was attempted. That leads to all sorts of mess,
particularly given that most 1.2 and earlier servers are totally
incapable of handling 0-RTT messages. In NSS, it's a fatal
error and I would expect others to be similarly strict given the
smackTLS work.
This is a simpler set of rules:
commits to supporting TLS 1.3 for the duration.
a ServerHello with 1.2 or earlier.
This is stricter than what we currently have, but it's crisper.
That is, unless people imagine modifying their TLS 1.2
implementations to be able to ignore 0-RTT data,