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 11:37:44AM -0400, Dave Garrett wrote:

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

Suppose the server's certificate is signed with SHAKE256, but the
client has no idea that SHA256 exists.  Suppose also the client is
doing opportunistic (unauthenticated TLS) or using DANE TLSA with
the server's certificate binding published in a DANE-EE(3) digest.

Then the client does not care what signatures may or may not be
present in the server certificate.  And yet the specification
demands that the server abort the handshake.  The specification is
wrong, and implementations that follow it are not well thought out.

With time we learn to ignore some elements of specifications that
don't make sense.  This is one such element.

Perhaps it is not too late to fix this in 1.3, so that the
specification does not demand unreasonable server behaviour.

-- 
	Viktor.