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

[Sofía Celi <[e-mail]>]

Dear, everyone,

Given the reviews that came as part of the procedure, it doesn't seem 
like the document is ready for the publication process. Hence, we will 
hold off, and continue with it as a WG document in a couple of iterations.

Thank you,

On 05/03/2024 21:55, Stephen Farrell wrote:
> 
> 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?
> 
> 
> 
> 
> 
> 

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
she/her, they/them.
Chair of hprc at IRTF, pquip at IETF, and anti-fraud at W3C.
Reach me out at: [e-mail]
Website: https://sofiaceli.com/