Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[[e-mail] (Martin Rex)]

Watson Ladd wrote:
> 
>>
>> https://tools.ietf.org/html/rfc5246#section-7.4.1.2
>>
>>   7.4.1.2  ClientHello
>>
>>    extensions
>>       Clients MAY request extended functionality from servers by sending
>>       data in the extensions field.  The actual "Extension" format is
>>       defined in Section 7.4.1.4.
>>
>>
>>                                       A server MUST accept ClientHello
>>    messages both with and without the extensions field,
>>
>>
>> The interpretation of rfc5246 that Microsoft is using to explain the
>> broken behaviour is in clear conflict with rfc2119 section 6
> 
>
> ECDHE support requires sending extensions.

This claim is also clearly invalid.

Btw. rfc4492 is *NOT* a standard, and implementing TLSv1.2 does not
require support for ECC (and neither does TLSv1.2 require support
for any AES-GCM cipher suites).

Our TLSv1.2 client, where we noticed the Microsoft SChannel goof,
does neither implement ECC nor AES-GCM.


rfc4492 says:

4.  TLS Extensions for ECC

   Two new TLS extensions are defined in this specification: (i) the
   Supported Elliptic Curves Extension, and (ii) the Supported Point
   Formats Extension.  These allow negotiating the use of specific
   curves and point formats (e.g., compressed vs. uncompressed,
   respectively) during a handshake starting a new session.  These
   extensions are especially relevant for constrained clients that may
   only support a limited number of curves or point formats.


   A TLS client that proposes ECC cipher suites in its ClientHello
   message SHOULD include these extensions.

                                                        A client that
   proposes ECC cipher suites may choose not to include these
   extensions. 

rfc4492 is a little inconsistent here, because it uses both
"SHOULD" and "may" for the very same client behaviour.



> A server configured to only support ECDHE
> ciphersuites will fail any handshake that doesn't contain the
> necessary extensions. You cannot expect psychic servers to negotiate
> unadvertised features.
> 
> Why can't you advertise support for the signatures you in fact
> support, if you want to advertise support?


Because sending TLS extensions is backwards incompatible behaviour when
you have never sent TLS extensions before, and it will cause some
interop scenarios to fail.  We are not allowed to ship backwards-incompatible
behaviour that breaks existing usage scenarios as patch into the installed
base.  For the very same reason, the use of protocol version > TLSv1.0
on outgoing connections is a pure opt-in.

>>
>> Requiring a server admin to continue using a sha1WithRsaEncryption
>> signed certificate and failing the handshake when a sha256WithRsaEncryption
>> signed certificate is installed, or alternatively requiring the server
>> admin to disable TLSv1.2 (which happens to be the default in Win7/2008R2)
>> is a dumb idea and actively causing harm.
> 
> If clients don't support sha256WithRsaEncryption, they won't work with
> that server. The problem is clients failing to advertise features,
> then their authors complaining about lack of psychic abilities on the
> behalf of servers.

So what.  Leave the matter of dealing with a sha256WithRsaEncryption
certificate to the client.  This is particularly true for the extremely
unhelpful SSL Alert that is meant to be used here (handshake_failure),
and doubly so for Microsoft IIS -- which does not put any alerts
on the wire before closing the connection.

The latter might not be a problem of SChannel, which seems to create
the alerts and potentially offers them at the SSPI interface, but might
a flaw of the SChannel SSP application callers (Microsoft IIS, MSIE),
to process a token that is returned from a context iterator
(InitializeSecurityContext / AcceptSecurityContex) along with
an SSPI error code.


-Martin