Re: [TLS] Should we require compressed points

[Ilari Liusvaara <[e-mail]>]

On Tue, Oct 21, 2014 at 05:03:27PM +0200, Eric Rescorla wrote:
> On Tue, Oct 21, 2014 at 5:01 PM, Hubert Kario <[e-mail]> wrote:
> >
> > How does that impact possibility of adding more "exotic" curves like
> > curve25519/Ed25519
> > in some later point in time?
> >
> 
> Hubert, thanks for your email.
> 
> I don't think it should impact it at all because you still have to
> advertise the curves you
> support. My assumption is that advertising curve X would be the same as
> advertising
> that you could support its defined point format(s).

I would just lock the point format per curve for non-X9.63-compatible
stuff, at least for DH. That is, use curve-defined wire encoding,
regardless of what point formats extension says.

Also, there is another issue with non-X9.63-compatible stuff:
Encoding of the premaster secret. Proposal: Use usual wire encoding.

Disadvantage of this is that TLS 1.2- compatiblity would require
contradicting RFC 4492 (but specs contradicting base specs is not
unheard of) in order to ignore point formats and pms encoding.


Now with this, one could just stuff raw 32-byte curve25519 public
key into *KeyShare packet (with no prefix) and use the raw shared
secret as premaster secret (also 32 bytes).

And similarly for some XYZ curve that is twice the speed of
curve25519, but has really odd 48-byte point format.


-Ilari