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

[Richard Barnes <[e-mail]>]

Hi John,

Thanks for the comments.  A couple of replies inline.

On Tue, Mar 12, 2019 at 1:49 PM John Mattsson <[e-mail]>
wrote:

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

Thanks, I've added this in my local copy.


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

Obviously, I agree, but thanks for a good list of reasons.  I've updated my
local copy with a version of this.



> - 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?
>

I initially had the same reaction, but I'm told that it is common in
practice for folks to use the NaCl box API in this way, i.e., to transmit
an initial crypto context, which is then used for several encryptions.  For
example, that lets you do an ECIES-like operation for content whose length
you don't know at the start.



> If you have two-way communication, you should use a protocol that gives
> PFS.
>

This doesn't presume two-way comms, just that the two parties have some way
to ensure the ordering of the ciphertexts.


I might miss something in the notation, but how does the recipient verify
> than an attacker did not throw away the last ciphertexts?
>

Nothing assures this right now.  Might be a good feature to add.

--Richard



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