Re: [TLS] Should we require compressed points

[Michael StJohns <[e-mail]>]

On 10/21/2014 10:52 AM, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/80
>
> Today we discussed the possibility of requiring support for compressed 
> points
> in TLS 1.3 now that the IPR has expired.
>
> Specifically, I propose that for TLS 1.3, we:
>
> - Use only compressed points for the existing curves (and presumably
>   whatever superior format is defined for the CFRG-recommended
>   curves, as appropriate).
>
> - Deprecate the Supported Point Formats extension for TLS 1.3

After thinking about this longer - how actually would this work 
negotiation wise?  Specifically "us[ing] only compressed points"?

AFAICT, all you're going to do is make the negotiation even more 
complex.  The TLS1.3 clients and servers will still need to implement 
uncompressed points to talk to TLS1.2 and before clients and servers.  A 
TLS1.3 server will still need to understand an offered Supported Point 
Format extension from a TLS1.2 client to figure out if it can send a 
compressed point public key.  (I think) A TLS1.3 client will still need 
to offer the Supported Point Format extension in case it's talking to a 
1.2 server if the client wants to offer a compressed public key.

Is there any benefit you get besides  the savings of 1/2 of a public key 
on the wire from the server to the client?  Call it 32 octets for a 256 
bit X9.63 key.

The only way you get away from this is if you have prior knowledge of 
the server implementation or you put TLS1.3 on a new port (which to be 
clear I'm not suggesting).

And you still need support for the uncompressed form for certificates 
for quite a very long time (RFC5480).

So what's the argument for doing this besides "we can"?

Mike


>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.
>
> What do people think?
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls