Re: [CFRG] I-D Action: draft-irtf-cfrg-hpke-08.txt

Frank Denis <> Mon, 19 April 2021 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C10B23A4106 for <>; Mon, 19 Apr 2021 12:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key); domainkeys=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XWyfFbUs1oOQ for <>; Mon, 19 Apr 2021 12:52:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 823E33A40FF for <>; Mon, 19 Apr 2021 12:51:51 -0700 (PDT)
Received: from (localhost []) by (OpenSMTPD) with ESMTP id 7200fd2f for <>; Mon, 19 Apr 2021 21:51:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=selector1; bh=OepJ 2Ga5c4UQEtjn+MbrOiNAFRs=; b=OH+mXWoYKmGC0kuOEbMYjV0pefKjSIbh8ZxY jkImin3mFPJMy3bpbxNp6QiK+IiHsjVJXlmSgkdKdZFeNomrvpsJDhczzp6sVv8A rSZRbA2qAh8rPgTvzcSQV4kVU+NbRopzYVDvpzmTid09d9ooHNZiWDByvaZb2pNY LYWdIpVi0AjzNitJt+7BdB72SIx3O8NQxCQ01Mm/52PRviUKI25+oLosy8NXbVTz rHVuzM8hFJQ/996BDL1C1Pz8Bvij7DbPT6GxXmUqlvUL9oxNRnlAgqQx7mS7Vqpi ydx8zLsbjYKEIXQOv5W3t0oXQhnv0B2s0o/NGP5cEZZoAMss+w==
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; q=dns; s=selector1; b= XGPVdEy3k3afXNa3cilwf0cM0e7bIyrw7y9aQNkY9OA5OxyD2I0+SO7jq+AO9BpH ghRprSX7N9YGRc41kYI2QNITcaJ3+e0jwmhPXdz2uy8hs6LY8QXCz0hCGsaVm+l7 YZRFm2eWHeNWJNJMCRf9NPTRvOmBzKCHJUR1M3LL9s0eLvlYSL3Wx4+PrY+Ilcwr Kp8b1axiAdZbWa7V7ThI2VsHt/CpBtWOaW84HePuuFUzU2yTD+0tKU00rVrmmyFT okbXCmPElRO+zlpMwj8iC9ZPBP1BuDXeH7nxHPkJRp7KcnpdbrTpcpPXkwgpizSX OOXj0VqrXC2kAix7g5ZfJQ==
Received: from ( []) by (OpenSMTPD) with ESMTPSA id 27c4d6ad (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for <>; Mon, 19 Apr 2021 21:51:47 +0200 (CEST)
From: Frank Denis <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 19 Apr 2021 21:51:47 +0200
References: <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [CFRG] I-D Action: draft-irtf-cfrg-hpke-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Apr 2021 19:52:10 -0000

General comments on draft-irtf-cfrg-hpke-08:

* The document is well-written and every function is clearly specified.
I wrote implementations solely based on it, that were verified to be interoperable with other implementations, and didn’t hit anything that required additional information.

* The test vectors also appear to be correct.

Given this, the maturity of the scheme, and the fact that it is a dependency for other protocols, I’d like to see this document move forward.


Additional comments:

* Section 4:

“This function can raise an DecapError” -> “a DecapError”

* Section 4: "The Seal() and Open() functions can return a NonceOverflowError."

The fact that HPKE uses increasing nonces is an internal detail; exposing this to applications looks like the wrong abstraction level.

From an application perspective, a more meaningful error would be `TooManyMessages` or a more generic `Overflow` error that could also encompass the case of the AEAD’s internal counter reaching a limit.

Using `NonceOverflowError` may catalyze inconsistencies between the specification and its implementations.

* Section 4: LabeledExtract() and LabeledExpand() functions

The document doesn’t mention any size limits regarding the `suite_id` and `label` parameters of these functions.

This can be an issue for implementations favoring static/pre-allocated storage space over heap allocations.

Specifying reasonable limits (64 bytes?) may be useful to avoid interoperability issues.
These limits can also be documented in section 7.2.1.

* Section 8.1.3

Splitting this into 2 or 3 paragraphs would make the section more readable.

* Section 8.4: “Further, because HPKE uses AEAD schemes that are not key-committing”

This seems to suggest that non key-committing schemes are a requirement for HPKE, which is not the case.
Further revisions of the document can include key-committing schemes, and exported keys can safely be used with such AEADs.