Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke

[mcgrew <[e-mail]>]

Hi Kenny and Richard, 

I support the adoption of draft-barnes-cfrg-hpke, and I have some comments below.

I like the goal of an RFC that provides a self-contained normative description of "hybrid public key encryption."  

It should be an explicit goal that an implementation can conform to this RFC and also conform to [keyagreement], for the NIST approved algorithms, because NIST validation is important in the industry.  I suggest adding a subsection somewhere that details how this conformance is possible.    Please note that I’m not asking that every possible option/ciphersuite in this document be in the NIST-approved category; rather, I’m asking that for the NIST-approved algorithms, the details such as key generation, domain parameters, and symmetric key derivation don’t have any incompatibilities.

I suggest changing the name from hybrid public key encryption to something from the existing literature.   According to Boyd and Mathuria, for instance, this is a key transport scheme, and the term “hybrid” has a different meaning.   Something like "Key Transport for AEAD Using Discrete Log Cryptography” seems accurate, since this draft only covers DL, there is no need to have a name that would be generic to RSA and McEliece.   “Asymmetric Key Transport for AEAD” would be appropriate if there is a need to be more generic.  

The phrase "Hybrid public-key encryption (HPKE) is a substantially more efficient solution than traditional public key encryption techniques such as those based on RSA or ElGamal” is confusing, because combined asymmetric/symmetric crypto systems have been the preferred solution since Kohnfelder’s 1978 thesis.   Someone without domain expertise might mistakenly think that this draft is claiming to be an improvement over current public key algorithms.   I suggest motivating this draft with something like “While there are well accepted standards for public key encryption [RFC7748][keyagreement], in several scenarios these techniques must be combined with symmetric authenticated encryption."

There should be some discussion about replay attacks and their prevention.  

If there is not a strong mechanism protecting against replays, would it make sense to use an AEAD that is robust against nonce misuse, like GCM-SIV?  

"A given context SHOULD be used either only for encryption or only for decryption.”   Why not a MUST?  

It seems that there is no citation given for P-256 and P-521.  

A nit: KEM is used before it is defined.

thanks

David


> On Apr 26, 2019, at 4:09 AM, Paterson Kenneth <[e-mail]> wrote:
> 
> Dear CFRG,
> 
> (This is the first of two adoption calls today.)
> 
> This email starts a 2-week adoption call for:
> 
> https://tools.ietf.org/html/draft-barnes-cfrg-hpke-01
> 
> Hybrid Public Key Encryption
> 
> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it.
> 
> Thanks,
> 
> Kenny (for the chairs)
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg