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

[Dave Garrett <[e-mail]>]

On Friday, July 10, 2015 11:05:15 am Viktor Dukhovni wrote:
> Yes, when possible servers should provide a chain that is more
> likely to be understood by the client.  But refusing to provide
> the chain they have, just because the client did not disclose every
> signature algorithm it supports (or simply did not send any) is a
> mistake in the implementation and likely a design error in the
> specification.

A TLS 1.2 client is not capable of not indicating at least some set of support. (unless it sends an invalid empty extension)

https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

   If the client supports only the default hash and signature algorithms
   (listed in this section), it MAY omit the signature_algorithms
   extension.  If the client does not support the default algorithms, or
   supports other hash and signature algorithms (and it is willing to
   use them for verifying messages sent by the server, i.e., server
   certificates and server key exchange), it MUST send the
   signature_algorithms extension, listing the algorithms it is willing
   to accept.

   If the client does not send the signature_algorithms extension, the
   server MUST do the following:
   [use SHA1 defaults]

The only instance a TLS 1.2 client is allowed to omit the extension is when it only support the defaults. If it doesn't support the default or supports something else (or both) then it MUST send the extension. The server MUST interpret the lack of an extension as equivalent to sending SHA1 support. A client not sending the extension is telling the server not to send it anything other than SHA1.

Yes, it doesn't explicitly say what the server should do when the client has not indicated support for anything it has, but a client is in the wrong for not indicating it. The client side is a spec error; the server side is just problematic.


Dave