Hi,
sorry for resurecting an old message on a fairly tangential point.
On 6/12/15 10:31, Ilari Liusvaara wrote:
AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
signature_algorithms).
(In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)
Either we're not talking about the same thing, or we don't read RFC 5246
in the same way. Section 7.4.2 (pages 47-48) says:
- The end entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange
algorithm.
Key Exchange Alg. Certificate Key Type
[...]
DHE_RSA RSA public key; [...]
To me that clearly means that if the server selects a DHE_RSA
ciphersuite, it MUST NOT use a certificate that contains an EC key, even
if the client offered ECDSA in the signature_algorithm extension.
However, in that case the certificate may be signed using ECDSA, which
is not the same.
Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is
quite clear about interaction of signature algorithms in ciphersuites
and explicit signature negotiation (explicit negotiation always takes
percedence).
I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about
what it says, which is ironic :) My understanding is that, regarding the
key in the server's certificate, there is indeed double negotiation,
with a clear rule that the set of allowed choices is the intersection of
what is allowed by the ciphersuite and what is allowed by the
signature_algorithms extension.
If the client has offered the "signature_algorithms" extension, the
signature algorithm and hash algorithm MUST be a pair listed in that
extension. Note that there is a possibility for inconsistencies
here. For instance, the client might offer DHE_DSS key exchange but
omit any DSA pairs from its "signature_algorithms" extension. In
order to negotiate correctly, the server MUST check any candidate
cipher suites against the "signature_algorithms" extension before
selecting them. This is somewhat inelegant but is a compromise
designed to minimize changes to the original cipher suite design.
To me, the "MUST check against" does not suggest "may still pick the
DHE_DSS suite and use an RSA cert with it if signature_algorithms
contains acceptable RSA pairs".
Regarding other signatures in the certificate chain, only
signature_algorithms apply, so there is no "double negotiation" indeed.
Of course, I wouldn't be surprised if there was fair bit of software
that got those rules wrong...
Regardless of whether your interpretation or mine is correct, I'm pretty
sure various implementations will do things in different ways here.
Anyway, a large proportion of servers deployments only have one cert, in
which case the RFC says "it [the server] SHOULD attempt to validate that
it [the certificate] meets these criteria", which may be interpreted as
an indication that the server may try to send its only certificate
anyway and let the client decide how to deal with it.
Manuel.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
