Hi Viktor,
thanks for the response, I replied inline.
> 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.
[[stf]] In general I agree, but section 7.4.2 directly relates to certificates
used by the server:
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.
Based on that I concluded the same restriction (fallback to SHA1) regarding the
absence of the signature_algorithm extension applies for the certificates.
> 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.
[[stf]] This is true, specifically, if the client offered SHA256 cipher suites
> This may lead to an error on the client side when validating the
> certificate.
You really should not even deploy SHA1 certificates these days, though some
sites are still using their legacy SHA1 certificates that have not yet expired.
[[stf]] Completely agree. I was curious if there is an option to signal to the
client that the server is not willing to support outdated algorithms
explicitly, rather than using a SHA256 based cert, which may lead to an error
in a legacy client, it it does not support SHA256.
> 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.
[[stf]] Yes, realized that. It gets better in TLS1.3
> Is there a standard compliant way to utilize SHA256 based certificates
> on the server side even when a client does not signal additional
> signature algorithms?
Yes, just use them regardless of the client's signature algorithm extension.
See the TLS 1.3 draft for improved language about the interaction of signature
algorithms and certificates.
[[stf]] That is the point I stumbled about. The text in 7.4.2 describes what a
server must do, when a client uses the signature algorithm extension, but does
not describe the supported behavior if the client does not use this extension.
It somehow implies that the server shall behave like described for the cipher
suite case (section 7.4.1.4.1). From a security perspective I completely agree,
one should not use outdated crypto.
Best regards
Steffen
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
