Subject: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 11:17:15 -0700

Folks,

I've just made Pull Request 82, which implements a number of
the changes we discussed in Toronto, including:

- Merge in support for ECC from RFC 4492.

- Merge in the relevant text from the Finite-Field Diffie-Hellman
  draft.

- Merge the code point spaces for named groups between ECC and FF-DHE
  (see DKG's message to the list from September 19.)

- Rename {Client,Server}KeyExchange to {Client,Server}KeyShare

- Add an explicit HelloRetryRequest to reject the client's
  ClientKeyShare. This was something we discussed and just makes
  things a lot clearer.

Please see the PR at:
https://github.com/tlswg/tls13-spec/pull/82

Target merge date October 9.

Please comment here or on github if you see issues.

Best,
-Ekr

P.S. Next up is incorporating the session-hash/triple handshake
changes.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 7 Oct 2014 22:35:12 +0300

> - Merge in support for ECC from RFC 4492.

Might be a good idea to allow curve to specify a format for ECDHE.
This avoids trouble with "exotic" formats (useful for what is
expected for CFRG curves[1] and some other high-performance curves).

The presently defined ECC curves can use X9.62 formats for ECDHE.

Also, note that ClientKeyShare representations are unnegotiable
(at least for optimistic round), so one presumably needs to fix
the representation (X9.62 compressed?) even for existing groups).

> - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare

How does the server know to expect CKS? If ClientVersion is 3.4
or higher and there is no first flight extension in ClientHello?

Due to how TLS handshake and underlying transport works, the
last message in flight can not be optional. And sending CKS as-is
would cause TLS 1.2 server to blow up.

>   ClientKeyShare. This was something we discussed and just makes

Now you have duplicate ClientHello and parts of ServerHello, both
of which must be checked for constency. If you don't, you have a
security hole (especially if one restarts hash).

I would rather not have such traps in the spec.

And since one needs copies of CH and SH to check them, sending
them again is completely redundant.

Also, omitting the superfluous CH and SH-parts will let one omit
the redundant key shares.

In DTLS, those retransmissions can be quite expensive (network
I/O can be way more expensive than you think).

Also, restarting the handshake, one must implement group selection
so that one can't get stuff like this:

C->S: Hello, Groups X, Y, Z.
S->C: Try again: Use group W.
C->S: Hello, Groups X, Y, Z, W.
S->C: Try again: Use group U.
...

Other notes:

Named_groups is not noted to be mandatory. What happens if it
is missing? Fatal error? Optimistic CKS has all supported
groups?

The optimistic nature of CKS means that Supported Point Formats
can't really be applied to ECDHE key exchange, only to
signatures.

Also, in Supported Point Formats, if it does not apply to
ECDHE (due to the problem above), what does it apply to?
The only another points are in host key, which is inside
certificate, and thus one would have to drive certificate
choice off SPF.

The stuff copied to section "Elliptic Curve Diffie-Hellman"
is likely totally inapporiate for CFRG curves. One idea
would be to encode the output point as it would be sent
on the wire in CKS/SKS.

[1] I expect those curves to be of "new" shapes, and
X9.62 point encoding can't properly handle those (especially
not compresion).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 14:45:43 -0700

> expected for CFRG curves[1] and some other high-performance curves).

Yes, see the somewhat opaquely worded note here:
https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R1968

> the representation (X9.62 compressed?) even for existing groups).

IIRC, the points are self-describing as to whether they are compressed
or not, so the client has to choose, but he might guess wrong as
he does with the groups. I would actually prefer to fix the representation
if that's possible, but I figure that's a separable question.

> or higher and there is no first flight extension in ClientHello?

Yes.

> would cause TLS 1.2 server to blow up.

Yes. You always must send it either in EarlyData or otherwise. And if
you don't know, it has to go in the extension for backwards compatibility.

> them again is completely redundant.

Can you elaborate on your concern here?

> the redundant key shares.

As I think I said previously, there was consensus to use this design
at the Denver interim in the name of consistency. All I've done here
is change the server's first ServerHello to a HelloRetryRequest,
which I believe is consistent with that decision. If the WG consensus
is to change this, I'll make the change.

> is missing? Fatal error? Optimistic CKS has all supported

My bad. This was supposed to be mandatory but it got lost in an
editorial pass. I will fix.

> can't really be applied to ECDHE key exchange, only to

I don't believe this is true. Supported points is the list of points that
you will let the other side send, not that you can send. See:

https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R2394

So, what you are saying is "regardless of what formats I sent you,
send me X". Also, Supported Points can be used by the server
in the HelloRetryRequest to indicate if the client sent an inappropriate
point format.

I recognize all this point negotiation is silly and as I said, I would be
fine if we just required one form. See issue:

https://github.com/tlswg/tls13-spec/issues/80

> certificate, and thus one would have to drive certificate

Yes, 4492 requires this:

" The server constructs an appropriate certificate chain and conveys it

   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves; in
   particular, the public key MUST employ a named curve (not the same
   curve as an explicit curve) unless the client has indicated support
   for explicit curves of the appropriate type.  If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)"

> would be to encode the output point as it would be sent

I've filed the following issue to deal with this when those curves
pop out:

https://github.com/tlswg/tls13-spec/issues/83

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Thu, 09 Oct 2014 14:06:15 -0400

On 10/7/2014 5:45 PM, Eric Rescorla wrote:
>
>
> On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Wouldn't it make sense not to overload this?  Keep the current code 
point for X9.62 curve based public data and assign a new code point to 
anything non-X9.62 compliant?

Or maybe we need to take a more "meta" look at representing EC 
cryptography given the discussions at the last CFRG - X9.62, Curve25519, 
Ed25519, Weiserstrass (mostly X9.62), twisted Edwards, etc.  Even though 
these are all "elliptic curve", they can easily be as distinct - 
representation wise - as RSA is from EC X9.62.

Mike

> "The server constructs an appropriate certificate chain and conveys it
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Oct 2014 11:36:40 -0700

On Thu, Oct 9, 2014 at 11:06 AM, Michael StJohns <[email-masked]>
wrote:

> Wouldn't it make sense not to overload this?  Keep the current code point
> for X9.62 curve based public data and assign a new code point to anything
> non-X9.62 compliant?
>

Which code point are you referring to? Each curve will have its own code
point
in any case.

In any case, the intent with the current draft is simply to cover the
current
X9.62 compatible forms and then deal with whatever the CFRG comes out
with once that's finalized.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Thu, 09 Oct 2014 15:26:41 -0400

On 10/9/2014 2:36 PM, Eric Rescorla wrote:
>
>
> On Thu, Oct 9, 2014 at 11:06 AM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>     point for X9.62 curve based public data and assign a new code
>     point to anything non-X9.62 compliant?
>
>
> Which code point are you referring to? Each curve will have its own 
> code point
> in any case.

Sorry for my lack of clarity. "dhe-param" refers to X9.42 diffie-hellman 
public data.  "ecdhe-param" currently refers to X9.62 EC DH public 
data.   In some ways you could have had just the single "dhe-param" and 
use the type of algorithm to differentiate.

select (algorithm) {
     dh:
         opaque dh_Y<1..2^16-1>; // positive big endian integer - could 
be encoded that way
     ec962:
         opaque point<1..2^8-1>; // x9.62 formatted point, odd number of 
bytes, first byte is compression type
     curve25519:
         opaque publicKey <255>; // don't beat me up on size; little 
endian integer on curve25519
// other formats to come
}

So what I'm suggesting is that instead of changing the meaning/format of 
the "point" field in "ecdhe-param" to handle things like curve25519 or 
twisted edwards curves, to instead assign "ec25519dhe-param" or 
"tedhe-param" when and if the CFRG gets around to blessing them.

The math is different, the proposed formats are different etc.

Otherwise, you might want to signal the possibility that this isn't just 
an X9.62 point as:

select (curvetype) { // implicit
      x962:
          opaque point <1..2^8-1>;
// more curve types to come.
}

which may have been Ilari's point.

> with once that's finalized.

Yup.  But always dealing with possible backwards compatibility.   If 
your intention is to overload ecdhe_param for the new curves, then it 
would be useful to provide the right encoding/implementation hints.  If 
you're going to allocate new code points for each parameter type, then 
there's nothing that needs changes right now.

BTW -you should probably change "ecdh_Y" to "ecdh_XY" in this line:
> The opaque value conveys the Elliptic +Curve Diffie-Hellman public 
> value (ecdh_Y)

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Oct 2014 12:53:16 -0700

On Thu, Oct 9, 2014 at 12:26 PM, Michael StJohns <[email-masked]>
wrote:

> public data.  "ecdhe-param" currently refers to X9.62 EC DH public data.
> In some ways you could have had just the single "dhe-param" and use the
> type of algorithm to differentiate.
>
> select (algorithm) {
>     dh:
>         opaque dh_Y<1..2^16-1>; // positive big endian integer - could be
> encoded that way
>     ec962:
>         opaque publicKey <255>; // don't beat me up on size; little endian
> integer on curve25519
> // other formats to come
> }
>
>
> Yup.  But always dealing with possible backwards compatibility.   If your
> intention is to overload ecdhe_param for the new curves, then it would be
> useful to provide the right encoding/implementation hints.  If you're going
> to allocate new code points for each parameter type, then there's nothing
> that needs changes right now.
>

I don't think there's really a backward compatibility problem since it
seems likely that
we'll have the new curves before we finalize TLS 1.3, so I'm going to leave
this as-is
for now.

> The opaque value conveys the Elliptic +Curve Diffie-Hellman public value
> (ecdh_Y)
>
>
It's this way in RFC 4492.

-Ekr