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

[Stephen Farrell <[e-mail]>]

Hiya,

On 27/11/2019 19:46, Richard Barnes wrote:
> Hi John,
> 
> Thanks for the comments.  I've reflected them in this PR:
> 
> https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/23

Urgh. Why do we always need to define every possible
option even though there's no real demand? There are
already far too many combinations of modes and suites
in hpke.

I'd suggest instead to aim to *remove* options from
the draft. Those that are really needed can be added
later via IANA code point allocations. If you keep all
the myriad options you have now then every IETF WG
will have to spend effort debating which to use and
pointless differences will emerge that may damage
interop.

In case it helps, I've started coding up hpke [1] but
fwiw do not plan to implement every single combination
of everything. I currently have one mode and one suite.
If ESNI/ECHO requires something else, then I'll probably
do that and call it done.

But what might help even more is to not have any new
code points at all but to find a way to re-use TLS
ciphersuite codepoints. I think that could save us
all a lot of bother and make-work related to HPKE.
(And we'd benefit from the "recommended" column in the
TLS registries.)

Cheers,
S.

[1] https://github.com/sftcd/happykey

> 
> Couple of responses inline.
> 
> On Sat, Nov 23, 2019 at 3:22 AM John Mattsson <john.mattsson=
> [e-mail]> wrote:
> 
>> This is a well-written and useful draft.
>>
>> - ”This scheme provides authenticated public key encryption”
>>
>>    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.
>>
>> - “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
>>
> 
> Reworded this whole paragraph to be clearer.
> 
> 
>>
>> - “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 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
> 
> 
>> - 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.
>>
> 
> 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.
>>
>>   -- privacy considerations
>>
> 
> We discuss some privacy considerations in the "Metadata Protection"
> section. Did you have others in mind?
> 
> 
> 
>> - “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?
>>
> 
> I understood that was the normal reference for point formats.  Do you have
> another preference?
> 
> 
> 
>> - 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.
>>
> 
> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>