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

[Frederic Jacobs <[e-mail]>]

Hello Richard,

I read it over the weekend and had the following feedback.

Typos:
- Double “the”: "The the shared secret produced by the KEM is combined via the KDF with information describing the key exchange, as well as the explicit info parameter provided by the caller.”
- I assume this was supposed to be “authenticated”: Authentication Encryption with Associated Data (AEAD) Functions

Technical feedback:
- I’ve noticed that in a previous draft, you had ciphersuites defined that are no longer in this version of the document. However, you still refer to a ciphersuite identifier in the context octet string definition:
 context = concat(mode, ciphersuite, enc, pkRm, pkIm,
                      len(pskID), pskID, len(info), info)
I assume this becomes the concatenation of the KEM, KDF, Cipher 2-byte values?

- Some of the example use-cases are examples where the size of the payloads should be minimal. With some standards (eg. 3GPP), the use of NIST-curves  is very important. For those cases, could the compact key representation <https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html> be considered?

- About the info string, in a previous document it was defined as opaque info<0..255>, which now has been changed to opaque info<0..2^16-1>. While I think being able to take longer info, I’m not sure why it’s meant to persist like that in the HPKContext and from an implementation perspective, having a variable-length info buffer complicates things (eg. specifying length in octet string). Implementation-wise I think that just taking an arbitrary info argument and hashing it using the hash function underpinning the key derivation function (or eventually just KDF’ing it) to Nh bytes would make more sense and simplify edge cases in implementation.

- As it currently stands, the RFC doesn’t define a wire format for the payloads. While I think that leaving that possibility is important for adoption in different use cases, it could be useful to define a standard way of concatenating for instance the enc || encryptedPayload and have that in the spec. Optionally defining Elligator-style encoding of the enc to make HPKE payloads less distinguishable.

It’s great to (finally!) see an RFC on interoperable ECIES implementations.

Best,

Frederic

> On 4 Jul 2019, at 13:28, Richard Barnes <[e-mail]> wrote:
> 
> Hi folks,
> 
> After our presentation in Prague and an adoption call on this mailing list, I'm happy to say that we have posted draft-irtf-cfrg-hpke-00. 
> 
> This version has a couple of notable changes from the last individual draft:
> 
> - The "setup" logic across the various modes has been united into a single algorithm
> - As a result, we added a "PSK + Auth" mode, where the sender is authenticated to hold both a PSK and an asymmetric key
> - Instead of one monolithic ciphersuite, individual algorithms are signaled independently
> 
> In addition, there were a bunch of clarifications and bugfixes thanks to Dave Cridland.
> 
> We've asked the chairs for some time to discuss this draft in Montreal, so please take a look and let us know what you think!
> 
> Thanks,
> --Richard
> 
> On Thu, Jul 4, 2019 at 6:09 AM <[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-00.txt
>         Pages           : 17
>         Date            : 2019-07-03
> 
> 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/ <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-00 <https://tools.ietf.org/html/draft-irtf-cfrg-hpke-00>
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-00 <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-00>
> 
> 
> 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/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg