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

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 28 January 2019 21:36 UTC

Return-Path: <ilariliusvaara@welho.com>
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 4DF68131224 for <cfrg@ietfa.amsl.com>; Mon, 28 Jan 2019 13:36:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5NL5sia5E5JP for <cfrg@ietfa.amsl.com>; Mon, 28 Jan 2019 13:36:47 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776A213115A for <cfrg@irtf.org>; Mon, 28 Jan 2019 13:36:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 43D265A0D for <cfrg@irtf.org>; Mon, 28 Jan 2019 23:36:44 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id pyYJfmxmDpGN for <cfrg@irtf.org>; Mon, 28 Jan 2019 23:36:43 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 9CA312321 for <cfrg@irtf.org>; Mon, 28 Jan 2019 23:36:42 +0200 (EET)
Date: Mon, 28 Jan 2019 23:36:42 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: cfrg@irtf.org
Message-ID: <20190128213642.GA2741@LK-Perkele-VII>
References: <4989B595-D57C-4D40-8B68-AB0AF8804AD3@wire.com> <CAO8oSX=KeW_yc8w4v+0E7GGZ1Hp0JNL8x3C5b-Jq=0YKv8XoDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAO8oSX=KeW_yc8w4v+0E7GGZ1Hp0JNL8x3C5b-Jq=0YKv8XoDQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/zJgHFZgHEqIZ5baCj8d4otM8zD0>
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, 28 Jan 2019 21:36:50 -0000

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.

> 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).


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