Re: [TLS] A la carte handshake negotiation

[Eric Rescorla <[e-mail]>]

On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>