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

Christopher Wood <> Mon, 28 January 2019 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 445A81310D8 for <>; Mon, 28 Jan 2019 09:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e-KVT78RwLCm for <>; Mon, 28 Jan 2019 09:52:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E8961310D3 for <>; Mon, 28 Jan 2019 09:52:23 -0800 (PST)
Received: by with SMTP id t11so1881606ybi.12 for <>; Mon, 28 Jan 2019 09:52:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IbZbgV5I6+FV0ni9UY+7t36GIPadfY8HTy6fkEIyJ5w=; b=mQWyGMiNrxWsiensNsqQaX4Tio32T5ouM37kPVYZ5WLmfgPT3o/nmtifIE79VAp2zJ pDQ51xWo6XRbbcGDvX88x9Qh8PqoU6HfLwuupkaSnRx6K/zKu3FTU6cruLSI8Mlxszh+ qcfFvyNXVaPK+7MMSuCzz3x6kYKA2U5X3habGZVpZgOnK/haZKr/Zzimj7SU0oDadPpe qOZ8VV/XPhJcB+HxUzFBwnYX8Uu6Tptp0OWVU1VqmG0NnQUcf8l92qjN0069/HJNBYIL j5OjbVPn4idwZ3AywAovmxjQh0nP7jak6fqyfQ+LIrMUK7SV7sX5sKxQw5j4LCZvarfW TjFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IbZbgV5I6+FV0ni9UY+7t36GIPadfY8HTy6fkEIyJ5w=; b=Phtk8gr3IbY0e/VrONRL6gJ7ppkwAnxruDiuH9Pa4J9YHYOEUd/7u5YQ2yNEMPX2hO 5nDa/RZxsKHoA3NNDkzqL4CVHF8nsExSDbrXdbJPieSuBs+ZqvKGQ9FRaVGuieOjhXWc mKmOSXHeu0AoNOy8jTcEHeB3as64Fu/YzOky4t/L2XK8MK4Kw06gE2DksgSlo1mVId/N 1pl20iahUhY+8IpM8AGVs2YggdXR/GsQbxaU5EDn3iYCEecb+bC91oJ6eNLOPUZ2W+Zu Btu2buBua98Sa1+DtL9V8IIXpY1fG8PjGrX+9R0GrTpXyhuZZheMbJEkpL96wVCQEmq4 tiYQ==
X-Gm-Message-State: AHQUAub6r6EBc2S7b5T73ZwyYS0jiGdnt5uUrSX/8OnGU5SVb+Obiy5X rXSpYOe0pVjfG1cRPctLdDVN1/R11YxN+eoFgggKn7I0jA0=
X-Google-Smtp-Source: AHgI3IYkvZrJSsFBBs7JWclpv2PXlhHKMA4XrMUwxc3gAm0LapPdKndNqYDK5wLeVb0TQW/9RwevgDEoqZ81DP3SrSI=
X-Received: by 2002:a25:486:: with SMTP id 128mr8757420ybe.305.1548697941986; Mon, 28 Jan 2019 09:52:21 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Christopher Wood <>
Date: Mon, 28 Jan 2019 09:51:51 -0800
Message-ID: <>
To: Raphael Robert <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Cfrg] Fwd: New Version Notification for draft-barnes-cfrg-hpke-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jan 2019 17:52:25 -0000

On Mon, Jan 28, 2019 at 7:17 AM Raphael Robert
<> wrote:
> Hey Richard,
> The proposal seems rather generic to me and I like the channel binding to the responder's public key.


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.


> 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]
> [1]
> [2]
> [3]
> ---------- Forwarded message ---------
> From: <>;
> Date: Fri, Jan 18, 2019 at 6:08 PM
> Subject: New Version Notification for draft-barnes-cfrg-hpke-00.txt
> To: Richard L. Barnes <>;, Karthikeyan Bhargavan <
> 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:
> Status:
> Htmlized:
> Htmlized:
> 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
> The IETF Secretariat
> _______________________________________________
> Cfrg mailing list