[hpke] AD comments on draft-ietf-hpke-hpke

[Deb Cooley <[e-mail]>]

Thanks for this work, I have a few comments, if it is easier to chat about
some of these, I'm happy to do that.  I look forward to the completion of
this specification!

Notes:
 - While I am a mathematician, I am rusty, go easy.
 - This is a top to bottom review.  I did not use a diff between this draft
and the original RFC 9180 as my starting point.  As a result, I've made
comments that would have been relevant to RFC 9180.  Since that RFC is from
the IRTF stream, it didn't have IETF consensus, therefore, I believe my
review is justified.  In the end, as a PS RFC, it will need to be clear to
implementers.

>From idnits (previously provided to the authors):
 - If you obsolete RFC 9180, please mention that in the abstract.
 - There are three references that are never referenced in the draft.
 - There are misc other comments/etc. listed in the experimental version of
idnits.

General:  While the html version of this draft has a different font for
variable names (enc, pt, ct, etc), none of the other formats have this
feature.  Please either use quotes around these structures, or add a note
to the editor to do it for you as part of the editing process.  The section
currently titled 'Discussion Venues' can be expanded to include this note
(possible renaming the section).

General:  While I'm making general comments, I'll point out that these all
exist: 'secret key', 'secret', 'key' where I think mostly 'secret' and
'key' usually mean the same thing.  Can we pick one word to mean the key
used to encrypt/decrypt plain text/cipher text and use it always?  (nothing
we can do about pk = public key vice private key, but it confuses me all
the time)

Section 3:  Please define N.  I assume it is an integer, seems to be used
as a length (as is 'n').

Section 5, para 1, sentence 2:  Replace 'recipient public key' with
'recipient public key skR.

Section 5, second to last para, sentence 1:  Sec 10 is referenced, should
this be Section 9.9?  Or possibly both sections?

Section 9.1.1:  At least provide a reference, if not a brief definition of
IND-CCA2, IND-CPA-secure, and INT-CTXT-secure ([CS01] Section 3.4 doesn't
quite do it).  I'm happy to discuss how to do this so it doesn't complicate
the flow of this draft.

Section 9.1.2, para 2:  'described above' is not obvious.  Do you mean PSK
mode?  or something in the paper referenced.  I'm thinking a reword of this
sentence should add clarity, something like, 'Using the PSK mode, is not
proven in [HPKEAnalysis] to have the hybrid quantum-resistance property
because....'  Obviously the authors might have a better suggestion.

Section 9.2, last sentence:  'element of some set', set of what?

Section 9.4:  Please explain to me why Section 9.1.1 (para 2) suggests that
something other than IND-CCA2 could be secure, compared to what is written
here. While Section 9.4 proposes a sufficient security level, is it indeed
the necessary security level? (note:  I'm not proposing a change to Section
9.4, I want to understand the dichotomy)

Section 9.5:  Is there a suggestion for a fancy PBKDF (my term, possibly
the wrong one for 'turn a password into a psk') to help with the 'low
entropy password' in combination with the classic psk distribution problem?

Section 11 (all subsections):  These registries are 'specification
required', which requires (and indeed has) designated experts.  What it
currently lacks is instructions for the DEs.  Please provide instructions.

Deb
Sec AD