Hi Rohan,
On 8/1/26 5:12 PM, Rohan Mahy wrote:
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.
I don't have a problem with adding the new reference and retaining the
old, if there is belief that this will be helpful in some way. But there
is a trade-off: a new implementer may then be distracted by a need to
look at both and decide if there is something he needs to consider from
the old one.
Because of the way -04 is written, it really is necessary to read both.
Since the intent (apparently) is to obsolete 9180, I think it should be
revised so that it is *not* necessary to consult 9180 unless your goal
is to understand the history,
I think this is a call for the WG and the AD to make.
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.
When the structure and meaning of a table is unchanged, I agree that
that entries that were added under the regime of the old document need
not be changed to reference the new one. But the ones that were
initialized by the obsoleted document itself should be redefined in a
document that is not obsolete. When the obsoleting document is
effectively a bis, then it makes sense to refine them there, though it
could be done in a separate document.
When the structure of a registry table is changed, then special care is
required to ensure that the updates are made in a way comprehensible
IANA and future users.
Thanks,
Paul
Thanks,
-rohan
On Sat, 1 Aug 2026, 16:38 Paul Kyzivat,
<[email protected]
<mailto:[email protected]>> 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
<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 -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
