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

Richard Barnes <rlb@ipv.sx> Mon, 11 March 2019 22:16 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6398C131249 for <cfrg@ietfa.amsl.com>; Mon, 11 Mar 2019 15:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLrNvQKgz0KC for <cfrg@ietfa.amsl.com>; Mon, 11 Mar 2019 15:16:17 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF13131083 for <cfrg@irtf.org>; Mon, 11 Mar 2019 15:16:17 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id a15so303228oid.5 for <cfrg@irtf.org>; Mon, 11 Mar 2019 15:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H5Thx3aOePywfkxHmJGmbefdsEuhhRdibheZsK1aTOY=; b=LX8YJ4IAJN+5klzDaK2MYnDzzrhRM269651zIxSuLhX5kNfaz5UoEbSSr8rg/Pau44 FuPAb6iwLb4yjbRKadIAsDcv69+4/cPkY/16wju7Ib4n9qmPNn3VXD4550Wnxj5fJnxW aFWa5r5+qvinZkZ4+eE8vPj5FX0dGncU4gTp4ET5QhkCHj+7xHqDIo2kGtEcPPNigWT0 VTmZb+cgczJTUtVrKxcQt01PqFdCcQFvBpRnYzB+fICNVYpB79L6eWNQQyGi+byKTiyB EJLiUR4xsuU/Dn7Xh4XWOnzhWPPnGlc3Fzq3jqJcBjc8p0m4g92jZqRcP3Vg1KDvSe6q CdQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H5Thx3aOePywfkxHmJGmbefdsEuhhRdibheZsK1aTOY=; b=Ers+4KWFTgMi1dflTzYLmv2URTq8A2YLSbdyLWwDgCEX1yJooBsz6xfnLauI2Y4DZ1 eY+T4fuBfA6YifD7rhPZRM+4EFkqLAVk/HAf3OERqIPxWwNVWUg77Jykrj/vOYGqlNvG pkbtUlYSOcerlXgnGFs4sF1EGxGA1I+kVPjI8Iy8m74OUyMuafIoL/q1o+9WSC1R6SfW fSNzOCvSIyge7/rlB7j4j5RQElEKXIX1PqBjv/BNTV/S2lDeAFWfEvyUWbpwL/ce+S/N jItGcRRLM6ff/FFCmZB/JKO3Zu8P4sDlAZ7k6s+sLIdxy24rBCSAwBcWcNvMlWM1n9DP S2Kw==
X-Gm-Message-State: APjAAAXtS0Mr+36hnyyWAqNHxD+xY4xpnTTlLzTLkUVSFrc9uJt6WQbg 7b3q5cN32wDmbnmV+jOUChadXGTg/eTCbmRRjdBv5Q==
X-Google-Smtp-Source: APXvYqxGKKeiTp/LpVJ/5l/XgXv4WgqKHrwhYZkiv22aMnABNLzo8XLrsc6yLzkUiiXSqxKMbRsppGHnucmG/c6nIU0=
X-Received: by 2002:aca:3687:: with SMTP id d129mr300700oia.51.1552342576820; Mon, 11 Mar 2019 15:16:16 -0700 (PDT)
MIME-Version: 1.0
References: <4989B595-D57C-4D40-8B68-AB0AF8804AD3@wire.com> <CAO8oSX=KeW_yc8w4v+0E7GGZ1Hp0JNL8x3C5b-Jq=0YKv8XoDQ@mail.gmail.com> <20190128213642.GA2741@LK-Perkele-VII> <CAO8oSXkqYw09w8VT1RoiAo+73V3LCp0osCBFLVheDtt=sA0rYw@mail.gmail.com>
In-Reply-To: <CAO8oSXkqYw09w8VT1RoiAo+73V3LCp0osCBFLVheDtt=sA0rYw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 11 Mar 2019 18:15:49 -0400
Message-ID: <CAL02cgSQxh+LvoqCEZmYBa2rRDwudGCxTP1fS55-gm+noWS5LA@mail.gmail.com>
To: Christopher Wood <christopherwood07@gmail.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000dc8d1d0583d8eb88"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/e188CYdAhurD30nqWTrBnlYOigA>
Subject: Re: [Cfrg] Fwd: New Version Notification for draft-barnes-cfrg-hpke-00.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 22:16:29 -0000

Hey all,

Just in time for the I-D deadline, I have submitted a draft-01 of this HPKE
draft:

https://tools.ietf.org/html/draft-barnes-cfrg-hpke-01

This version incorporates a bunch of feedback from this thread, in
particular, moving from a DH framing to a KEM framing.  It also adds modes
that authenticate possession of a pre-shared key or an asymmetric key
pair.  It also allows multiple encryptions to be done based on a single KEM
operation.

Happy to have more comments on the list here if people have thoughts.  In
particular, there's a lot of different modes in here, and it would be
helpful to hear which of these people think are useful to keep around.
I've also requested an agenda slot for IETF 104.

Thanks,
--Richard


On Mon, Jan 28, 2019 at 5:40 PM Christopher Wood <
christopherwood07@gmail.com> wrote:

> On Mon, Jan 28, 2019 at 1:37 PM Ilari Liusvaara
> <ilariliusvaara@welho.com> wrote:
> >
> >
> > On Mon, Jan 28, 2019 at 09:51:51AM -0800, Christopher Wood wrote:
> > > 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.
> >
> > 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.
>
> The CH would be passed in as additional data, as it is in the current
> draft.
>
> >
> > > 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.
> >
> > 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).
>
> If generalized to work KEMs, could we not restrict the algorithm to
> those KEMs we deem appropriate via ciphersuites?
>
> >
> >
> > 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.
>
> It could probably be expanded to two bytes.
>
> Best,
> Chris
>
> >
> >
> > -Ilari
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>