[Gen-art] Re: [hpke] Gen-ART Last Call review of draft-ietf-hpke-hpke-04

[Rohan Mahy <[e-mail]>]

Hi Paul,
Thanks for the review.

I want to chime in with a different opinion about what is useful for folks
to see in the IANA tables. I think it is very valuable for folks to see
which algorithms were initially defined in which RFCs. Replacing RFC9180
with RFCXXXXX in the tables throws away useful information for
implementers. When a new column is added, the Reference can contain both
the old and new RFCs (so the source of values in the new column is clear).
I don't see any value in replacing an obsoleted RFC in an unchanged IANA
table, nor for one that merely drops a column.
Thanks,
-rohan

On Sat, 1 Aug 2026, 16:38 Paul Kyzivat, <pkyzivat=
[e-mail]> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-hpke-hpke-04
> Reviewer: Paul Kyzivat
> Review Date: 2026-08-01
> IETF LC End Date: 2026-08-03
> IESG Telechat date: ???
>
> Summary: This draft is on the right track but has open issues, described
> in the review.
>
> Note: I have minimal knowledge of cryptographic algorithms. Hence this
> review doesn't address any cryptographic issues, and doesn't attempt to
> validate the appendices. Comments are structural, procedural and editorial.
>
> Issues: 7
> Nits: 4
>
> 1) ISSUE: Are one-stage KDFs ready for prime time?
>
> Section 4.2 (Key Derivation Functions) introduces the notion one-stage
> and two-stage KDFs. This is a notable change from RFC 9180. It
> considerably increases complexity. Did you try to better encapsulate the
> distinction? (E.g., turn one-stage into a degenerate form of two-stage.)
>
> Also, the parameter "Nh" is defined only for a two-stage KDF. It isn't
> defined for one-stage KDFs. And Table 3 in section 7.2 lacks any entries
> for one-stage KDFs.
>
> It appears to me that the notion of one-stage KDFs might be speculative,
> and under-specified.
>
> 2) ISSUE: References to RFC 9180
>
> This document obsoletes RFC 9180, but still references it. Some
> references are reasonable, to highlight the differences. But some
> references remain that probably should instead refer to this document.
> Notably:
>
>    Section 7.1, Table 2
>    Section 7.2, Table 3
>    Section 7.3, Table 5
>    Section 9.7.3
>
> Ideally, I think it would be better to confine references to RFC 9180 to
> Appendix A, while making the rest of the document stand on its own.
>
> 3) ISSUE: IANA Registration issues
>
> Section 11 (IANA Considerations) fails to clearly identify the location
> of the IANA registries. Instead it references the definitions in RFC
> 9180. Since this doc obsoletes RFC 9180, it should fully take over the
> specification of the IANA registries.
>
> What do you want to allow after this document is published? Do you want
> all current registrations, made under RFC 9180 rules, to remain? Even
> those that use features that have been removed? (More specifics below.)
>
> 4) ISSUE: Update of KEM Identifiers
>
> Section 11.2 (KEM Identifiers) says "Initial contents: Provided in Table
> 2". If the intent is to preserve everything that is currently
> registered, rather than starting over, then this is not true. Instead, I
> think you need to specify that table 2 provides additions and/or updates
> to the existing registry.
>
> I gather the "Auth" column is made obsolete by this document, and is
> perhaps being retained for backward compatibility with RFC 9180. If so,
> do you want to allow future registrations to specify a value for this?
> I'm not sure how best to handle this, but you should specify your
> intent. Perhaps a discussion with IANA would be helpful.
>
> 5) ISSUE: Update of KDF Identifiers
>
> Section 11.3 (KDF Identifiers) says "Initial contents: Provided in Table
> 3". If the intent is to preserve everything that is currently
> registered, rather than starting over, then this is not true. Instead, I
> think you need to specify that table 3 provides additions and/or updates
> to the existing registry.
>
> Also, this adds a column to the table. IANA needs some guidance about
> how to handle this for existing table entries. What value should be used
> for "Two-Stage". (I gather the default would be "Y".)
>
> 6) ISSUE: Update of AEAD Identifiers
>
> Section 11.4 (AEAD Identifiers) says "Initial contents: Provided in
> Table 5". The registry was already defined by RFC 9180, and it appears
> that Table 5 is consistent with the existing registry content, including
> referencing RFC 9180 rather than this document. (With exception of N/A
> in the Export-only row.)
>
> I think IANA needs better direction about what to do. I suggest you
> update Table 5 to reference this document rather than 9180, and direct
> IANA to replace the existing table with the contents of Table 5.
>
> 7) ISSUE: Undefined terms
>
> Section 4.1 (Key Encapsulation Mechanisms) omits the definitions of
> AuthEncap and AuthDecap which were included in RFC 9180. Yet they are
> still referenced in 7.1 and 11.2. Please either define them, or omit the
> references. (See other issues for more on this.)
>
> 8) NIT: Lack of normative language
>
> In section 8.1 (Auxiliary Authenticated Application Information) the
> last paragraph is wishy-washy, and lacking normative language. If you
> intend to permit the behavior you discourage, then please at least say
> more about the negative consequences of doing so, and/or explain when
> that behavior would be appropriate, using normative language.
>
> 9) NIT: Byte order unspecified
>
> Section 3 (Notation) The definition of lengthPrefixed fails to specify
> what encoding is to be used for the two-byte length. (Presumably network
> byte order.)
>
> 10) NIT: wording
>
> In section 4 (Cryptographic Dependencies) the statement: "An
> Authenticated Encryption with Associated Data (AEAD);" seems to be
> lacking a noun stating what the AEHD *is*. Based on the title of 4.3,
> how about revising to:
>
>     "An Authenticated Encryption with Associated Data (AEAD) algorithm;"
>
> 11) NIT: IdNits
>
> The IdNits tool reports a couple of things that seem relevant:
>
>   == Unused Reference: 'BHK09' is defined on line 1992, but no explicit
>       reference was found in the text
>
>   -- Duplicate reference: RFC9849, mentioned in 'RFC9849', was also
>      mentioned in 'ECH'.
>
> _______________________________________________
> hpke mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>