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

[Eric Rescorla <[e-mail]>]

On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Mar 23, 2017, at 10:31 AM, Fries, Steffen <[e-mail]>
> wrote:
> >
> > According to  TLS 1.2 section 7.4.1.4.1. a client may use the
> > signature_algorithm extension to signal any combinations the
> > client supports, listed in the order of preferences.
>
> The signature algorithm is primarily about signatures made as part
> of the TLS handshake, and not so much signatures in certificates.
>

This does not seem consistent with
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.2

"If the client provided a "signature_algorithms" extension, then all
certificates provided by
the server MUST be signed by a hash/signature algorithm pair that appears
in that extension."

I appreciate that there are people who feel that this rule is bad, and
to some extent it has been relaxed in 1.3, but I think the text is
pretty clear here.


> If the client does not use this extension, the server must use the
> > signature algorithm in combination with SHA1.
>
> For signing the TLS key exchange, however, it should still present
> whatever certificate chain it has, even if that chain employs SHA256.
> It is exceedingly unlikely these days that a client will not support
> SHA256 signatures in the certificate chain.
>

Yes, that's generally true. Though a TLS 1.2 client which does not offer
SHA-256
in its ClientHello but accepts SHA-256 is broken. So, this should generally
only happen with TLS 1.1 and below.



> Unfortunately the server is not allowed to use this extension, otherwise
> > he could tell the client his preferences according to his security
> policy.
>
> The protocol (as it should) lacks the additional round-trips necessary for
> the server to initiate signature algorithm negotiation.
>

I'm not sure quite what the OP Is trying to achieve here. For certificates
offered
by the server, the client just tells you what algorithms it will accept for
no negotiation
is needed. For certificates offered by the client, the server tells the
client
what algorithms it will accept in the CertificateRequest.
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4

-Ekr