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

[[e-mail] (Martin Rex)]

Henrik Grubbström wrote:
>  Martin Rex <[e-mail]> wrote:
>> The issue here is the (lack of the) TLSv1.2 signature_algorithms extension.
>>
>> Windows SChannel appears to treat the absence of this extension
>> the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,dsa)
>>
>> If you send the TLSv1.2 signature_algorithms extension with the
>> algorithm matching the signature of the server certificate, e.g.
>> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.
> 
> Sounds like it is complying with the TLS v1.2 RFC. Fix your client.


Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions.
SCHannel is violating a MUST requirement, failing to properly process
a ServerHello without a TLS extension.

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

https://tools.ietf.org/html/rfc2119#section-6

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.


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.

So the alleged requirement they're looking at is either not meant
the way they're reading it, or that requirement is simply VOID because
it is clearly incompatible with rfc2119 section 6.


What the implementor did not take into account is the warning sign
on the front of rfc5246, where it says "Proposed Standard",
which is explained by rfc2026:

http://tools.ietf.org/html/rfc2026#section-4.1.1

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.


-Martin