Re: [CFRG] compact representation and HPKE

Dear Dan,

>> I can get an I-D out RSN in the expectation that RGLC finishes
Just a quick comment: the RGLC (the second RGLC) was in August, see
https://mailarchive.ietf.org/arch/msg/cfrg/H2xkKDiMVM6x0B8KdGx6Ii5iOO0/,
the HPKE draft is one step before the IRSG review.

>> Yes, I think this is an acceptable way forward.
Thanks, Dan! No objections against moving forward with the HPKE draft now,
right?

Regards,
Stanislav

On Mon, 15 Feb 2021 at 21:42, Dan Harkins <dharkins@lounge.org> wrote:

>
>   Hello,
>
> On 2/15/21 8:50 AM, Richard Barnes wrote:
>
> Hi folks,
>
> I think Karthik is on the right track here.  While the compact
> representation undoubtedly has its benefits, it seems like there is no
> disagreement that it is not widely supported in either standards or crypto
> libraries.  So there is a sizable community for whom a requirement to use
> the compact format would render HPKE unusable.
>
> Given that, I would propose we resolve this issue in the following way:
> * In the current document, define KEMs for the NIST curves using the
> uncompressed format.
> * If there is a community that is *also* interested in supporting the
> compact format, they can define new KEM code points for it.
>
> Would folks be comfortable proceeding on that basis?
>
>
>   Yes, I think this is an acceptable way forward. I can get an I-D out RSN
> in the expectation that RGLC finishes and we will soon have an HPKE RFC to
> update.
>
>   regards,
>
>   Dan.
>
>
> --Richard
>
> On Mon, Feb 15, 2021 at 11:45 AM Karthik Bhargavan <
> karthikeyan.bhargavan@inria.fr> wrote:
>
>> I think the idea of having a compact representation of EC points for use
>> in IoT-like scenarios is an attractive one, but the core ciphersuites of
>> HPKE should only depend on standardized and widely-implemented point
>> formats.
>>
>> In particular, HPKE is certainly not the right place to standardize a new
>> EC point format, however sensible the change may seem.
>> A protocol like EDHOC is laser-focused on small wire messages and is
>> meant to be implemented by IoT-specific crypto libraries, and so it makes
>> sense for that protocol to employ such optimizations.
>> Perhaps the LAKE working group could drive a IETF/CFRG standard for
>> x-only EC point representations that are more generally usable by other
>> protocols?
>>
>> Having said all that, HPKE is extensible and we do anticipate extensions
>> to HPKE in the near future, notably for adding PQ ciphersuites.
>> I think the best way to proceed for compact HPKE would be, along the
>> lines of Dan’s suggestion, to propose new KEM algorithm identifiers for
>> compact encodings of the NIST curves, and to do this as part of a new CFRG
>> draft as an extension to HPKE.
>> I suspect that, beyond the point representation, we may find other parts
>> of HPKE that would benefit from compaction for low-bandwidth scenarios.
>>
>> Best,
>> Karthik
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
> --
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>