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

[Watson Ladd <[e-mail]>]

On Oct 20, 2014 10:30 AM, "Brian Smith" <[e-mail]> wrote:
>
> 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.

After all these years you would think software vendors would test proper
version negotiation before release.

>
> Cheers,
> Brian
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>