On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard <m...@elzevir.fr> wrote:
> 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. This is how I understand the situation as well. I am sad to hear that we didn't manage to make the document clear on this point. -Ekr > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
