[CFRG] Spencer Dawkins' No Objection on draft-irtf-cfrg-hpke-09: (with COMMENT)

[Spencer Dawkins via Datatracker <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-irtf-cfrg-hpke-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This isn't even remotely a topic I'm smart about, but the document was clearly
written, and I can imagine using it as an implementer. I do have some nits, so
please Do The Right Thing.

At the bottom of Section 5, this sentence, "The procedures described in this
session are laid out in a Python-like pseudocode", and that's the only
occurence of "session" in the document. I don't know what "this session" is
intended to refer to - I can guess, but I'd be guessing. Is it something like
"in the following *sections*"?

In this text, "This assurance is based on the assumption that AuthDecap(enc,
skR, pkS) produces the correct KEM shared secret only if the encapsulated value
enc was produced by AuthEncap(pkR, skS), where skS is the private key
corresponding to pkS", is "assumption" the right word? "Assumption" makes me
look for some mention of evidence that would support that assumption, but
reading further, I'm led to believe that this is a fundamental property, not an
assumption.

In this text, "In many cases, applications encrypt only a single message to a
recipient's public key", is "to the recipient's public key" the right way to
say this? I was guessing this meant "In many cases, applications encrypt only a
single message using a recipient's public key"

In this text, "The precise likelihood of DeriveKeyPair() failing with
DeriveKeyPairError depends on the group being used, but it is negligibly small
in all cases", is there any obvious action that an implementer could take if
this DOES happen?

I wonder if Section 7.1.5. KEM Key Reuse should appear in the security
considerations section, or perhaps even just be mentioned there, with a
reference to its current location. Perhaps even in Section 9.2? But just having
this appear in Section 7 without a mention in Section 9 seems counterintuitive.

Hmmm. Section 5.3 says this: “Applications that do not use the encryption API
in Section 5.2 can use the export-only AEAD ID 0xFFFF when computing the key
schedule. Such applications can avoid computing the key and base_nonce values
in the key schedule, as they are not used by the Export interface described
above”, but Section 7.3 says “The 0xFFFF AEAD ID is reserved for applications
which only use the Export interface; see Section 5.3 for more details”. Would
saying “Applications that do not use the encryption API in Section 5.2 can use
the export-only AEAD ID 0xFFFF when computing the key schedule” in Section 7.3
be accurate? If so, it would be more obvious that these two statements apply in
the same conditions if they use the same phrasing.

I may be going blind (and that would be a pity, since I had cataract surgery
earlier this year), but I can’t see the difference between what’s said about
DHKEM in

Extract() and Expand() (in DHKEM): Extract() can be modeled as a random oracle.
Expand() can be modeled as a pseudorandom function, wherein the first argument
is the key.

and what’s said about “elsewhere” in

Extract() and Expand() (elsewhere): Extract() can be modeled as a random
oracle. Expand() can be modeled as a pseudorandom function, wherein the first
argument is the key.

Is there a difference? I see text in Section 9.5 that looks like it might be
related, but I just don’t have the background to know for sure.

In 11.1. KEM Identifiers, “The "HPKE KEM Identifiers" registry lists
identifiers for key encapsulation algorithms defined for use with HPKE. These
are two-byte values, so the maximum possible value is 0xFFFF = 65535”, These
“might” be clearer as “These identifiers” (same comment in 11.2 and 11.3).