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

[John Mattsson <[e-mail]>]

Hi,

This is just what I was looking for a few years ago when we convinced 3GPP to encrypt IMSIs in 5G with a ECIES. I think the move to a more general framework supporting future PQC KEMs is a good choice. A document like this could be very useful.

- "This type of public key encryption has many applications in practice,
   for example, in PGP [RFC6637] and in the developing Messaging Layer
   Security protocol [I-D.ietf-mls-protocol]."

   You could add ESNI and 3GPP TS 33.501 https://www.3gpp.org/DynaReport/33501.htm

- "Lack of a single standard"

   Defining yet another standard will for sure not help :) but the other standards have several problems:

   - most of them are behind paywalls
   - they are showing their age (old algorithms: SHA-1, no AEAD, no HKDF, and design choices that feel dated)
   - some of them do not seem to be updated anymore
   - some of them are not really directly implementable and are more a framework that another SDO can use to build an HPKE
   - some of them do not have test vectors.
   - some are not IND-CCA2

  I think these are problems worth solving.

- I think it would be good to explain the externally visible API in some early section.

- I am not convinced the sequence number based encryption is needed. What would the use cases be? If you have two-way communication, you should use a protocol that gives PFS. I might miss something in the notation, but how does the recipient verify than an attacker did not throw away the last ciphertexts?

Cheers,
John

From: Cfrg <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Monday, 11 March 2019 at 23:17
To: Christopher Wood <[e-mail]>
Cc: CFRG <[e-mail]>
Subject: Re: [Cfrg] Fwd: New Version Notification for draft-barnes-cfrg-hpke-00.txt

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 <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jan 28, 2019 at 1:37 PM Ilari Liusvaara
<[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/cfrg