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'.
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
