Subject: Re: [TLS] Should we require compressed points

From: Peter Gutmann <[email-masked]>
Date: Wed, 22 Oct 2014 22:01:14 +0000

Eric Rescorla <[email-masked]> writes:

>Given that people seem to think that compressed points are better, I figured
>that was the way to go. If people prefer to just require uncompressed points
>(at least for the existing X9.63 curves) I could certainly live with that.

Uncompressed points have been a MUST in TLS since ECC was introduced, and are
also a MUST everywhere else.  So adding compressed points as a MUST as well
won't get rid of uncompressed points in any way, it'll just add more options
that need to be supported.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Oct 2014 15:10:10 -0700

> that need to be supported.

As I said above, I'm principally trying to get rid of negotiation so we
have one
point format for each curve. I could certainly live with requiring
uncompressed
only for the X9.62 curves and then defining a new, cleaner format for the
new CFRG curves.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 16:04:35 -0700

On 27 October 2014 15:10, Eric Rescorla <[email-masked]> wrote:
> As I said above, I'm principally trying to get rid of negotiation so we have
> one

And maybe we could define a new cleaner format for the existing curves too...

---

From: Watson Ladd <[email-masked]>
Date: Mon, 27 Oct 2014 17:55:44 -0700

> And maybe we could define a new cleaner format for the existing curves too...

What's wrong with SEC1?

Sincerely,
Watson Ladd

> _______________________________________________
> TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Michael StJohns <[email-masked]>
Date: Mon, 27 Oct 2014 22:07:47 -0400

On 10/27/2014 6:10 PM, Eric Rescorla wrote:
>
>
> On Wed, Oct 22, 2014 at 3:01 PM, Peter Gutmann 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Eric Rescorla <[email-masked] <mailto:[email-masked]>> writes:
>
> As I said above, I'm principally trying to get rid of negotiation so 
> we have one

You've said this before and it's unclear that this is the correct approach.

Curve25519 has one (or maybe two) representation(s)  (public keys are 
basically Bignums - DJB has the representation as fixed length octet 
strings representing the little endian encoding - but that seems to be 
based on his specific implementation - its not required by the math as 
far as I can tell) - it also doesn't have multiple curve types.  
NUMS/Edwards curves have another format (I think still undefined).   
NUMS/Montgomery/X9.62 curves a third (a format byte plus one or two 
fixed length octet strings representing big endian bignums).   The math 
for each of these is different  - the only thing they really share is 
the name "Elliptic Curve".   It's unclear that you gain anything trying 
to shoehorn all of these into the same overlying structure except a 
small amount of compression and a large amount of complexity.

Think of it this way - if you can combine  this to cover all of the 
various curve structures, why stop there?  Why not integrate generic DH 
for key agreement and RSA  and DSA for signatures?

Instead, treat each of the different elliptic cryptomath systems as 
distinct and separate.  Define suites that don't require across the 
board mappings of incompatible data and formats.  Retain the 
pluggability of new systems as units.

We've got legacy X9.62 - let's leave it alone.  All the stuff that's 
already defined (suites, formats, certificates, etc) remains as X9.62 
(and the various RFCs) defined it.    New systems, as they are defined, 
get their own code points,suites, public key formats, key agreement 
protocols, signature methods and extensions (if necessary) appropriate 
only for them.

On the point above, uncompressed X9.62 public keys are not going away 
anytime soon and are MUSTs in all the existing standards. Making them 
MUST NOT's in TLS1.3 seems to be a bad idea. If we want to require 
support for compressed points in addition as the next step then *maybe* 
that's the right answer.  But then we probably need to go back to X9.62 
and get them to make that recommendation as well.

Later, Mike

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 28 Oct 2014 10:35:25 +0100

On 27/10/2014 23:10, Eric Rescorla wrote:
> one point format for each curve. I could certainly live with requiring 
> uncompressed only for the X9.62 curves and then defining a new, cleaner
> format for the new CFRG curves.
> 
If the goal is to get rid of negotiation, would it be reasonable to say that
implementations MUST support both formats?

Manuel.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Oct 2014 14:52:24 +0000

> implementations MUST support both formats?

I think that Bodo's suggestion of separate IANA assignments for
compressed and uncompressed variants of curves makes the most sense.

With that, clients that need to interoperate with TLS <= 1.2 can
send the point format extension indicating uncompressed format for
legacy curves, and include the code points for the legacy
format-ambiguous curves, and send new code points for (some of the
same underlying) curves that have an implied format.

Brand new curves would then ideally be registered with a single
preferred point format that is most suitable for the curve.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Oct 2014 07:54:32 -0700

On Tue, Oct 28, 2014 at 7:52 AM, Viktor Dukhovni <[email-masked]>
wrote:

> we have

This seems perfectly reasonable to me.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Oct 2014 17:54:24 +0200

> preferred point format that is most suitable for the curve.

And the new code points also presumably used the fixed wire format
(whatever that happens to be) for the premaster secret (because that
is another thing that currently assumes X9.63 curves)?

With that in, one could handle anything CFRG might throw at us, and
more.

-Ilari

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 28 Oct 2014 17:24:25 +0100

> compressed and uncompressed variants of curves makes the most sense.
Yes, I didn't see his suggestion when I posted, but now I agree it looks like
the best way to go.

Manuel.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Oct 2014 10:34:52 -0700

This discussion seems to be settling, so I've prepared a pull request
that implements Bodo's suggestion:

https://github.com/tlswg/tls13-spec/pull/86

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 31 Oct 2014 20:31:46 +0200

> https://github.com/tlswg/tls13-spec/pull/86
 
I think 8.1.2 (ECDHE premaster secret calculation) should be modified
as well, to specify using the fixed wire encoding of selected group for
premaster secret.

This is to avoid problems with more "odd" encodings.

Note that 8.1.1 does not quite match that beheviour, since it specifes
leading zero octets to be stripped (whereas DHE "element" encoding
doesn't seem to specify if zeroes are stripped or not)

-Ilari