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

[Ilari Liusvaara <[e-mail]>]

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=[e-mail]> 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