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

[Eric Rescorla <[e-mail]>]

This makes a certain amount of sense (though I wonder how often it's really
an issue that a server declines to send a certificate that would otherwise
have worked to a compliant client [0]).

Perhaps the right text here is that if you have a conformant certificate,
you
MUST send it, but if not, you MAY send a nonconformant one?

-Ekr

[0] As you say, with a buggy client all bets are off.


On Sat, Jul 11, 2015 at 9:45 AM, Ilari Liusvaara <
[e-mail]> wrote:

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