Subject: [TLS] Clarifictions for failure to agree on key sizes during hello

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Sep 2014 15:21:38 -0700

I am trying to figure out how this works and I find myself confused and not
able to make headway.

My view of the messages looks like the following:

(Yes I know that I have shortened the cipher suite strings and have defined
a new extension for ECDH parameters that I do not believe exists yet.)

ClientHello

                Cipher_suites = <TLS_DHE_RSA, TLS_DHE_DSS, TLS_ECDHE_RSA,
TLS_ECDHE_ECDSS>

                NegotiatedDHParams=<ffdhe2432, ffdhe4096>

                NegotiatedECDHParams=<P-256, P-521>

                ClientKeyExchange=<(dhe, ffdhe2432), (ecdh, P-256)>

ServerHello

Cipher_suite = ??????

NegotiatedDHParams = <ffdhe4096>

NegotiatedECHDParams = <P-521>

ClientHello

                Copy above with a different ClientKeyExchange extension.

I don't know what is going to be placed in the Cipher_suite field so that
the client can say - who there is a mismatch in the keys that I passed in,
but I should not expect to see a ServerkeyExchange message (which I might
not like).

Putting a cipher suite means that the client must check for an overlap
between the negotiated params extension for that suite to check for an
overlap between what the server returns and what it put into the client key
exchange record.

Putting a cipher suite means that the client might get locked into doing DH
in this case, when it would prefer doing ECDH for P-521 to doing  DH t 4096.

It was not clear to me from the document, but I think it is correct, that
the way this is handled is to use the negotiated params extensions to
declare what sizes I support, even if I did not send keys of that size to
start with.  

Putting a value into the cipher_suite field that is not in the client hello
list seems to be a bad idea, unless there is a specific value that says I
did not like the set of client keys you gave me to start with.  Since this
is not defined I assume that it is not there.  (as an example putting
TLS_DH_anon_* would be a disaster in the making.)

Jim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Sep 2014 15:41:26 -0700

On Mon, Sep 1, 2014 at 3:21 PM, Jim Schaad <[email-masked]> wrote:

> I am trying to figure out how this works and I find myself confused and
> not able to make headway.
>
>
>
> (Yes I know that I have shortened the cipher suite strings and have
> defined a new extension for ECDH parameters that I do not believe exists
> yet.)
>
>
>
> ClientHello
>
> I don’t know what is going to be placed in the Cipher_suite field so that
> the client can say – who there is a mismatch in the keys that I passed in,
> Putting a cipher suite means that the client might get locked into doing
> DH in this case, when it would prefer doing ECDH for P-521 to doing  DH t
> 4096.
>
>
>

If I understand your question, then I think the answer is: yes.

The client sends a list of all the ciphersuite and group values it supports
and then sends some subset of the keys in his CKE. The server then
selects the specific ciphersuite/group he wants. If the client has already
supplied a share for that, great. If not, the client needs to resent.

The intention is that this has the same negotiation properties as TLS
currently has, namely that the client announces all of his capabilities
and the server selects what he wants.

-Ekr

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Sep 2014 15:56:50 -0700

From: Eric Rescorla [mailto:[email-masked]] 
Sent: Monday, September 01, 2014 3:41 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [TLS] Clarifictions for failure to agree on key sizes during hello

On Mon, Sep 1, 2014 at 3:21 PM, Jim Schaad <[email-masked]> wrote:
I am trying to figure out how this works and I find myself confused and not able to make headway.
 
My view of the messages looks like the following:
(Yes I know that I have shortened the cipher suite strings and have defined a new extension for ECDH parameters that I do not believe exists yet.)
 
ClientHello
                Cipher_suites = <TLS_DHE_RSA, TLS_DHE_DSS, TLS_ECDHE_RSA, TLS_ECDHE_ECDSS>
                NegotiatedDHParams=<ffdhe2432, ffdhe4096>
                NegotiatedECDHParams=<P-256, P-521>
                ClientKeyExchange=<(dhe, ffdhe2432), (ecdh, P-256)>
 
                                                                                ServerHello
                                                                                                Cipher_suite = ??????
 
ClientHello

I don’t know what is going to be placed in the Cipher_suite field so that the client can say – who there is a mismatch in the keys that I passed in, but I should not expect to see a ServerkeyExchange message (which I might not like).
 
Putting a cipher suite means that the client must check for an overlap between the negotiated params extension for that suite to check for an overlap between what the server returns and what it put into the client key exchange record.

Putting a cipher suite means that the client might get locked into doing DH in this case, when it would prefer doing ECDH for P-521 to doing  DH t 4096.
 
It was not clear to me from the document, but I think it is correct, that the way this is handled is to use the negotiated params extensions to declare what sizes I support, even if I did not send keys of that size to start with.  

-Ekr

So just to be clear.  In this case the server would put TLS_RSA_DHE_ into the cipher suite field, and the client would understand that there is not going to be a server key exchange record because the lack of intersection between what it sent in the client key exchange record and the the negotiated_dhe_params extension returned from the server.  In this case the negotiated_ecdhe_params extension would not need to be sent from the server since it is extraneous information.

Jim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Sep 2014 16:06:19 -0700

>
>
> So just to be clear.  In this case the server would put TLS_RSA_DHE_ into
> the cipher suite field, and the client would understand that there is not
> going to be a server key exchange record because the lack of intersection
> between what it sent in the client key exchange record and the the
> negotiated_dhe_params extension returned from the server.  In this case the
> negotiated_ecdhe_params extension would not need to be sent from the server
> since it is extraneous information.

Affirmative.

-Ekr