Re: [TLS] Simpler backward compatibility rules for 0-RTT

[Martin Thomson <[e-mail]>]

I've added this option to my PR.  I've also weakened the deployment
requirement to a SHOULD in light of that.  I'll learn to live with the
bad taste that leaves :)

On 22 June 2016 at 12:31, David Benjamin <[e-mail]> wrote:
> On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson <[e-mail]>
> wrote:
>>
>> On 22 June 2016 at 10:30, Bill Frantz <[e-mail]> wrote:
>> > Well, it seems like a browser could try TLS 1.3 without 0-RTT first.
>> >
>> > If it connects with 1.3 non-0-RTT, then it could mark the host as not
>> > supporting 0-RTT for a day or so and after that time retry to see if the
>> > host has been fixed.
>>
>> Yes, that is an option.  Harder to manage, but certainly possible and
>> (overall) preferable to falling back to 1.2.
>
>
> Right, that (minus the statefulness because I don't care for adding state
> here) was exactly my intent with the specification text. Don't change the
> ClientHello version and only retry with the 0-RTT data dropped. It
> explicitly says "It is NOT RECOMMENDED to retry the connection in response
> to a more generic error or advertise lower versions of TLS."
>
> The version fallback is also inevitable (unless the version negotiation is
> moved elsewhere), but at least we can separate the two and someday retire
> the version fallback half.
>
> (Also, it's unlikely, but one could also imagine that the retry switches
> back to hitting a 1.3-capable server. Then changing the ClientHello version
> will trip fallback detection and the connection will fail again. Whereas
> retrying with only 0-RTT off is a handshake that will work against 1.2 and
> 1.3 servers alike.)
>
> I don't care much about the exact distribution of MAY/SHOULD/MUST, if that's
> all we disagree on. If we both agree that browsers will have to fallback, I
> want the mechanism written down somewhere. Because it's not obvious that
> this fallback may be triggered without a version downgrade and without a
> broad trigger, both of which have been problems with the past fallbacks.
> (The version downgrade has clear security implications and a broad trigger
> means debugging harder and, worse, it hides bugs. I've seen many cases of
> server software shipping new code that flat-out doesn't work but fallbacks
> are so easy to trigger that no one noticed.)
>
> Note that, since TLS stacks typically are not in charge of creating sockets,
> the implementation is the same with or without the fallback. The TLS stack
> needs to return a very specific error code (<= 1.2 ServerHello in response
> to 0-RTT ClientHello) and higher-level logic can condition on it as it
> pleases.
>
> David