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

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

We saw enough TLS 1.2 clients that are non-compliant in this way that I made the server-side change to accommodate them.
Obviously, Martin Rex’s code is one example.
I’ve also seen a number of embedded/IoT-oriented TLS stacks that had this defect initially, when they first implemented TLS 1.2, although they were quick to fix.
Some of our customers in East Asia reported that the TLS stacks they used had this defect; when pointed at the RFC, they took the issue to the corresponding SW vendor(s).
Overall, a small percentage, but it generated enough support calls that the server change was worthwhile.

Cheers,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, March 23, 2017 9:58 AM
To: Fries, Steffen <steffen.fries@siemens.com>
Cc: TLS WG <tls@ietf.org>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen <steffen.fries@siemens.com<mailto:steffen.fries@siemens.com>> wrote:
Hi Erik,

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.

-          clients should always use the signature algorithm extension to ensure the server can apply a certificate with the appropriate crypt algorithms
Yes.

-Ekr

Best regards
Steffen

On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni <ietf-dane@dukhovni.org<mailto:ietf-dane@dukhovni.org>> wrote:

> On Mar 23, 2017, at 10:31 AM, Fries, Steffen <steffen.fries@siemens.com<mailto:steffen.fries@siemens.com>> 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

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls