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

["Dang, Quynh" <[e-mail]>]

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 <[e-mail]>
Sent: Friday, January 16, 2015 1:18 PM
To: Dang, Quynh
Cc: Henrik Grubbström; [e-mail]
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

On Fri, Jan 16, 2015 at 9:59 AM, Dang, Quynh <[e-mail]<mailto:[e-mail]>> 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: Henrik Grubbström <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 16, 2015 11:44 AM
To: Dang, Quynh
Cc: Eric Rescorla; [e-mail]<mailto:[e-mail]>
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh <[e-mail]<mailto:[e-mail]>> 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                                       [e-mail]<mailto:[e-mail]>
Roxen Internet Software AB                              [e-mail]<mailto:[e-mail]>