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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Christopher,

On Tue, Jun 29, 2021 at 7:59 AM Christopher Wood <[e-mail]>
wrote:

> Thanks, Spencer! I wrote the following PR to address these comments:
>
>    https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/230


These changes look fine to me. Thank you for considering my comments.

Best,

Spencer


> 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).
>