Subject: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 16 Jan 2015 15:26:59 +0000

Hi all,

It seems to be fine to improve inter-operability (or efficiency: less back and forth) by allowing multiple groups (multiple "NamedGroup"s) in the "HelloRetryRequest" message since a server might be willing to accept 2 (or more) groups for a particular key exchange method. For example,  a client might offer only one FFDH group in its Client Key Share message and the server is willing to offer two higher level security groups for the client to choose from.

The situation would be similar if we had 3 or more curves.

Quynh.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Jan 2015 07:44:44 -0800

Note that the client advertises all the groups it can support, so the server
can just pick the "best" one on the clients list.

-Ekr

On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh <[email-masked]> wrote:

>  Hi all,
>
>
>  It seems to be fine to improve inter-operability (or efficiency: less
> back and forth) by allowing multiple groups (multiple "NamedGroup"s) in the
> "HelloRetryRequest" message since a server might be willing to accept 2 (or
> more) groups for a particular key exchange method. For example,  a client
> might offer only one FFDH group in its Client Key Share message and the
> server is willing to offer two higher level security groups for the client
> to choose from.
>
>

---

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 16 Jan 2015 15:51:21 +0000

?If a client offers all of the options it supports and a server sends back one group out of these options, it would guarantee a failure.

Quynh.

________________________________
From: Eric Rescorla <[email-masked]>
Sent: Friday, January 16, 2015 10:44 AM
To: Dang, Quynh
Cc: [email-masked]
Subject: Re: Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

-Ekr

On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Quynh.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jan 2015 08:29:50 -0800

> can just pick the "best" one on the clients list.

I think what Quynh wants is to turn the HelloRetryRequest into an advertisement for the server's capabilities, and having that advertisement be longer than 1 would be better. That is, it would be "We're failing and I'm choosing none of yours, but if you retry and can do any of these, please do so".

I'm not saying I like that idea, and I waffled a lot on it in IKEv2, but it is a common proposal for how to do negotiation (as compared to "offer-pick").

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Jan 2015 08:33:07 -0800

On Fri, Jan 16, 2015 at 7:51 AM, Dang, Quynh <[email-masked]> wrote:

>  ​If a client offers all of the options it supports and a server sends
> back one group out of these options, it would guarantee a failure.
>

I don't understand. The client sends a list of all the groups it supports
and a ClientKeyShare with a subset of those groups. If the server doesn't
support any group in the ClientKeyShare it sends back HRR with a single
group out of the clients larger set that the client needs to respond with.
How does that guarantee a failure?

-Ekr

Quynh.
>  ------------------------------
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Friday, January 16, 2015 10:44 AM
> *To:* Dang, Quynh
> *Cc:* [email-masked]
> *Subject:* Re: Singular or multiple NamedGroup(s) in the
> "HelloRetryRequest"
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Jan 2015 08:34:46 -0800

On Fri, Jan 16, 2015 at 8:29 AM, Paul Hoffman <[email-masked]> wrote:

> I think what Quynh wants is to turn the HelloRetryRequest into an
> advertisement for the server's capabilities, and having that advertisement
> be longer than 1 would be better. That is, it would be "We're failing and
> I'm choosing none of yours, but if you retry and can do any of these,
> please do so".
>
> I'm not saying I like that idea, and I waffled a lot on it in IKEv2, but
> it is a common proposal for how to do negotiation (as compared to
> "offer-pick").
>

Sure, but that basically just pushes the choice back on the client. What's
the
advantage of that?

-Ekr

---

From: Henrik Grubbström <[email-masked]>
Date: Fri, 16 Jan 2015 17:44:08 +0100

On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh <[email-masked]> wrote:
> If a client offers all of the options it supports and a server sends back
> one group out of these options, it would guarantee a failure.

It seems you've misunderstood; the client announces all named groups
that it supports in the named_group extension, but usually only
provides a subset of these in its ClientKeyShare message. Thus the
server can ask for a named group that the client supports but hasn't
provided a key share for in its HelloRetry.

/grubba

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]

---

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 16 Jan 2015 17:59:56 +0000

Hi Eric and Henrik,

That would be fine. I just read the description of the "Client Key Share Message" again, It does not reflect the intent (to me); I found the description confusing, not clear.

Quynh. 

________________________________________
From: Henrik Grubbström <[email-masked]>
Sent: Friday, January 16, 2015 11:44 AM
To: Dang, Quynh
Cc: Eric Rescorla; [email-masked]
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

/grubba

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Jan 2015 10:18:49 -0800

On Fri, Jan 16, 2015 at 9:59 AM, Dang, Quynh <[email-masked]> wrote:

> Hi Eric and Henrik,
>
> That would be fine. I just read the description of the "Client Key Share
> Message" again, It does not reflect the intent (to me); I found the
> description confusing, not clear.
>

That's too bad. If you have some editorial improvements, a pull request
would
be appreciated.

Best,
-Ekr

Quynh.

---

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 16 Jan 2015 20:03:31 +0000

How about replacing the following text in Section 7.3.2

"Meaning of this message:

      This message contains the client's cryptographic parameters for
      zero or more key establishment methods.

   Structure of this message:

      struct {
          NamedGroup group;
          opaque key_exchange<1..2^16-1>;
      } ClientKeyShareOffer;

   group  The named group for the key share offer.  This identifies the
      specific key exchange method that the ClientKeyShareOffer
      describes.  Finite Field Diffie-Hellman parameters are described
      in Section 7.4.2.1; 7.3.2.1; Elliptic Curve Diffie-Hellman parameters are
      described in Section 7.4.2.2. 7.3.2.2.

   key_exchange  Key exchange information.  The contents of this field
      are determined by the value of NamedGroup entry and its
      corresponding definition.

      struct {
          ClientKeyShareOffer offers<0..2^16-1>;
      } ClientKeyShare;

   offers
      A list of ClientKeyShareOffer values."

by the following text?

"

Meaning of this message: This message contains the client's cryptographic parameters for zero or more groups for key establishment it supports. The client indicates which group(s) it supports in the "supported_groups" extension (Section 7.3.2.5.2). This message contains a "ClientKeyShare" value specified below.

Structure of each client key share for a particular group:

struct {

           NamedGroup group;

           opaque key_exchange;

          } ClientKeyShareOffer;

      group  The named group for the key share offer.  This identifies the

      specific key exchange method that the ClientKeyShareOffer

      describes.  Finite Field Diffie-Hellman parameters are described

      in Section 7.3.2.1; Elliptic Curve Diffie-Hellman parameters are

      described in Section 7.3.2.2.

      key_exchange  Key exchange information.  The contents (and the length) of this field

      are determined by the value of NamedGroup entry and its corresponding definition.

Structure of a "ClientKeyShare" message:

      struct {

                   ClientKeyShareOffer offers<0..2^16-1>;

                 } ClientKeyShare;

      offers  A list of ClientKeyShareOffer values.?

"
If the group finds that the proposed text is clearer than the current text, I will do a pull request.

Quynh.

________________________________
From: Eric Rescorla <[email-masked]>
Sent: Friday, January 16, 2015 1:18 PM
To: Dang, Quynh
Cc: Henrik Grubbström; [email-masked]
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

On Fri, Jan 16, 2015 at 9:59 AM, Dang, Quynh <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric and Henrik,

That's too bad. If you have some editorial improvements, a pull request would
be appreciated.

Best,
-Ekr

Quynh.

________________________________________
From: Henrik Grubbström <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 16, 2015 11:44 AM
To: Dang, Quynh
Cc: Eric Rescorla; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

/grubba

--
Henrik Grubbström                                       [email-masked]<mailto:[email-masked]>
Roxen Internet Software AB                              [email-masked]<mailto:[email-masked]>