Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

I think I could be convinced in either direction right now.

It is definitely ugly and more of a nuisance to implement. The alternative
is a fallback and then painfully driving it out later. We've done that
before and we have FALLBACK_SCSV and the server_random trick now.

At the same time, I am rather bored of this fallback game. We can actually
avoid the intolerance problem with this mechanism. Suppose we used empty
indicator extensions, one for each new version. Then as long as servers
tolerate unknown extensions, we'll be fine. So far this has not rusted yet,
and we can defend it from rust by having clients send random fake
extensions out of a range of values we burn for this purpose[*] (or private
use area). If one extension with a list of values, we can do something
similar.

(Strictly speaking, the version already does not appear at a fixed position
because a ClientHello may be pathologically fragmented. OpenSSL even had
CVE-2014-3511 here. I believe the master branch no longer has a sniff-based
version negotiation. BoringSSL hasn't for a while now. But rejecting such
pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does
it now.)

David

[*] I'm planning on writing something up here soon.

On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote:
>
> > My opinion on this hasn't really changed since the last time. This seems
> > like it's more complicated and it's not clear to me why it won't lead to
> > exactly the same version intolerance problem in future.
>
> Doing version negotiation through extensions would be a major
> implementation burden.  At present the client version appears early
> in the ClientHello at a fixed position in the packet, and the server
> can quickly grab the version, compute the highest shared version
> and branch to the protocol implementation for that version to parse
> the rest of the ClientHello.
>
> Putting the client version in an extension dramatically complicates
> server-side processing.  So my view is that this would not be
> progress.  This is IMNSHO even less likely to interoperate than
> what we have now.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>