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

[David Benjamin <[e-mail]>]

Right, the limits section notes some (very large) formal limits which seem
to have been computed that way. Those limits are large enough to not
matter. :-)
https://www.rfc-editor.org/rfc/rfc9180.html#name-input-length-restrictions

The issue is the smaller, additional limit discussed in the section.
Because of how HPKE was constructed, it is a little tricky to use the
"info" parameter without making a copy of it. But that means, even if the
primitive theoretically accepts a lot of data, you wouldn't want to pass
something *too* large into it. (For some nebulous notion of "too large".)
The immediate issue is the chosen limit (64) is very tight, and
inconsistent with uses of HPKE. But I think there is a bigger issue here
because we said "info" is to be used like an AEAD aad. You typically do not
need to make a copy of aad to run the AEAD.

On Thu, Nov 17, 2022 at 12:01 PM Benjamin Beurdouche <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>> _______________________________________________
>> CFRG mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>