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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 20 May 2020 13:39 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8293A09C7 for <cfrg@ietfa.amsl.com>; Wed, 20 May 2020 06:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91hQLaxBIDD6 for <cfrg@ietfa.amsl.com>; Wed, 20 May 2020 06:38:58 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07AD3A09CD for <cfrg@ietf.org>; Wed, 20 May 2020 06:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9370; q=dns/txt; s=VRSN; t=1589981938; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=o+1L9QcSqU1L6xrUA9TM0Iii+uWhZ1kq0bhUiX0PC9g=; b=HnhHfyLOcUgiFN1uRchOoIIgK7Z8WUGYNrUFnulS6bRovdukHNBDxGCx S0OkwFWQR5KnTTIrREdU0yYVFp9QJRax61aGUzA1ei1KQMkGdiLFyej0a AXWLTmQoJvUXfZrPKG7PScjYBIwCuJZ1uHkPhyJsvbvb4+Urb9Cu79MYn vgr6PHkM6RVQqpRyXYfcgEKChCjGSFO5zIvYelzyW+4G0W19FsD6QGQVe vCeHuNladBX3BeQ9GJxYWGwflawFmHGO33KoMoqBhOq78/bQJijQ5NV4w zM03Gtc2d/OZyrWVmiBziSM6iK0OkvzTeyAWHCBEJjJ0kuHH3bPRhEK3Y Q==;
IronPort-SDR: /cpnL2VstcTiBCaevP/f4zST5zZ00sJXQLPJoor2IPXbiIEaH5mgLHILcUEnZelzPdVe3gOi9j SL/vvK2q5O/qQQoNAqoFcllaRTgbWM2Av4h3YjrLvPlaAu2QR3t9sNcBeNZ/tpvhWnKHWvDE62 KJEhW4SKUcxKagnrRc2BwpvGWcYtxDggwXR+bJTdQIzmB5vDDo0DAptBqO0zEtNB+A6LtDeRf6 aUtYG++92p+/JJ2iJUiDiLHKf8wif7PCV/OR8d8UWfqJDOoHRcT6d8CmRfNObkI/TOt3OU5CeA MeM=
X-IronPort-AV: E=Sophos;i="5.73,414,1583193600"; d="scan'208";a="1040931"
IronPort-PHdr: =?us-ascii?q?9a23=3AdW5G9h33HjsdQATdsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8ZseMUIvad9pjvdHbS+e9qxAeQG9mCtrQd07ud7fyocFdDyK7JiGoFfp1IWk?= =?us-ascii?q?1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBA?= =?us-ascii?q?j0OxZrKeTpAI7SiNm82/yv95HJbAhEmTqwbalvIBmqqQjducgbjIR/Iast1x?= =?us-ascii?q?XFpWdFdf5Lzm1yP1KTmBj85sa0/JF99ilbpuws+c1dX6jkZqo0VbNXAigoPG?= =?us-ascii?q?Az/83rqALMTRCT6XsGU2UZiQRHDg7Y5xznRJjxsy/6tu1g2CmGOMD9UL45VS?= =?us-ascii?q?i+46ptVRTljjoMOTwk/2HNksF+jLxVrg+9pxJxwIDUYZ2aOvVxca7GYdMaXG?= =?us-ascii?q?hBUtpNWyBdHI+xaZYEAeobPeZfqonwv1UCoxm5BQmoAOPg1DlIiWTo0qIm0O?= =?us-ascii?q?QtCRzN0hE8ENIJrHTUsNv5P7oVXOCuzKnIyjHDb/dI1jf784fHbAwuofKXUL?= =?us-ascii?q?Jub8XR00gvFxjEjlWfr4zpJS+a1uMIs2WC6edrSO2ghXI9pQ5rvjiv2tkjip?= =?us-ascii?q?PPho8NxF3J9Ct3zJs7K9C6R0N2Y9CqHIdTuiyEOIV7XN4uTnxmtis61rELvY?= =?us-ascii?q?C3cigExpopxRPSZPOKfYaG7x/gVeucLjF1j29rdrK4gha960mgyuvkW8m1zl?= =?us-ascii?q?lFsDRKnsPLtnAX2Bze7NWMRPhl/kq5xDqDyxrf5vxGLE06j6bXNp4sz7Aqmp?= =?us-ascii?q?ccsknPBjL6lFnsgKOLdEgo5vKk5/nob7jlvJOQKox5hwfjOao0gMO/G/43Mg?= =?us-ascii?q?0WUmie/uSzyaPs8FXiQLVPkv02iq7ZsI3GJcgDpq62HQtV0oE75huiEzmoyM?= =?us-ascii?q?kUknkfIlxKeR2Lk5XlN0vQIP/kCve/mUysnC1xyP/bJLHhHI/NLmPFkLv7Yb?= =?us-ascii?q?l97EtcxBIyzdBZ+Z1UFqkMLO/vVkPrqdDVDBE0Pxapz+vnBthxzIwTVGGXDq?= =?us-ascii?q?+cKqzSsFuI5uw1I+mLYY8YoC39K/gi5/7qiX82h1kdcrK30pQLa3C1BepmLF?= =?us-ascii?q?uDYXrtmdcBEGgKvgwkQOP2j12CVCZfZ2yuUKIk+jE7FIWmAJ/fSYCjmryB0z?= =?us-ascii?q?y2HpxIaWBaBFCAC3Dod5+LW6REVCXHaMRviDMsVLW9Rckmzx7k/FvxxaBoBu?= =?us-ascii?q?vZ5iNesojsgotb/erWwFsS8jhwAsKX3mqOCylPlWQUW3V+iLt/pkh5x1GJ3K?= =?us-ascii?q?N7q+JVD91I5vxPFAw9MMiPnKRBF9nuV1eZLZ+yQ1G8T4D+DA=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2EUBQAbMsVe/zCZrQo9BQEBGAEJgQmEYoE9liOaJz0LA?= =?us-ascii?q?QEBAQEBAQEBBwETEAwEAQECg32CezgTAgMBAQsBAQEFAQEBAQEFAwEBAQKGE?= =?us-ascii?q?wYmAQuCOyJ3RTkBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEAKBFBZNEzgZA?= =?us-ascii?q?T5CJgEEEQqDH4MLs2CBATOEOgETQUKFDgaBOIwkOIFCPoERgluFFAEKAQGGF?= =?us-ascii?q?ASOMVGJJ4pYkCADB4JTBIgjkCElnXSQSIltk20CBAIEBQIVgWmBeXAvglYBN?= =?us-ascii?q?E8YDYsShTkYiGOFQkhjAgYIAQEDCYwrgRABAQ?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 20 May 2020 09:38:56 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Wed, 20 May 2020 09:38:56 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Thread-Topic: Comments on draft-irtf-cfrg-hpke-04
Thread-Index: AdYuqqrfL8TQxjWJTaex+a27DTh7IQ==
Date: Wed, 20 May 2020 13:38:55 +0000
Message-ID: <c8ba505b874b43af85169dba48724341@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZcTCJkilzCDshxsIj7MwKHNlNuM>
Subject: [Cfrg] Comments on draft-irtf-cfrg-hpke-04
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 13:39:01 -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