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

[Dan Brown <[e-mail]>]

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

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

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?

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.