Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Brian Smith <[e-mail]>]

On Mon, Oct 20, 2014 at 4:53 AM, Martin Thomson <[e-mail]>
wrote:

> On 20 October 2014 04:47, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> > Indeed, there is an arguments to keep that mechanism, as there are still
> > some TLS 1.3 intolerant servers. But instead of prolonging the life of
> > such an insecure mechanism wouldn't it make sense to fix those broken
> > servers instead; e.g., by peer pressure by documenting the
> > implementations that are not TLS 1.3-ready in [0]?
>
> I think that we should do that, but as a practical matter, I suspect
> that we'll be stuck with some amount of fallback for a while yet.  I
> find the TLS 1.3 intolerance numbers pretty alarming in this regard;
> even with rapid improvement, I doubt it will go away quickly.


That's why the version negotiation mechanism for TLS 1.3 should be
different. We've already made the mistake 3 times of trying to use
ClientHello.client_version to negotiate versions and 3 times we've learned
that it has terrible compatibility issues. Why keep repeating that same
mistake? By negotiating TLS 1.3 with a new extension, and keeping
ClientHello.client_version = TLS 1.2 for TLS 1.3, you avoid the
compatibility costs without losing anything.

Also, even if we decide to keep making that mistake, browsers could stop
fallback for TLS 1.3 -> TLS 1.2, while dropping the rest.

Cheers,
Brian