Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-02.txt

From: Nasrul Zikri <[email-masked]>
Date: Wed, 20 Nov 2019 06:32:24 +0000

On your draft of Hybrid Public Key Encryption.

The draft appears to be for any DH KEM, but I note, however that the
examples and test vectors it gives are only for the elliptic curves
P-256, Curve25519, P-521, Curve448.

Would it be possible to define the algorithm identifiers and test
vectors for some FFDH groups as well as the elliptic curve? Or is there
some important reason why only ECDH methods are suitable?

If FFDH groups are indeed correct for use in the draft, it would appear
that the table in section 8.1 could be extended to allocate identifiers
for at least the parameter ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144,
ffdhe8192 as stated in RFC 7919, and perhaps the MODP groups as stated
in RFC 3526 and RFC 5114.

I would also like there to be a way of specifying the use of a custom
finite field for when the use of a defined elliptic curve or finite
field is not enough. I realise that stating a method for transporting
the parameters {p,q,g} is outside the scope of this draft, but could a
value for custom groups or private use be stated in this table also?

Tk,
Nasrul

> Hey all,
>
> Happy IETF 106 deadline day!
>
> The authors feel that this version of HPKE is substantially complete.  All
> of the functional parts are there, as well as test vectors to facilitate
> interop.  And I think we've got some formal proofs on the way.  Please take
> a look and speak up if you see any gaps.
>
> Thanks,
> --Richard
>
> On Mon, Nov 4, 2019 at 3:47 PM <[email-masked]>; wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Crypto Forum RG of the IRTF.
> >
> >         Title           : Hybrid Public Key Encryption
> >         Authors         : Richard L. Barnes
> >                           Karthik Bhargavan
> >         Filename        : draft-irtf-cfrg-hpke-02.txt
> >         Pages           : 45
> >         Date            : 2019-11-04
> >
> > Abstract:
> >    This document describes a scheme for hybrid public-key encryption
> >    (HPKE).  This scheme provides authenticated public key encryption of
> >    arbitrary-sized plaintexts for a recipient public key.  HPKE works
> >    for any combination of an asymmetric key encapsulation mechanism
> >    (KEM), key derivation function (KDF), and authenticated encryption
> >    with additional data (AEAD) encryption function.  We provide
> >    instantiations of the scheme using widely-used and efficient
> >    primitives.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-irtf-cfrg-hpke-02
> > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-02
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-hpke-02
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Cfrg mailing list
> > [email-masked]
> > https://www.irtf.org/mailman/listinfo/cfrg

---

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Nov 2019 15:02:44 -0500

Hi Nasrul,

Thanks for taking a look at this draft.  Personally, I am disinclined to
define FFDH schemes, unless there are other folks in the RG who think they
would be useful.  That said, the registry policy on group IDs is
Specification Required, so you can get code points if you have a
specification; it doesn't have to be in this doc.  AFAIK, there should be
no technical barrier to doing FFDH.

As far as custom parameters, I think the only reasonable way to accommodate
them here would be to reserve some space in the registry for private,
vendor-specific use.  But this seems like an even worse idea than FFDH, so
again, I'm inclined to do nothing here.

If other folks are interested in these cases, please speak up.

--Richard

On Wed, Nov 20, 2019 at 1:32 AM Nasrul Zikri <[email-masked]>
wrote:

> > >    with additional data (AEAD) encryption function..  We provide