Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

[Eric Rescorla <[e-mail]>]

On Thu, Mar 23, 2017 at 10:24 AM, Martin Rex <[e-mail]> wrote:

> Eric Rescorla wrote:
> >>
> >> based on your reply my conclusion is that
> >>
> >> -          there is no (standard compliant) way for a server to use a
> >> SHA256 based certificate for server side authentication in cases where
> the
> >> client does not provide the signature_algorithm extension
> >
> > Not quite. If the client offers TLS 1.1 or below, then you simply don't
> > know if it
> > will accept SHA-256 and you should send whatever you have. If the client
> > offers
> > TLS 1.2 and no signature_algorithm extension, then you technically are
> > forbidden
> > from sending it a SHA-256 certificate. Note that any client which in fact
> > supports
> > SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,
> > is noncomformant. It's not clear to me how many such clients in fact
> exist.
>
> rfc5246 makes it perfectly compliant for a TLSv1.2 client to support
> sha256-based signature algorithms and be willing to use them,
> and *NOT* send the TLS signature_algorithm extension.
>
> https://tools.ietf.org/html/rfc5246#appendix-E.2


Yes, I agree with this, if you use the v2 ClIENT-HELLO.

-Ekr

> -    clients should always use the signature algorithm extension to
> >> ensure the server can apply a certificate with the appropriate crypt
> >> algorithms
>
> Except that the vast majority of servers only has a single certificate,
> and will have to do "the right thing" in most situations anyway.
> The definition of the "signature_algorithms" extensions is
> sufficiently dense to say that you MUST not send it, except when
> ClientHello.client_version=(3,3), and it is not possible to send it
> when using a backwards-compatible SSL version 2 CLIENT-HELLO.
>
>
> -Martin
>