Subject: Re: [TLS] Point Compression

From: Carl Mehner <[email-masked]>
Date: Mon, 25 Oct 2021 23:47:08 -0500

I uploaded a draft for the IANA assignments for compressed code points for
the NIST curves:
https://datatracker.ietf.org/doc/draft-cem-compressed-curves/
In it, I elected to not pursue the format to encode the types of keys
specified in draft-jivsov-ecc-compact
<https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html>, mostly
because the support for 'regular' (SEC1) compressed curves is more
widespread. However, I'm not against using the method described by Andrey
if we want to shave off one more byte and require software updates to
handle the different format required.

ekr, (seeking advice for next steps): do you think this would fit better as
a footnote in the cTLS update presentation at ietf112 or do you think it
would need extra discussion?

-carl
On Fri, Jul 30, 2021 at 3:00 PM Andrey Jivsov <[email-masked]> wrote:

> I propose a method to compress NIST curves as defined in
> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html
>
> Its main benefit is that the compressed point fits into field size / group
> order size. There is no additional byte needed.
> <snip>
> On Fri, Jul 30, 2021 at 9:48 AM Carl Mehner <[email-masked]> wrote:
>
>> As requested during ekr's presentation
>> <https://youtu.be/SfuvB41YhyU?t=980>, I will volunteer to write up a
>> draft for defining new "supported groups" for compressed NIST curves. I
>> didn't see/hear any objections during the tls-wg meeting, but thought
>> I should probably confirm on the list before I got too far along in writing
>> it...
>>
>> -carl
>>
>
>

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 25 Oct 2021 22:15:14 -0700

Do we have evidence that "02 <x>" or "03 <x>" is more widespread than <x>
for NIST curves? I haven't seen "02 <x>" or "03 <x>" in deployed products
in TLS / X.509 at all. So, I feel that for TLS space the slate is clean
regarding compression. X25519 uses one coordinate, which is simiiar to
doing <x> for NIST curves...

---

From: John Mattsson <[email-masked]>
Date: Tue, 26 Oct 2021 07:58:08 +0000

There are several active documents also defining compact representation.

After the discussion regarding HPKE there was a suggestion EDHOC should define a compract format that could be reused by other protocols. That was done in an Appendix.
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#page-67

Also as an outcome of the HPKE discussions Dan Harkins has written on compact representation for HPKE submitted to CFRG. This also defines a a general format than can be reused by other protocols.
https://datatracker.ietf.org/doc/draft-harkins-cfrg-dnhpke/

> the support for 'regular' (SEC1) compressed curves is more widespread.

What is support in this case? An implementation can just use one of the values "02" and "03" or flip a coin. If you have support of 'regular' (SEC1) compressed curves, then compact representation is trivial.

Cheers,
John

From: TLS <[email-masked]> on behalf of Andrey Jivsov <[email-masked]>
Date: Tuesday, 26 October 2021 at 07:15
To: Carl Mehner <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] Point Compression
Do we have evidence that "02 <x>" or "03 <x>" is more widespread than <x> for NIST curves? I haven't seen "02 <x>" or "03 <x>" in deployed products in TLS / X.509 at all. So, I feel that for TLS space the slate is clean regarding compression. X25519 uses one coordinate, which is simiiar to doing <x> for NIST curves...

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 26 Oct 2021 19:37:35 -0700

Looking closer, all what we discuss here is related to ECDH, so the sign of
a point is not important for the result.

In this case the compression can be a simple truncation to <x>, e.g.
without the need to do tricks with the private key to make this an
unambiguous representation of a point. This simple truncation works with
existing software. I think that TLS should adopt the <x> format (without 02
or 03 prefix).

Note that this truncation extends to the SEC1 compressed format: in this
case we just drop the first byte.

This truncation is highest-performance option and it's simplest too.

On Tue, Oct 26, 2021 at 12:58 AM John Mattsson <[email-masked]>
wrote:

> After the discussion regarding HPKE there was a suggestion EDHOC should
> define a compract format that could be reused by other protocols. That was
> done in an Appendix.
>
> Also as an outcome of the HPKE discussions Dan Harkins has written on
> compact representation for HPKE submitted to CFRG. This also defines a a
> general format than can be reused by other protocols.
>
> What is support in this case? An implementation can just use one of the
> values "02" and "03" or flip a coin. If you have support of 'regular'
> (SEC1) compressed curves, then compact representation is trivial.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *TLS <[email-masked]> on behalf of Andrey Jivsov <
> [email-masked]>
> *Date: *Tuesday, 26 October 2021 at 07:15
> *To: *Carl Mehner <[email-masked]>
> *Cc: *IETF TLS <[email-masked]>
> *Subject: *Re: [TLS] Point Compression
>