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

On Mon, Jan 28, 2019 at 7:17 AM Raphael Robert
<raphael=40wire.com@dmarc.ietf.org> wrote:
>
> Hey Richard,
>
> 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

>
> 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
> [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/
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>;
> Date: Fri, Jan 18, 2019 at 6:08 PM
> Subject: New Version Notification for draft-barnes-cfrg-hpke-00.txt
> To: Richard L. Barnes <rlb@ipv.sx>;, Karthikeyan Bhargavan <
> karthikeyan.bhargavan@inria.fr>;
>
>
>
> 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
> 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:
>    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.
>
> The IETF Secretariat
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg