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

From: John Mattsson <[email-masked]>
Date: Fri, 22 Nov 2019 19:22:31 +0000

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Nov 2019 14:46:54 -0500

Hi John,

Thanks for the comments.  I've reflected them in this PR:

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

Couple of responses inline.

>    Should mention the unauthenticated mode as well.

The challenge here is that we have two meanings of "authenticated".  Every
mode is "authenticated" in the sense of "authenticated encryption".  Some
modes also authenticate some information about the sender.  I'm inclined to
leave this as-is, since I don't see an easy way to reword more clearly.

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

Reworded this whole paragraph to be clearer.

>    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 agree it's suboptimal, but given that this change would touch a lot of
stuff, I'm inclined to leave it unless there's a

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

Sorry, I'm not familiar with these notions.  Maybe you could propose some
text?

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

We discuss some privacy considerations in the "Metadata Protection"
section. Did you have others in mind?

>    Why suddenly referring to SECG?

I understood that was the normal reference for point formats.  Do you have
another preference?

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

I added P-384 and HKDF-SHA-384.  It's not immediately clear how KMAC maps
in here, given the shape the document assumes for KDFs.  It would be
trivial to do HKDF-SHA3, but my guess is that you want something
different.

>
> Cheers,
> John
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>