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

[Ilari Liusvaara <[e-mail]>]

On Sat, Jul 11, 2015 at 08:52:27AM -0400, Eric Rescorla wrote:
> I'm not necessarily opposed to relaxing this requirement on the server,
> but given that:
> 
> 1. SHA-1 is on its way out.
> 2. Future versions of TLS seem very likely to explicitly indicate which
> hash algorithms the clients support.
> 
> I'm kind of confused about the principle being espoused here. In general,
> when the client has told the server what's acceptable and the server
> doesn't have it, we abort the handshake. What makes this case different
> from (say) the client only supporting P256 and the server only supporting
> Curve25519 but deciding to send Curve25519 anyway?

The ECDH example involves something that will certainly blow up. Same with
the server signature itself being made with unsupported algorithm.

But with sending non-compliant certificates, the further up the chain the
non-complance is, the more likely client processing will terminate before
the client hits the "bad" signature and chokes. In some cases the last
thing client processes might even be the public key of the end-entity
certificate (never reaching the issuer signature of any certificate
in chain).


So if server wants to make last-ditch hail mary attempt, it would be
picking certificate chain that contains accepted algorithms as far
as possible (if it doesn't have EE certificate that can sign using
the indicated algorithms, it can abort right away because it is
not going to work[1]). It may or may not work, but at least it has
the greatest probability of working.


[1] Unless the client is buggy.


-Ilari