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

[[e-mail] (Martin Rex)]

Watson Ladd wrote:
>Martin Rex <[e-mail]> wrote:
>>
>> 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.

The proposed small addition of when the TLS cipher suites can be negotiated
is clearly *NOT* a change, and certainly not substantial.

Implementors that want to completely ignore this small addition
can do so and will remain fully compliant, they will not have to
change a single line of code.

For those implementing the proposed addition there will be two
very desirable effects:

  1) make more TLS handshakes succeed

  2) make more TLS handshakes use TLS protocol version TLSv1.2 rather
     than TLSv1.1 or TLSv1.0

come at an extremely low cost, and this addition has ZERO downsides.
The IETF is about promoting interoperability.

You seem to have a problem with either or both of the above outcomes,
but I fail to understand which and why.


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

Actually, it does not.  TLSv1.2 works just fine without TLS extension,
although there are a few implementations in the installed base which
got this wrong.  rfc5246 appendix E.2 shows that TLSv1.2 interop with
extension-less ClientHellos was desired and assumed to be possible.
Some implementors got it wrong.



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

The above WinHTTP issue alone applies to Win7, which is about 50% of
the installed base of Desktops PCs.

Refering to ~50% of the installed base as "large parts" seems OK to me. YMMV.


-Martin