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

On Tue, May 30, 2017 at 1:03 PM, Martin Rex <mrex@sap.com> wrote:
> Eric Rescorla wrote:
>> On Tue, May 23, 2017 at 9:34 PM, Martin Rex <mrex@sap.com> 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.

It's a substantial change made after WG last call. That alone makes it
improper. If you want to get WG consensus for such a change, go ahead.
But don't try making this in the dead of night.

>
>
>>
>>> 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).

TLS 1.2 demands extensions work. Sending a TLS 1.2 hello without
extensions is going to make it impossible to implement many features
TLS 1.2 security relies on.

>
> 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.

The people who have these problems are not "large parts" of the
install base. They are large parts of *your* install base. Don't
confuse these two.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.