On Sat, Feb 22, 2025 at 07:06:49AM +0000, Geoff Huston wrote:
> So firstly let me quickly recap my understanding of the issues with
> the need for PQC. AS I noted to ekr a day ago I can't find the NIST
> document thought I has seen this.
>
> However the state of the art of quantum computation capability today
> is up to finding the prime factots of 21, so if your required lifetime
> of integrity of secrecy is, say one month, then its hard to support
> the case that you need to use PQC right now.
The source of the confusion in this thread appears to be the use of the
word "integrity" in the construct "integrity of secrecy". This is
because in communications security it is common to distinguish between
data *integrity* (resistance to tampering with the content) and
*privacy* (resistance to interception and decryption, though sometimes
also overlapping with traffic analysis to discover who's communicating
with whom, without content recovery).
In that light "integrity of secrecy" is a somewhat unfortunate choice
of words. Though not a major problem, once the intent is understood.
> So if the sense of the advice in section 3 refers to the use of a
> crypto exchange to protect the privacy of the subsequent session then
> the key consideration is: "What is the period over which you think
> that such privacy protection ios necessary? If your answer is "20
> years" or even 15 years, then you really need to use PQC right now!
> Not "migrate" but "right now". On the other hand if you don't have
> such a requirement then the advice about the shirt fo PQC algorithms
> need not be so strident.
Correct, there is no rush to immediately switch to PQ signatures that
are used to authenticate the peer, but future compromise is not
relevant, because different authentication keys will protect future
sessions.
> Your own need to use PQC is based on a) your estimate as to when such
> tools wil be available and b) how long you want to maintain the
> integrity of privacy.
More clearly just "maintain privacy". There's presently a lot more
interest in and deployment of hybrid (or just solo) ML-KEM, than either
hybrid or solo ML-DSA. There are IANA TLS code points assigned for the
three ML-KEM parameter sets and three hybrids (X25519, P-256 and P-384),
but none yet for ML-DSA.
My Postfix MTA already negotiates X25519MLKEM768 key exchange with
Google's SMTP servers, ML-DSA, on the other hand, is only seen with
another system I deployed, and a personal domain of another PQ early
adopter.
--
Viktor.
_______________________________________________
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
