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

I also support the adoption of this draft.

Marek.

On Tue, Apr 30, 2019 at 5:28 PM mcgrew <mcgrew@cisco.com> wrote:

> 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 <
> kenny.paterson@inf.ethz.ch> 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
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>