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

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
>