Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[[e-mail] (Martin Rex)]

Eric Rescorla wrote:
> On Tue, May 23, 2017 at 9:34 PM, Martin Rex <[e-mail]> wrote:
>>
>> This change _still_ prohibits the server from negotiating these algorithms
>> with TLSv1.1 and below.
>>
>> Could you elaborate a little on where and why you see a problem with this?
>>
> 
> For starters, TLS 1.3 has already designed a completely independent
> mechanism for doing version negotiation outside of ClientHello.version,
> so doing another seems pretty odd. In any case, it's not something you
> do between IETF-LC and IESG approval.

The suggestion to accept a recognized TLSv1.2 cipher suite code point
as an alternative indicator for the highest client-supported protocol
version is not really a "mechanism".  It's efficient (with 0-bytes on
the wire), intuitive and extremely backwards-compatible (will not upset
old servers, neither version-intolerant as the Win2008/2012 servers,
nor extension-intolerant servers.


> 
>> As this changes tries to explain, had such a text been used for all
>> TLSv1.2 AEAD cipher suite code points, then browsers would have never
>> needed any "downgrade dance" fallbacks, POODLE would have never
>> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
>> would not been needed, either.
> 
> I'm not sure this is true, because there were also servers which did
> not understand extensions.


It's worse -- there are still TLS servers out there which choke on
TLS extensions (and TLS server which choke on extension ordering).

Sending TLS extensions is therefore a negotiation scheme that we
can not ship as patch into the installed base, because we *KNOW*
that it will break a few existing usage scenarios.  Stuff that needs
TLS extensions is therefore an opt-in only scheme -- and even when
making it opt-in, we may have to additonally provide a TLS extension
exclusion list of hostnames.

It seems that there are others facing the same issue:

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows

and defer enabling to explicit customer opt-in.


Really, a very compatible and extremely robust and useful approach would
be to allow implied client protocol version indication through presence of
TLSv1.2-only cipher suite codepoints and this would allow large parts
of the installed base to quickly start using TLSv1.2--without breaking
existing usage scenarios and without the hazzle for users having to opt-in
and test stuff.


-Martin