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

From: "Paterson Kenneth" <[email-masked]>
Date: Fri, 26 Apr 2019 08:09:17 +0000

Dear CFRG,

(This is the first of two adoption calls today.)

This email starts a 2-week adoption call for:

https://tools.ietf.org/html/draft-barnes-cfrg-hpke-01

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.

Thanks,

Kenny (for the chairs)

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 26 Apr 2019 12:02:33 +0300

Dear colleagues!

I support adoption of the draft and will be happy to review.

Best regards,
Stanislav

пт, 26 апр. 2019 г. в 11:11, Paterson Kenneth <[email-masked]>:

> 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.
>
> Thanks,
>
> Kenny (for the chairs)
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Apr 2019 10:09:07 +0100

Hiya,

On 26/04/2019 09:09, Paterson  Kenneth wrote:
> 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 support adoption and am happy to review.

If this gets adopted for ESNI, then I'd be implementing the
relevant bits too.

Cheers,
S.

> 
> Thanks,
> 
> Kenny (for the chairs)
> 
> 
> _______________________________________________ Cfrg mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 26 Apr 2019 09:20:37 -0400

Perhaps unsurprisingly, I would also like for this draft to be adopted.

I have an implementation of the current draft in Go here:
https://github.com/bifurcation/hpke

I have also implemented the "base" variant within my draft MLS
implementation (in C++):
https://github.com/cisco/mlspp/blob/master/src/crypto.cpp#L1260

---

From: Benjamin Beurdouche <[email-masked]>
Date: Fri, 26 Apr 2019 15:52:46 +0200

Dear all,

I support adoption of this draft as well.

B.

> On Apr 26, 2019, at 3:20 PM, Richard Barnes <[email-masked]> wrote:
> 
> https://github.com/bifurcation/hpke <https://github.com/bifurcation/hpke>
> 
> I have also implemented the "base" variant within my draft MLS implementation (in C++):
> https://github.com/cisco/mlspp/blob/master/src/crypto.cpp#L1260 <https://github.com/cisco/mlspp/blob/master/src/crypto.cpp#L1260>

---

From: Scott Arciszewski <[email-masked]>
Date: Fri, 26 Apr 2019 10:00:08 -0400

I support adoption and would be interested in providing testable reference
implementations in PHP.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

---

From: Dan Brown <[email-masked]>
Date: Fri, 26 Apr 2019 16:57:23 +0000

> -----Original Message (abbreviated) -----
> From: Cfrg <[email-masked]> On Behalf Of Paterson Kenneth
> Sent: Friday, April 26, 2019 4:09 AM
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.

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Apr 2019 14:47:24 -0400

I support adoption of this draft, and I will gladly review it.

Russ

Dear CFRG,

https://tools.ietf.org/html/draft-barnes-cfrg-hpke-01 <https://tools.ietf.org/html/draft-barnes-cfrg-hpke-01>

Thanks,

Kenny (for the chairs)

---

From: denis bider <[email-masked]>
Date: Fri, 26 Apr 2019 21:58:24 -0500

> I recommend changing "hybrid" to something else,
> but suffer from writer's block for an alternative (sorry).

Dual?

---

From: John Mattsson <[email-masked]>
Date: Sat, 27 Apr 2019 07:52:51 +0000

I support adoption. I think https://tools.ietf.org/id/draft-barnes-cfrg-hpke should be modified (if needed) so both ESNI and MLS want to use it.

(See my five cents on the word hybrid below).

John

From: Cfrg <[email-masked]> on behalf of denis bider <[email-masked]>
Date: Saturday, 27 April 2019 at 05:00
To: Dan Brown <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke

Minor comments:

Hybrid has also been used in crypto to describe various “hybrid attacks”. Given this I would say that hybrid in crypto is kind of used just as defined in dictionaries “Hybrid = composed of different elements”.

I think one important aspect is that people wanting to use this construction should find the draft/RFC. Given that Wikipedia use the term “hybrid cryptosystem” for KEM-DEM compositions, I think it might be best to keep hybrid.

https://en.wikipedia.org/wiki/Hybrid_cryptosystem

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 27 Apr 2019 15:36:07 -0400

I support adoption and am willing to review.

Best,
Chris 

On Sat, Apr 27, 2019, at 12:53 AM, John Mattsson wrote:
> *From: *Cfrg <[email-masked]> on behalf of denis bider <[email-masked]>
> *Date: *Saturday, 27 April 2019 at 05:00
> *To: *Dan Brown <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke
> 
> 
> Minor comments:
>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 27 Apr 2019 17:11:34 -0400

Oops, meant to reply all.

On Sat, Apr 27, 2019 at 5:11 PM Richard Barnes <[email-masked]> wrote:

> Thanks, John.  I certainly agree that if we do something here and it's not
> usable by at least ESNI and MLS, then we will have failed.
>
> Also agree about "hybrid".  For better or worse, some terms get
> overloaded, but they're still the right terms.
>
> --Richard
>
> On Sat, Apr 27, 2019 at 3:53 AM John Mattsson <[email-masked]>
> wrote:
>
>> I support adoption. I think
>> https://tools.ietf.org/id/draft-barnes-cfrg-hpke should be modified (if
>> needed) so both ESNI and MLS want to use it.
>>
>>
>>
>> Hybrid has also been used in crypto to describe various “hybrid attacks”.
>> Given this I would say that hybrid in crypto is kind of used just as
>> defined in dictionaries “Hybrid = composed of different elements”.
>>
>>
>>
>> I think one important aspect is that people wanting to use this
>> construction should find the draft/RFC. Given that Wikipedia use the term
>> “hybrid cryptosystem” for KEM-DEM compositions, I think it might be best to
>> keep hybrid.
>>
>>
>>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 27 Apr 2019 17:23:43 -0400

Hi Dan,

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

> "hybrid" to something else, but suffer from writer's block for an

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.

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

> crypto_box, even ECC-in-CMS EnvelopedData, etc?

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

> 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

---

From: Paul Lambert <[email-masked]>
Date: Tue, 30 Apr 2019 06:19:30 -0700

The area of ‘hybrid’ encryption is an important topic and I support the adoption of this work area the CFRG.

The current  'draft-barnes-cfrg-hpke-01’ does have some issues …
 - the first draft was a bit easier to read. the current ’setup’ should be removed/rewritten
 - KEM abstraction is unnecessary and seems to be adequately covered by the DH_Group
 - the PSK mode goals and use cases is unclear
 - PSK mode should use a Security Context Indicator (versus key id). The ’sci’ could be derived from a prior hike message.
 - use case/requirements are lacking …e.g.  should the mechanisms support firmware encryption (word alignment requirements, header requirements)
 - the stateful nature of the encryption risks making this a full key exchange and messaging protocol … maybe not a problem
 - using Initator and Responder does not work well for describing local processing. It’s more consistent for processing to refer to local keys (e.g. my_public_key) and peer keys.
 - it’s not obvious from the draft how the secret key on sent messages uses a different context than the received message. 
   There needs to be two secret keys defined to make this clear.
 - the len(KemContext) is defined as a one byte encoding, but one of the modes has >255 context bytes. This should be a 4 byte little-endian encoding.

Since the draft was written in a Python-like pseudo code, I’ve addressed the issues above in a working Python implementation: 

https://github.com/nymble/hpke/blob/master/hpke.py  

The KEM and ’setup’ functions did not add clarity and these processing steps were implemented in-line (see below). I suspect that the draft would read much better if these were removed.

Some additional comments:
 - The sequence number usage creates a very fragile protocol. The service interface and impact of the communication channel needs consideration.
 - design is not suitable for very large files or small processors
   - validity of header should be able to be validated before processing full encrypted data
   - major fields should be word aligned
   - message layout for in-place encryption/decryption should be considered
- The NIST based cipher suites could be using x-coord encoding for better efficiency
- The AEAD abstract prevents better control/placement of the IV and MAC fields (e.g. MAC always at end)
- Nonce misuse resistant algorithms should be considered as an alternative to keeping sequence number state (e.g. SIV modes)

Paul

—— HPKE wrap … working implementation including one minor message formatting change.

def wrap(self, pt, aad=None, auth=True):
        """ Encrypt using AEAD the plain text 'pt' to the 'peer_pk'
            and return cipher text 'ct'.
        """
        ephemeral_key_pair = self.cipher_suite.DH_Group.generateKeyPair()    # generate the ephemeral key pair

        # definitions for for readability ...
        cs = self.cipher_suite
        marshal = cs.DH_Group.marshal
        hash_length = cs.Hash.digest_size
        info = self.info
        csi = cs.csi # octets
        pkP = self.peer_key
        skE = ephemeral_key_pair    # key pair object used in API rather than private key
        pkE = ephemeral_key_pair.public_key
        skM = self.my_key_pair      #  'M' for secret key of My key pair
        pkM = self.my_key_pair.public_key
        DH  = cs.DH_Group.dh
        KDF = cs.KDF
        Nk = cs.AEAD.key_length
        Nn = cs.AEAD.nonce_length
        
        salt = hash_length * b'\x00'  # all zero octet string
        enc = marshal( pkE )
        
        if auth:                        # authenticated
            mode = MODE_AUTH
            shared_secret = KDF.extract( salt, DH(skE, pkP) + DH(skM, pkP) )
            kemContext = enc + marshal( pkP ) + marshal( pkM )
            sci = KDF.extract( salt, csi + mode + marshal( pkP ) + marshal( pkM ) )

        else:                           # unauthenticated
            mode = MODE_BASE
            shared_secret = KDF.extract( salt, DH(skE, peer_pk) )
            kemContext = enc + marshal( pkP )
            sci = KDF.extract( salt, csi + mode + marshal( pkP ) )
        
        context = csi + mode + blen(kemContext) + kemContext + blen(info) + info
        snd_secret = KDF.expand(shared_secret, b'hpke key'   + context, Nk)
        snd_nonce  = KDF.expand(shared_secret, b'hpke nonce' + context, Nn)
        aead = cs.AEAD( snd_secret )
        snd_seq_bytes = pack( '<L', self.snd_seq )   # little-endian to simplify zero padding by bxor        
        nonce = bxor( snd_nonce, snd_seq_bytes )

        ct = csi + mode + b'\00' + enc + aead.seal(nonce, aad, pt)       #

        self.snd_seq += 1
        
        return ct

Paul

> On Apr 26, 2019, at 1:09 AM, Paterson Kenneth <[email-masked]> wrote:
> 
> Dear CFRG,
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbarnes-2Dcfrg-2Dhpke-2D01&d=DwICAg&c=qgVugHHq3rzouXkEXdxBNQ&r=oIg4FfS8P761BlhMPJ2ys3IvSyH4XQ12Mbj_mXrCAJs&m=Wh8bn9aCR4-MFtTP5yCwkeaQZqO2PAOTRibf5ydPXHw&s=tv3ZjsWTM-r7Yk_XfD-Cgcd8aVedPNI9Ekt2_Q1vbM0&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwICAg&c=qgVugHHq3rzouXkEXdxBNQ&r=oIg4FfS8P761BlhMPJ2ys3IvSyH4XQ12Mbj_mXrCAJs&m=Wh8bn9aCR4-MFtTP5yCwkeaQZqO2PAOTRibf5ydPXHw&s=HD8zv1ivtjPaqEeGlOHxvARItXMw6_tBhK7SLcXXckw&e=

---

From: mcgrew <[email-masked]>
Date: Tue, 30 Apr 2019 11:27:43 -0400

Hi Kenny and Richard, 

I support the adoption of draft-barnes-cfrg-hpke, and I have some comments below.

I like the goal of an RFC that provides a self-contained normative description of "hybrid public key encryption."  

It should be an explicit goal that an implementation can conform to this RFC and also conform to [keyagreement], for the NIST approved algorithms, because NIST validation is important in the industry.  I suggest adding a subsection somewhere that details how this conformance is possible.    Please note that I’m not asking that every possible option/ciphersuite in this document be in the NIST-approved category; rather, I’m asking that for the NIST-approved algorithms, the details such as key generation, domain parameters, and symmetric key derivation don’t have any incompatibilities.

I suggest changing the name from hybrid public key encryption to something from the existing literature.   According to Boyd and Mathuria, for instance, this is a key transport scheme, and the term “hybrid” has a different meaning.   Something like "Key Transport for AEAD Using Discrete Log Cryptography” seems accurate, since this draft only covers DL, there is no need to have a name that would be generic to RSA and McEliece.   “Asymmetric Key Transport for AEAD” would be appropriate if there is a need to be more generic.  

The phrase "Hybrid public-key encryption (HPKE) is a substantially more efficient solution than traditional public key encryption techniques such as those based on RSA or ElGamal” is confusing, because combined asymmetric/symmetric crypto systems have been the preferred solution since Kohnfelder’s 1978 thesis.   Someone without domain expertise might mistakenly think that this draft is claiming to be an improvement over current public key algorithms.   I suggest motivating this draft with something like “While there are well accepted standards for public key encryption [RFC7748][keyagreement], in several scenarios these techniques must be combined with symmetric authenticated encryption."

There should be some discussion about replay attacks and their prevention.  

If there is not a strong mechanism protecting against replays, would it make sense to use an AEAD that is robust against nonce misuse, like GCM-SIV?  

"A given context SHOULD be used either only for encryption or only for decryption.”   Why not a MUST?  

It seems that there is no citation given for P-256 and P-521.  

A nit: KEM is used before it is defined.

thanks

David

> On Apr 26, 2019, at 4:09 AM, Paterson Kenneth <[email-masked]> wrote:
> 
> Dear CFRG,
>