Re: [CFRG] RFC9180/HPKE erratum on recommended sizes

You might find this useful... formal bounds for all those HPKE inputs can
be found here:
https://github.com/hacl-star/hacl-star/blob/main/specs/Spec.Agile.HPKE.fsti#L330

... of course it is a weird formula which depends on which hash algorithm
[a] is used.
An audit of this would be welcome btw.

B.

Le jeu. 17 nov. 2022 à 16:05, David Benjamin <davidben@chromium.org> a
écrit :

> Our implementation doesn't impose any particular limits on info. But this
> maybe points to a larger issue here. The resolution of
> https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/226 to recommend
> using info like an AEAD's aad parameter, which typically does not have
> tight limits. And, even independent of that advice, non-single-shot uses
> (like ECH) may well have non-trivial per-context additional authenticated
> data. For ECH in particular, should we ever stick PQ KEMs into ECH, the
> info field will become a lot larger.
> https://www.rfc-editor.org/rfc/rfc9180.html#section-8.1
>
> Looks like the size issue comes from info being used as the IKM to
> LabeledExtract, which constructs a labeled_ikm by prepending a prefix. This
> means that, if your HKDF API requires contiguous IKMs, you need to make a
> copy of the info string.
> https://www.rfc-editor.org/rfc/rfc9180.html#section-5.1-9
> https://www.rfc-editor.org/rfc/rfc9180.html#section-4-9
>
> I would not expect most HKDF-Extract APIs to support discontiguous IKMs,
> as that's kinda weird for keying material. Then again, if we break the
> abstraction, it's just the body of an HMAC, which typically can be
> streamed, much less discontiguous. So we do't *actually* need to make a
> copy here. But breaking the abstraction here is not ideal because HPKE aims
> to abstract over KDFs. So if we want to rely on that, we might need to make
> a note to tweak the definition for future KDFs so they don't need to rely
> on the HMAC internals.
>
>
> On Wed, Nov 16, 2022 at 7:27 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> I filed an erratum [1] on RFC9180. It'd be good know what
>> other implementations support before we finalise/approve
>> that.
>>
>> The issues:
>>
>> - section 7.2.1 recommends a max of 64 octets for various
>>    values, but appendix A.6.1 and other test vectors require
>>    handling values that are 66 octets long
>>
>> - 64 octets is too short for the "info" parameter, as used
>>    for ECH (where it needs to allow 8+len(ECHConfig) which
>>    will be longer, and ECHConfig is extensible so we can't
>>    be sure how long)
>>
>> One way to handle this might be to change the erratum so
>> it recommends supporting up to 128 octets for all values
>> except "info" where we might recommend supporting up to
>> 1024.
>>
>> So - would the above work for your HPKE implementation or
>> application using HPKE, or would you prefer some other
>> change?
>>
>> Thanks,
>> S.
>>
>> [1] https://www.rfc-editor.org/errata/eid7251
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>