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

[Christopher Wood <[e-mail]>]

On Mon, Jan 28, 2019 at 1:37 PM Ilari Liusvaara
<[e-mail]> 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=[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.

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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg