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

[Christopher Wood <[e-mail]>]

Thanks, Spencer! I wrote the following PR to address these comments:

   https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/230

Best,
Chris

On Fri, Jun 18, 2021, at 9:58 AM, Spencer Dawkins via Datatracker wrote:
> 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).