Skip to main content

Hybrid Public Key Encryption
draft-irtf-cfrg-hpke-12

Yes

Stephen Farrell

No Objection

David Oran

Note: This ballot was opened for revision 09 and is now closed.

Ballot question: "Is this draft ready for publication in the IRTF stream?"

Colin Perkins
(was No Objection) Yes
Comment (2021-06-27 for -09) Not sent
Changing my ballot from "No Objection" to "Yes", now we also have an additional external review from Kirsty P. I believe once her comments, and those from Spencer, are addressed, then this will be ready for publication.
Stanislav Smyshlyaev
Yes
Comment (2021-06-18 for -09) Sent
I am the document shepherd.
Stephen Farrell
Yes
David Oran
No Objection
Spencer Dawkins
No Objection
Comment (2021-06-18 for -09) Sent
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).