Re: [TLS] Should we require compressed points

[Michael StJohns <[e-mail]>]

On 10/27/2014 6:10 PM, Eric Rescorla wrote:
>
>
> On Wed, Oct 22, 2014 at 3:01 PM, Peter Gutmann 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Eric Rescorla <[e-mail] <mailto:[e-mail]>> 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.
>
>
> 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.

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