Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke

[Richard Barnes <[e-mail]>]

Hi Dan,

Thanks for the comments.   A couple of replies inline below.

On Fri, Apr 26, 2019 at 12:58 PM Dan Brown <[e-mail]> wrote:

>
> > -----Original Message (abbreviated) -----
> > From: Cfrg <[e-mail]> On Behalf Of Paterson Kenneth
> > Sent: Friday, April 26, 2019 4:09 AM
> > This email starts a 2-week adoption call for:
> >
> > Hybrid Public Key Encryption
> >
> > Please give your views on whether this document should be adopted as a
> CFRG
> > draft, and if so, whether you'd be willing to help work on it/review it.
>
> I think it item should be adopted, with changes, though I'm not sure how
> much I will be able to work on it or review it.
>
> Minor comments:
>
> The word "hybrid" now has 3 distinct meanings in crypto, two of them nearly
> opposite.  The older meaning refers a system, with security relying on both
> components of the hybrid, i.e. weakest link.   This is what HPKE means:
> both
> ECDH and AES-GCM must be secure, for example.   A newer, nearly opposite,
> meaning is defense-in-depth, redundancy, strongest-link, etc., for example
> ECC+PQC.   (A third meaning refers to a type of security proof.)  Based on
> its title, this document could be expected to be a how-to on combining
> ECC+PQC+RSA+...  (Arguably, the older meaning of "hybrid" should have
> precedence, and the newer meaning is infringing, etc.)  I recommend
> changing
> "hybrid" to something else, but suffer from writer's block for an
> alternative (sorry).
>

Yeah, Karthik and I spent a fair bit of time brainstorming alternatives,
and didn't come up with anything better.  FWIW, my personal favorite among
what we invented was Combined Asymmetric / Symmetric Hybrid Encryption
Wrapping, or CASHEW.



> A well-known downside of ECIES (and any PKE) is the lack of forward secrecy
> (on the recipient side).  In the olden times of ECC versus RSA, a real risk
> was somebody drop-in replacing RSA by ECIES, even when some type of
> forward-secure ECDH was possible.  The famous example TLS 1.3 of requiring
> (EC)DHE should now minimize this risk. Nonetheless, a PKE document is
> better
> if it (somehow?) recommends the reader to use forward security if possible.
> (Maybe current draft does this well enough already.)
>

I would be be open to suggestions here if you have more concrete thoughts.
My main worry going down this line is that I don't think we want to invent
too much protocol here, vs. keeping this to a fairly small, reusable tool.
Given that forward secrecy typically involves a lot of context and RTTs, it
might be better to punt and say, "You should aim for forward secrecy, and
for that you need more of a full protocol, e.g., MLS".   After all, the
whole point of MLS is arguably to build up from HPKE to something with
forward secrecy and post-compromise security.



> Perhaps differences in HPKE from ECIES standards (i.e. algorithm, security,
> efficiency) - especially if those ECIES standards were implemented - should
> be documented (in an tedious appendix or table)?  Also what about a
> comparison to other types of ECPKE: Cramer--Shoup encryption, NaCL's
> crypto_box, even ECC-in-CMS EnvelopedData, etc?
>

Good idea.  I've filed an issue in our repo.



> An updated link of SEC1 v2 for is http://www.secg.org/sec1-v2.pdf  (Sorry
> that PDF metadata title is version 1.9.) The ECIES in SEC1 v2 is rather
> outdated in its symmetric component (i.e. AEAD part).  It uses a menu of
> KDF, XOR/AES/DES CTR/CBC, HMAC/CMAC, and then some concatenation of 2 extra
> info inputs.  (Perhaps, one day a new version SEC1 will correct/modernize
> this, though CFRG may not care.)
>
> The ANSI X9.63-2011 standard used the extended KDF output as XOR key
> stream,
> and then an "Approved MAC", which allows HMAC, but also allows updates via
> other X9 documents, mainly the registry, (pointing to NIST MACs).
>
> There was an aim that the intersection of the ECIES versions defined IEEE
> 1363a, SEC1 and X9.63 was non-empty.  Not sure if HPKE wants to aim for
> similar backwards interop.
>

Personally, I am not inclined to bother with this.  If someone wants to
work out what it would take to achieve this and propose a solution, I would
be willing to review a proposal.

--Richard



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