Re: [Cfrg] Second RGLC on draft-irtf-cfrg-hpke

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

Sorry for being a bit later than the deadline, however here are some comments anyways.

This is a fairly boring document (boring in cryptography is, of course, a good thing); one concern I had was whether it required concat’ing two variable length fields (which would lead to the possibility of a post-concat collision); I’m pretty sure that in all cases at most one of the inputs is variable length, but someone may want to double check.

Section 5.2
This section correctly states that the encryption (which is a nonce-based AEAD method) needs to be stateful.  However, it also makes the decryption process also stateful; that is, if one encrypted message is lost or corrupted, then later encrypted messages cannot be decrypted.  Is this the intended semantic?

Section  7.1.2
   The keys that "DeriveKeyPair()" produces have only as much entropy as
   the provided input keying material.  For a given KEM, the "ikm"
   parameter given to "DeriveKeyPair()" SHOULD have length at least
   "Nsk", and SHOULD have at least "Nsk" bytes of entropy.
Well, for the defined KEMs (all EC-based), this isn’t bad advice (and is obviously sufficient in all cases).  However, if someone were to define, say, a McEliece KEM, well, it’s rather dramatic overkill (and, yes, as per the note below, McEliece wouldn’t work; it’s just an example).  It might be better to list the suggested entropy based on the security target of the KEM, rather than the secret key length.

One security property (section 8.1) that this does not provide is replay protection; if an adversary were to replay a previous set of messages, the receiver would decrypt it successfully into the a reply of the original plaintext messages.  While this property would be difficult to provide with a noninteractive protocol, this (IMHO) should be listed as a cavaet in the security properties section.

Finally, not a correction, but a word of warning to the authors: this doesn’t translate as well as one would hope into the postquantum realm.  The problem is that (unless you’re relying on PSKs) this design uses a Noninteractive Key Exchange (NIKE) with CCA security; ECDH is a fine example, but postquantum versions are harder to come by.  In particular, none of the NIST finalists and alternatives are NIKEs, and so they would not work here.  Again, this is not something requiring any change to the text…

From: Cfrg <[e-mail]> On Behalf Of Stanislav V. Smyshlyaev
Sent: Sunday, August 16, 2020 4:50 AM
To: CFRG <[e-mail]>
Cc: [e-mail]
Subject: [Cfrg] Second RGLC on draft-irtf-cfrg-hpke

Dear CFRG participants,

This message starts a second 2-week RGLC on "Hybrid Public Key Encryption" (draft-irtf-cfrg-hpke-05), that will end on August 31st. See https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ for the latest version of the draft.

We are having the second RGLC because we didn't have much feedback during the first RGLC and because we have obtained two new Crypto Panel reviews:
https://mailarchive.ietf.org/arch/msg/crypto-panel/Ol1Mm8JUpmgapgq8ppnBQQSlEkE/
https://mailarchive.ietf.org/arch/msg/cfrg/7zhOHPFkCyZC00xLZnsEBT3o6ZU/

Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs.

Regards,
Stanislav, Nick and Alexey