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

[Viktor Dukhovni <[e-mail]>]

On Fri, Jul 10, 2015 at 07:44:35AM -0700, Watson Ladd wrote:

> > 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.
> 
> Specific overrules general.

While I don't agree with the line of argument that Martin takes to
support his position, I still agree with the conclusion that the
Schannel behaviour is unfortunate.  

If the client does not signal the signature algorithms extension,
and the server's chain is not SHA-1, it should use whatever chain
it has.  Withholding the chain the server has is counterproductive.

Yes, extensions are needed to negotiate the use of SHA2-256 for
TLS MAC computations, but forcing the certificate chain signatures
issued by arms-length CAs to agree with the client's preference for
message MAC algorithms is I think needless restrictive.  

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.

I encourage implementations to ignore the MUST in question, and
respond with some default chain even if it does not match the
client's signature algorithms extension.  The client may well be
able to handle the new chain, or may not even care about the CA
signatures at all (e.g. opportunistic TLS or DANE-EE(3)).

-- 
	Viktor.