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

[Frank Denis <[e-mail]>]

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.





Cheers,
-Frank.