Re: [Pqc] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology

[Stephen Farrell <[e-mail]>]

Hiya,

I had a read of this. I don't think it's ready. Some of
the text is IMO wrong, (not much, but some), some of the
definitions aren't that good or a little inconsistent,
there are some things included that don't seem useful and
there's a couple of terms I think may be missing.

I'd say all the above is fixable, but might take another
iteration or two. Detailed comments below.

Cheers,
S.

- I think this is missing some terms for an anti-pattern
that defining hybrids enables, that is re-use of private key
material for both a classic and hybrid asymmetric operation.
This has been specifically called out as something that
some people "might want" on the openpgp list, where e.g. a
classic signing private key is on a smartcard/hsm and they
want to both use that independently and to combine it with
a (presumably s/w stored) ml-dsa private value to make an
ml-dsa+ed25519 composite sig. (And have the signer emit
both.) That seems like such an awful practice it deserves
a name. Doing similarly with KEMs is also I guess possible
and probably even worse. How about calling that "PQ/T private
key abuse"? Not sure if different terms for KEMs/sigs are
needed for this anti-pattern. If an even more negative
sounding term could be found for that, that'd be better IMO:-)

- "Signing algorithms in products that are
    expected to be in use for many years are also at risk if a CRQC is
    developed during the operational lifetime of that product."

The above omits important caveats - for example if a system
supports s/w update then the above should not apply in almost
all cases. (And if a system does not support s/w update then
it has, IMO, far harder problems to deal with than a CRQC.)

- "During the transition from traditional to post-quantum algorithms,
    there may be a desire or a requirement"

Why would a "desire" be relevant? I really wish we could stick
to using hybrids when they are required and not when they are
only desired (an error commonly seen, IMO).

- "They may also choose to implement a post-
    quantum algorithm alongside a traditional algorithm for ease of
    migration from an ecosystem where only traditional algorithms are
    implemented and used, to one that only uses post-quantum algorithms."

This is more than a choice - in cases where backwards compatibility
is needed, then emitting a classic signature is needed as well as a
PQ signature that might or might not need to be hybrid/composite.
The point here is that backwards compat is a requirement, we're not
dealing with a fashion choice:-)

- "[RFC4949]"

I say referring to HPKE/RFC9180 would make it clear this usage is
not ancient lore, but is still-current.

- "Traditional Cryptographic Algorithm*:  An asymmetric cryptographic"

Is AES traditional/or PQ according to these definitions? If you qualify
to asymmetric on the RHS, you need it on the left too, if you want
to be precise, which'd seem good in a terminology doc like this.
(Same thing applies elsewhere.)

Also, if you define a scheme to be a set of algs, and a combiner
involves a KDF, then this definition probably also needs to work
for KDFs. That implies "component alg" needs to cover KDFs, and
hence so also does "traditional alg"?

- "*PQ/T Hybrid Public Key Encryption (PKE)*:"

Why is it useful to define this? If the reason is just to say:
"don't do that" (which'd be ok) then be good to say it here.

- Section 3...

I'm not sure this is needed at all. WHen has terminology around
this been confusing? Who else is using these terms? Separately,
I don't think the choice of term is that good here, but I don't
recall if that's been discussed or not.

- "   *PQ/T Hybrid Protocol with Composite Authentication*:  A PQ/T
       hybrid
       protocol that incorporates a PQ/T hybrid scheme to achieve
       authentication, in such a way that the protocol fields and message
       flow are the same as those in a version of the protocol that uses
       a single-algorithm scheme."

That's not a good definition as it doesn't provide a distinguisher
for any protocol that already supports >1 signature, e.g. s/mime or
pgpmime between the case where two independent sigs are carried or
where a composite sig alg is imeplemented below e.g. a crypto API.

- "In a PQ/T hybrid protocol with a composite construction, changes are
    primarily made to the formats of the cryptographic elements, while
    the protocol fields and message flow remain largely unchanged.  In
    implementations, most changes are likely to be made to the
    cryptographic libraries, with minimal changes to the protocol
    libraries."

That is a topic of significant debate and the above only states one
position. Either much more text is needed there or the above should
be deleted. (Probably better to do the latter.)

- "*PQ/T Hybrid Backwards Compatibility*:  The property that a PQ/T
       hybrid scheme or PQ/T hybrid protocol can be completed
       successfully provided that both parties support the traditional
       component algorithm."

The above seems to be missing something - don't you need to say that
if both peers do support classic and PQ, the this protocol gets the
benefit of both? (Likely similar changes needed elsewhere.)

- Section 7...

Not sure that's needed - who else wants to use that term?