[Cfrg] Review of draft-irtf-cfrg-hpke-02

[John Mattsson <[e-mail]>]

This is a well-written and useful draft.

- ”This scheme provides authenticated public key encryption”

   Should mention the unauthenticated mode as well.

- I think it might be useful to add a sentence on ECIES and PSEC in the introduction to help so people searching for “ECIES” will find the draft.

- “Encrypted messages convey a single ciphertext and authentication tag alongside a short public key”

   This made me think the tag was sent a separate field. I suggest changing it to a sentence saying that the ciphertext includes an authentication tag (but some AEAD would not even have a clearly defined tag such as wide PRP ones like XCB.)

   Also, the sentence does not seem to cover the mode that encrypts several plaintexts with the same ephemeral key. I assume the initiator can send several ciphertect with the encapsulation ot ciphertexts without the encapsulation like in the following sequence:

   -> enc, ct1, ct2
   -> ct3

- “mode_auth”, “mode_psk”, “mode_psk_auth”

   The term “auth” is not optimal as psk also provides authentication. Maybe it could it be changes to something related to asymmetric, public-key, or KEM.

- I am missing a Security considerations. I think there are several things that could be mentioned:

  -- How does an application supporting several algorithms protect against downgrade?

  -- Should the receiver do replay protection?

  -- Shortly mention that the construction in the draft protects against attack on earlier ECIES standards such as the Benign malleability and the XOR malleability.

  -- Stating that the protocol does not provide PFS and give some consideration on when that would be ok instead of setting up a TLS connection.

  -- privacy considerations

- “For the NIST curves P-256 and P-521, the Marshal function of the DH
   scheme produces the normal (non-compressed) representation of the
   public key, according to [SECG].”

   Why suddenly referring to SECG?

- Single-Shot APIs

   Should mention that this is stateless.

- The document has very detailed descriptions of the parts KEM, KDF, AEAD, but I miss a short overview section describing which fields the initiator is supposed to send to the receiver and what the initiator and receiver need to agree on out of band. Are any information like pskID and sequence number supposed to be sent on the wire?

- I would like to see P-384 and SHA-384. The US CNSA suite, TLS, and 3GPP are all using these together with AES-256. I would also like to see KMAC.

Cheers,
John