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

[Nasrul Zikri <[e-mail]>]

Hello Richard,

Thanks for looking at my use-case. I have been working recently on a quick implementation of FFDH so I would be interested to see how this perform in HPKE. If I can test this first and then request code points later that is good enough. If you can find a way to re-use TLS cipher suite code points (like Stephen say) that is good also because this defines ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144(0x0103), ffdhe8192(0x0104), ffdhe_private_use(0x01FC..0x01FF).

I think there are improvements that can be made for generating custom group for better security and speed. Using custom group help defend against an powerful adversary who would put a lot of work into breaking a fixed group, so I disagree that they are "even worse idea", but I realise there will be difficulties in negotiate parameters for custom group so I don't want to delay your draft.

Tk,
Nasrul


________________________________
From: Richard Barnes <[e-mail]>
Sent: Thursday, November 28, 2019 04:02
To: Nasrul Zikri <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-02.txt

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 <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>>; 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<http://tools.ietf.org>.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Cfrg mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.irtf.org/mailman/listinfo/cfrg


_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/cfrg