[openpgp] draft-ietf-openpgp-pqc-13 ietf last call Secdir revi ew

Document: draft-ietf-openpgp-pqc
Title: Post-Quantum Cryptography in OpenPGP
Reviewer: Brian Weis
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

The summary of the review is Has Issues.

This document defines a post-quantum public-key algorithm extension for
the OpenPGP protocol. It specifies two "post-quantum/traditional" (PQ/T)
hybrid algorithms, and one stateless hash-based signature scheme,
designed to provide resistance against attacks from a large-scale
quantum computer. Each of these methods results in a single KEK used in
a key wrap algorithm.

The document is very precisely written, and Security Considerations is
very thorough.

Issues

I believe it might be valuable to update  the multiKeyCombine() KDF
defined in Section 4.2.1:

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.

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?

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?


_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]