[openpgp] Re: draft-ietf-openpgp-pqc-13 ietf last call Secdi r review

Aron Wussler <[email protected]> Tue, 04 Nov 2025 12:57:50 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<yfsNjy6hLUTLkr1LATbXqQFMS5BNgqfiD7qFqHtA_EJvXcHakC7XWKuUAomMoCG122ZeFR6sN3EMgQI3AEdfTMMxKh1eF4y3-ZfCgj2o-H8=@wussler.it>
Hi Brian,

thank you for the throughout review!
We addressed all your point and prepared a couple of MRs on the repository.

> 1. The key derivation function is claimed to be “compliant to Section 4
> of [SP800-56C], based on SHA3-256”. In reviewing the inputs to the hash
> function, this seems to be a fair statement except that one input is
> missing. I note that that Section 4.1 of NIST SP800-56Cc2 specifies
> adding L, which represents the length of “the secret keying material to
> be derived”, which has always been recommended or required in KDFs
> defined by NIST (see NIST SP800-108r1 and NIST SP800-56Br1). It may
> have been intentionally omitted because it was expected that there will
> only ever be one KDF output length, but if in the future there is a
> change to the KDF hash function that results in a different length this
> will be important. I would suggest adding it now — the cost is not
> great.

Length encoding is not necessary because the output length is fixed for the specified combiner, and is always used in full because the algorithms mandate AES-256 in the keywrap. If a new combiner with a different output length is created, then a new value for DomSep should be used.

The references to SP800-108 and SP800-56C are outdated and were related to an older construction we had in the draft. When we started with this draft, the CFRG work on this topic was had not started. Now there are quite stable results in research and in the CFRG drafts. The LAMPS hybrid KEM construction, which is now in WGLC, is based on these, and we have aligned the OpenPGP construction to this as well. Therefore we removed the references to the NIST spec and updated it with the appropriate new references in the following PR: https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/250.


> 2. I’m not sure about the value of len(domSep). Section 9.2.1 mentions
> that it is “guaranteed to result in a suffix-free set of octet strings
> even if further values should be defined for domSep”. I am guessing that
> “suffix” implies that a new domSep is defined that has the
> currently-defined domSep with new octets appended to it, and the intent
> is that len(domSep) will ensure a different output KEK. But a different
> domSep (with either the same initial bytes or not) will already result
> in a different output. So can you clarify what is meant by
> “sufffix-free”, and whether you still think len(domSep) is useful?

Having a len(domSep) makes the construction more robust.
A suffix-free language is one where no word is the ending (suffix) of another word. This property is ensured by appending a length octet: when the length is included, two words that might otherwise share a suffix become distinct, since the suffix (being shorter) always results in a different overall sequence once its length is encoded. 

If the suffix-free-property was not achieved for the possible values of domSep, it could happen that a similarly defined combiner with an unlucky choice for the domSep string induces shifts in the value fields that allow for divide-and-conquer style attacks. This problem was discussed in the context of TLS with reference to the "APOP Attack" [1]. Thus the use of len(domSep) is necessary to achieve a sound construction.


> Nits
> 

> 1. Section 9.1.1: The last sentence references Section 6.1.1 as
> providing a recommendation against key-reuse, but that section doesn’t
> seem to have any recommendations, so wonder if that text was moved to
> earlier in this section?

This is a broken reference, and we have fixed it in PR https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/251

Cheers,
Aron

[1] https://who.rocq.inria.fr/Gaetan.Leurent/files/APOP_IJACT.pdf

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 343 B)