Subject: [Cfrg] Comments on draft-irtf-cfrg-hpke-04

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 20 May 2020 13:38:55 +0000

I have some last call comments on draft-irtf-cfrg-hpke-04 to share from the Verisign Labs team. There's nothing show-stopping, but we do have a number of suggested clarifications and a few questions.

Abstract:  The draft only specifies a Diffie-Hellman-based KEM (Section 4.1). To set expectations for the implementer, we recommend stating this limitation in the abstract, e.g., by adding "based on elliptic curve Diffie-Hellman key agreement" at the end of the last sentence of the abstract.

As guidance for future revisions, we would recommend adding a section about the issues that need to be considered when adding support for other KEMs. There will presumably be industry interest in including post-quantum KEMs (as anticipated in Sec. 8.1), and there may also be interest in including RSA-based KEMs, for legacy support.  The technical subtleties in adding such mechanisms include:

- Assumptions about the relationship between the private key and the public key and the definition of the "pk()" function.  For instance, GenerateKeyPair, listed as part of a KEM in Section 4, doesn't really need to be part of one (it's not part of RSA-KEM).

- Assumptions about the length of the public key.  It may not always be a fixed value, "Npk", for a KEM with a given set of parameters.  The other (and unrelated) "hybrid" draft, draft-ietf-tls-hybrid-design, Section 3.2 ,makes accommodation for public keys associated with a given set of parameters to vary in size.

Introduction:

Asymmetric and symmetric algorithms have been combined since the 1980s, e.g., in Privacy-Enhanced Mail [RFC1113], so a hybrid approach (in the sense of combining the two) can by now be considered the "tradition" of public-key cryptography.  We would therefore suggest replacing the first sentence with the following:

Encryption schemes that combine asymmetric and symmetric algorithms have been specified and practiced since the early days of public-key cryptography (e.g., [RFC1113]).  Combining the two brings the "best of both worlds":  the key management advantages of asymmetric cryptography and the performance benefits of symmetric cryptography.  However, the traditional combination has been "encrypt the symmetric key with the public key."  "Hybrid" public-key encryption schemes (HPKE), specified here, take a different combination, "generate the symmetric key and its encapsulation with the public key." .

Should "formally verified" be "proven secure under standard cryptographic assumptions"?  Or is the intent indeed to enable tools that check correctness of an implementation?

Section 3:  Definition of encode_big_endian:  Add "unsigned" before "integer" if this is the intent (so that the set of encodable n-byte integers clearly includes 0 through 2^{8n}-1).

Section 4.1: Should "#ciphersuites" be changed to a reference to Section 7?

Section 5:

 "we include two authenticated variants .":  We would also suggest mentioning that these variants also contribute additional keying material to the encryption operation.  See also discussion in Section 8.1.

After the sentence, "the constructions described here presume .", mention that the recipient also needs a way to determine which of its public keys was used for the encapsulation operation (if the recipient has more than one public key).  Also add a reference to Section 9 which addresses the corresponding issues for message encoding.

Section 5.1:

 "mode" should also be listed as a key schedule input.

 "assumed that the sender" --> "assured that the sender"

With the revisions in recent drafts, "pkSm" has become a vestigial input to KeySchedule, only provided so that the mode can be checked for correctness, with cryptographic computation on the optional sender's public key fully contained within the encapsulation and decapsulation operations.  We would therefore recommend removing "pkSm" processing from both KeySchedule and VerifyMode.  (It makes sense still to have VerifyMode check "mode" against "psk" and "pskID", since all three are cryptographically processed by KeySchedule.)  This would also simplify SetupAuthS, SetupAuthR, SetupAuthPSKS and SetupAuthPSKR, which, due to the same revisions in recent drafts, now are missing the marshalling step needed to compute "pkSm."

Shouldn't "no_psk" be computed with an "or" rather than an "and"?  If either "psk" or "pskID" has the default value, then an exception should be raised for the two PSK modes.  As the code is currently specified, if exactly one has the default value - which is against the specification - the error would not be detected.  A simpler approach would be to compute just "got_psk" and raise an exception based on "!got_psk" in the PSK modes.

The "label" argument to LabeledExtract is being used in some cases to identify the output, in one case to identify the input, and in one case to identify the intent.  We suggest harmonizing on the former, and also consistently suffixing the output variable name with "_hash" when the purpose of the extraction is to produce a hash of the input.  This would result in the following statements being updated:

info_hash = LabeledExtract(zero(Nh), "info_hash", info) // new label

psk_hash = LabeledExtract(zero(Nh), "psk_hash", psk) // new output name

secret = LabeledExtract(psk_hash, "secret", zz) // new input name and label

The "Context" constructor in the return statement is implied but not defined. We suggest adding a sentence describing what "Context(.)" means and its relationship to the "HPKEContext" structure (which includes the concatenated "context" string, but not "key", "nonce", or "exporter_secret").

Section 5.1.3: The lower-case "must" in "the sender must be the other" might be confused with normative "MUST".  Suggest using a different word or changing to the normative form.

Section 5.2.:

The symbol "<<" isn't defined, but assuming it means "shift left by a specified number of bits", the number of bits to shift should be "8*Nn" rather than "Nn".

Does "overflow" in the third paragraph refer to the same condition as "wrap" in the fifth paragraph?  If so, the text should be combined and a single term used for consistency.  If not, the differences between the two requirements should be explained.  We would also suggest adding a note indicating that the reference code assumes the sequence number is the same length as the nonce.

The use of "Nonce" (capitalized) as a function and "nonce" (lower case) as a value may be confusing.  We suggest instead that the function be named "ComputeNonce" or similar.

On a similar object-oriented programming note, it should be stated that the underlying "Seal" and "Open" functions are the ones determined by the  "aead_id" property.

Section 8.1:  "A full proof of post-quantum security .".  Although we understand that a full proof of post-quantum security may not be achievable within the timeline of this draft's publication, we would nevertheless recommend some additional discussion on what might be desirable to prove.  In the draft, the PSK is employed as an authentication factor, so presumably the proof being contemplated would be that authentication in the modes involving PSKs remains secure against a quantum computer.  A stronger property would be more attractive:  that encryption in the PSK modes remains secure against a quantum computer, whether the KEM itself is post-quantum or not.  If the authors consider this property plausible, then it should be mentioned here as a goal for security analysis.  If not, then the reasons for not targeting this property should also be given.

Section 8.2:

 "avoid identity mis-binding issues":  Perhaps also note that including the public key and the encapsulated key as inputs to key derivation can help with the security proof.  [Shoup] makes this observation in Section 15.6.1.

[Shoup]  @article{shoup2001proposal,
  title={A proposal for an ISO standard for public key encryption (version 2.1)},
  author={Shoup, Victor},
  journal={IACR e-Print Archive},
  volume={112},
  year={2001}
}

"KEM public key pkR" --> "KEM public key "pkR""

"ciphertext enc" --> "encapsulated key enc" (two occurrences).  "Ciphertext" is used elsewhere in the draft to refer to the AEAD output.

Section 8.3:  There is a non-normative (lower-case) "should" in the first sentence.  (Contrasting against a normative/upper-case "SHOULD" in the first sentence of 8.4.)  Should this "should" be "SHOULD"?

Section 8.7:  There are missing quotes around "(enc2, ciphertext2, enc, ciphertext)".

References:

[ANSI]:  Add "X9.63" to title.

[BNT19] and other references as needed:  Add authors' names.

[MAEA10]:  Use "authoritative" URI for long-term stability: https://ieeexplore.ieee.org/abstract/document/5604194/.

Appendix:  "pkR", "pkS" values are given.  These are presumably the same as the marshalled versions "pkRm", "pkSm", this should be stated for completeness.  (In contrast, both "pKE" and the equivalent "enc" are shown.)

Thanks for the good work!

Scott

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 20 May 2020 09:04:02 -0700

Thanks, Scott! I filed a bunch of issues to address these comments (#84 through #98 on the repository): 

   https://github.com/cfrg/draft-irtf-cfrg-hpke/issues

Some of them have already been raised and addressed in the editor's copy of the draft. I'll follow up on this thread if there are particular questions or concerns that arise in dealing with the rest.

Best,
Chris

On Wed, May 20, 2020, at 6:38 AM, Hollenbeck, Scott wrote:
> I have some last call comments on draft-irtf-cfrg-hpke-04 to share from 
> the Verisign Labs team. There's nothing show-stopping, but we do have a 
> number of suggested clarifications and a few questions.
> 
> Abstract:  The draft only specifies a Diffie-Hellman-based KEM (Section 
> 4.1). To set expectations for the implementer, we recommend stating 
> this limitation in the abstract, e.g., by adding "based on elliptic 
> curve Diffie-Hellman key agreement" at the end of the last sentence of 
> the abstract.
> 
> As guidance for future revisions, we would recommend adding a section 
> about the issues that need to be considered when adding support for 
> other KEMs. There will presumably be industry interest in including 
> post-quantum KEMs (as anticipated in Sec. 8.1), and there may also be 
> interest in including RSA-based KEMs, for legacy support.  The 
> technical subtleties in adding such mechanisms include:
> 
> - Assumptions about the relationship between the private key and the 
> public key and the definition of the "pk()" function.  For instance, 
> GenerateKeyPair, listed as part of a KEM in Section 4, doesn't really 
> need to be part of one (it's not part of RSA-KEM).
> 
> - Assumptions about the length of the public key.  It may not always be 
> a fixed value, "Npk", for a KEM with a given set of parameters.  The 
> other (and unrelated) "hybrid" draft, draft-ietf-tls-hybrid-design, 
> Section 3.2 ,makes accommodation for public keys associated with a 
> given set of parameters to vary in size.
> 
> Introduction:
> 
> Asymmetric and symmetric algorithms have been combined since the 1980s, 
> e.g., in Privacy-Enhanced Mail [RFC1113], so a hybrid approach (in the 
> sense of combining the two) can by now be considered the "tradition" of 
> public-key cryptography.  We would therefore suggest replacing the 
> first sentence with the following:
> 
> Encryption schemes that combine asymmetric and symmetric algorithms 
> have been specified and practiced since the early days of public-key 
> cryptography (e.g., [RFC1113]).  Combining the two brings the "best of 
> both worlds":  the key management advantages of asymmetric cryptography 
> and the performance benefits of symmetric cryptography.  However, the 
> traditional combination has been "encrypt the symmetric key with the 
> public key."  "Hybrid" public-key encryption schemes (HPKE), specified 
> here, take a different combination, "generate the symmetric key and its 
> encapsulation with the public key." .
> 
> Should "formally verified" be "proven secure under standard 
> cryptographic assumptions"?  Or is the intent indeed to enable tools 
> that check correctness of an implementation?
> 
> Section 3:  Definition of encode_big_endian:  Add "unsigned" before 
> "integer" if this is the intent (so that the set of encodable n-byte 
> integers clearly includes 0 through 2^{8n}-1).
> 
>  "we include two authenticated variants .":  We would also suggest 
> mentioning that these variants also contribute additional keying 
> material to the encryption operation.  See also discussion in Section 
> 8.1.
> 
> After the sentence, "the constructions described here presume .", 
> mention that the recipient also needs a way to determine which of its 
> public keys was used for the encapsulation operation (if the recipient 
> has more than one public key).  Also add a reference to Section 9 which 
> addresses the corresponding issues for message encoding.
> 
> Section 5.1:
> 
> With the revisions in recent drafts, "pkSm" has become a vestigial 
> input to KeySchedule, only provided so that the mode can be checked for 
> correctness, with cryptographic computation on the optional sender's 
> public key fully contained within the encapsulation and decapsulation 
> operations.  We would therefore recommend removing "pkSm" processing 
> from both KeySchedule and VerifyMode.  (It makes sense still to have 
> VerifyMode check "mode" against "psk" and "pskID", since all three are 
> cryptographically processed by KeySchedule.)  This would also simplify 
> SetupAuthS, SetupAuthR, SetupAuthPSKS and SetupAuthPSKR, which, due to 
> the same revisions in recent drafts, now are missing the marshalling 
> step needed to compute "pkSm."
> 
> Shouldn't "no_psk" be computed with an "or" rather than an "and"?  If 
> either "psk" or "pskID" has the default value, then an exception should 
> be raised for the two PSK modes.  As the code is currently specified, 
> if exactly one has the default value - which is against the 
> specification - the error would not be detected.  A simpler approach 
> would be to compute just "got_psk" and raise an exception based on 
> "!got_psk" in the PSK modes.
> 
> The "label" argument to LabeledExtract is being used in some cases to 
> identify the output, in one case to identify the input, and in one case 
> to identify the intent.  We suggest harmonizing on the former, and also 
> consistently suffixing the output variable name with "_hash" when the 
> purpose of the extraction is to produce a hash of the input.  This 
> would result in the following statements being updated:
> 
> The "Context" constructor in the return statement is implied but not 
> defined. We suggest adding a sentence describing what "Context(.)" 
> means and its relationship to the "HPKEContext" structure (which 
> includes the concatenated "context" string, but not "key", "nonce", or 
> "exporter_secret").
> 
> Section 5.1.3: The lower-case "must" in "the sender must be the other" 
> might be confused with normative "MUST".  Suggest using a different 
> word or changing to the normative form.
> 
> Section 5.2.:
> 
> The symbol "<<" isn't defined, but assuming it means "shift left by a 
> specified number of bits", the number of bits to shift should be "8*Nn" 
> rather than "Nn".
> 
> Does "overflow" in the third paragraph refer to the same condition as 
> "wrap" in the fifth paragraph?  If so, the text should be combined and 
> a single term used for consistency.  If not, the differences between 
> the two requirements should be explained.  We would also suggest adding 
> a note indicating that the reference code assumes the sequence number 
> is the same length as the nonce.
> 
> The use of "Nonce" (capitalized) as a function and "nonce" (lower case) 
> as a value may be confusing.  We suggest instead that the function be 
> named "ComputeNonce" or similar.
> 
> On a similar object-oriented programming note, it should be stated that 
> the underlying "Seal" and "Open" functions are the ones determined by 
> the  "aead_id" property.
> 
> Section 8.1:  "A full proof of post-quantum security .".  Although we 
> understand that a full proof of post-quantum security may not be 
> achievable within the timeline of this draft's publication, we would 
> nevertheless recommend some additional discussion on what might be 
> desirable to prove.  In the draft, the PSK is employed as an 
> authentication factor, so presumably the proof being contemplated would 
> be that authentication in the modes involving PSKs remains secure 
> against a quantum computer.  A stronger property would be more 
> attractive:  that encryption in the PSK modes remains secure against a 
> quantum computer, whether the KEM itself is post-quantum or not.  If 
> the authors consider this property plausible, then it should be 
> mentioned here as a goal for security analysis.  If not, then the 
> reasons for not targeting this property should also be given.
> 
> Section 8.2:
> 
>  "avoid identity mis-binding issues":  Perhaps also note that including 
> the public key and the encapsulated key as inputs to key derivation can 
> help with the security proof.  [Shoup] makes this observation in 
> Section 15.6.1.
> 
> "ciphertext enc" --> "encapsulated key enc" (two occurrences).  
> "Ciphertext" is used elsewhere in the draft to refer to the AEAD output.
> 
> Section 8.3:  There is a non-normative (lower-case) "should" in the 
> first sentence.  (Contrasting against a normative/upper-case "SHOULD" 
> in the first sentence of 8.4.)  Should this "should" be "SHOULD"?
> 
> [MAEA10]:  Use "authoritative" URI for long-term stability: 
> https://ieeexplore.ieee.org/abstract/document/5604194/.
> 
> Appendix:  "pkR", "pkS" values are given.  These are presumably the 
> same as the marshalled versions "pkRm", "pkSm", this should be stated 
> for completeness.  (In contrast, both "pKE" and the equivalent "enc" 
> are shown.)
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>