On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:
> I'm afraid I don't understand this remark. There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.
"Send whatever it has" is the expected behaviour in the vast majority
of cases, i.e., for servers with just one certificate chain. I sure
hope that server implementation that abort instead of sending some
chain will be rare.
It is indeed a nuisance that even with curves for key agreement
split off into the separate "groups" extension, the "signature
algorithms" extension is still overloaded to serve two rather
different purposes:
1. Negotiate algorithms suitable for signing TLS handshake
messages.
2. Signal support for X.509 signature algorithms.
Using the same extension for both was perhaps a mistake. As pointed
out in this thread, X.509 admits more combinations for "2" than
TLS 1.3 does for "1". Consequently TLS 1.3 servers with multiple
chains to choose from might employ suboptimal algorithms in order
to match the client's supported signature algorithm extension, even
though a better choice is available, but was not or cannot be
signalled by the client.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
