Subject: [Cfrg] Fwd: New Version Notification for draft-barnes-cfrg-hpke-00.txt

From: Raphael Robert <[email-masked]>
Date: Mon, 28 Jan 2019 16:17:33 +0100

Hey Richard,

The proposal seems rather generic to me and I like the channel binding to the responder's public key.

A few comments:

 - There seems to be some terminology mismatch between (receiver, responder and recipient) also possibly between (initiator and sender).
 - I suppose the ciphersuites are inspired by TLS. I'd like to raise the question if blake2 wouldn't make sense for the non-NIST ones.
 - The points brought up in Appendix A are important. In particular, I think it would be worthwhile investigating if a general KEM mechanism wouldn't be the better choice, potentially paving the way for PQ primitives.

Thanks

Raphael

> Hi CFRG folks,
> 
> I've just posted this draft that Karthik and I have been working on.  You
> may recall my having mentioned it at the IETF in Bangkok; it took us a bit
> longer than expected to get our ducks in a row :)
> 
> The idea here is to write a clean, easy-to-use spec for hybrid public-key
> encryption.  (We're using the name "ECIES", but as the draft notes, the
> idea is clearly more general.)  This primitive has come up in IETF work on
> MLS and ESNI [0][1], and in several other protocols, e.g., through the NaCl
> "box" API [2].  The hope here is to have a single spec that unifies these
> ideas and can be the target of formal verification.
> 
> I admit that there's a little bit of XKCD#927 here [3], but I think there's
> good work to do here in terms of addressing some more modern use cases
> (e.g., streaming / multiple encryptions from a single DH) and possibly
> enabling better post-quantum support by generalizing to KEM instead of DH.
> 
> This is obviously still at -00 quality, but we wanted to go ahead and ask
> whether this was a topic of interest to folks in CFRG.
> 
> Thanks,
> --Richard
> 
> [0]
> https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#direct-paths <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#direct-paths>
> [1] https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-5.1 <https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-5.1>
> [2] https://nacl.cr.yp.to/box.html <https://nacl.cr.yp.to/box.html>
> [3] https://xkcd.com/927/ <https://xkcd.com/927/>
> 
> 
> ---------- Forwarded message ---------
> From: <[email-masked]> <mailto:[email-masked]&gt>;
> Date: Fri, Jan 18, 2019 at 6:08 PM
> Subject: New Version Notification for draft-barnes-cfrg-hpke-00.txt
> To: Richard L. Barnes <[email-masked]> <mailto:[email-masked]&gt>;, Karthikeyan Bhargavan <
> [email-masked]> <mailto:[email-masked]&gt>;
> 
> 
> 
> A new version of I-D, draft-barnes-cfrg-hpke-00.txt
> has been successfully submitted by Richard L. Barnes and posted to the
> IETF repository.
> 
> Name:           draft-barnes-cfrg-hpke
> Revision:       00
> Title:          Hybrid Public Key Encryption
> Document date:  2019-01-18
> Group:          Individual Submission
> Pages:          10
> URL:
> https://www.ietf.org/internet-drafts/draft-barnes-cfrg-hpke-00.txt <https://www.ietf.org/internet-drafts/draft-barnes-cfrg-hpke-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-barnes-cfrg-hpke/ <https://datatracker.ietf.org/doc/draft-barnes-cfrg-hpke/>
> Htmlized:       https://tools.ietf.org/html/draft-barnes-cfrg-hpke-00 <https://tools.ietf.org/html/draft-barnes-cfrg-hpke-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-barnes-cfrg-hpke <https://datatracker.ietf.org/doc/html/draft-barnes-cfrg-hpke>
> 
> 
> 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 Diffie-Hellman group and has a strong security proof.  We
>    provide instantiations of the scheme using standard and efficient
>    primitives.
> 
> 
> 
> 
> 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 <https://tools.ietf.org/>.
> 
> The IETF Secretariat

---

From: Christopher Wood <[email-masked]>
Date: Mon, 28 Jan 2019 09:51:51 -0800

> The proposal seems rather generic to me and I like the channel binding to the responder's public key.

+1

Thanks for posting this draft, Richard! It should suit the ESNI use
case quite well. In particular, servers could advertise HPKE
ciphersuites and key shares, instead of the TLS ciphersuites and
keyshares currently used, and invoke Encrypt() with "esni" or a
similar info string for key derivation.

With regards to the questions raised in Appendix A, I am in favor of
generalizing this to work with any KEM, especially given the rationale
Raphael lists below. The streaming variant is tricky, though, as we
would ideally not want to turn this into a full protocol. In any case,
this is a great -00, and something I think the RG should work on.

Best,
Chris

> https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#direct-paths
> [1] https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-5.1
> [2] https://nacl.cr.yp.to/box.html
> [3] https://xkcd.com/927/
>
>
> From: <[email-masked]>;
> To: Richard L. Barnes <[email-masked]>;, Karthikeyan Bhargavan <
> [email-masked]>;
>
>
>
> https://www.ietf.org/internet-drafts/draft-barnes-cfrg-hpke-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-barnes-cfrg-hpke/
> Htmlized:       https://tools.ietf.org/html/draft-barnes-cfrg-hpke-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-barnes-cfrg-hpke
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 28 Jan 2019 23:36:42 +0200

> similar info string for key derivation.

How is the binding to main key exchange done (I just remember there
were some nontrivial issues there)?

That is, the ESNI ciphertexts must be bound to the client hello those
are in, as otherwise cutting and pasting breaks security.

> this is a great -00, and something I think the RG should work on.

Yes, streaming is tricky. In fact, true stream-mode AE (byte
granularity, reliable in-order) is impossible.

The best approximations are datagram mode AE (datagram granularity,
not reliable) or sequential packet mode (datagram granularity, reliable
in-order) AE. To make things worse, there are protocols that need mode
equivalent to sequential packet mode, and protocols that absolutely
can not use mode equivalent to sequential packet mode.

> > A few comments:
> >
> >  - The points brought up in Appendix A are important. In particular,
> > I think it would be worthwhile investigating if a general KEM
> > mechanism wouldn't be the better choice, potentially paving the way
> > for PQ primitives.

Yes, I think that PQ support is important in any modern protocol (unless
one takes quantum skeptic view). And there are very few DH-compatible
PQC primitives, and the ones that exist are umm... exciting and slow.

However, I do not think any generic KEM would do, as many of those have
too high failure rate, and failures leak information about the private
key (so called reaction attack).

However, there is subclass of KEMs that are IND-CCA secure. Those could
be used (the cost of IND-CCA is higher runtime and larger messages than
generic IND-CPA KEMs).

Few other comments:

- Decryption references function "Decrypt()", which I do not see
  defined anywhere. I suppose it should be "SetupR()"?

- I would expect encryption to pack pkE inside ciphertext, as that
  is per-message and required to decrypt.

- Only one-byte ciphersuite identifier? That seems quite small.

-Ilari

---

From: Christopher Wood <[email-masked]>
Date: Mon, 28 Jan 2019 14:39:59 -0800

> are in, as otherwise cutting and pasting breaks security.

The CH would be passed in as additional data, as it is in the current draft.

> PQC primitives, and the ones that exist are umm... exciting and slow.

:-)

> be used (the cost of IND-CCA is higher runtime and larger messages than

If generalized to work KEMs, could we not restrict the algorithm to
those KEMs we deem appropriate via ciphersuites?

> - Only one-byte ciphersuite identifier? That seems quite small.

It could probably be expanded to two bytes.

Best,
Chris