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

[Flo D <[e-mail]>]

Thanks to everyone who reviewed the draft, and particular to Sofía and Paul for managing the last call.  I really appreciate the contributions to improve this document.

I'll take away the comments and incorporate them in slower time, aiming for a new version of the draft for the interims between 119 and 120.  If anyone else on the list has any more feedback or suggestions, please do get in touch.

Flo
UK NCSC

-----Original Message-----
From: Pqc <[e-mail]> On Behalf Of Sofía Celi
Sent: Wednesday, March 6, 2024 11:37 PM
To: [e-mail]
Subject: Re: [Pqc] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology

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/

--
Pqc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pqc