[saag] Re: post quantum guidance draft

On Mon, 1 Dec 2025 at 22:09, John Mattsson
<[email protected]> wrote:
>
> Nico Williams wrote:
> >Active attacks are always much more challenging to mount.
>
> In this case I would say that the challenge is similar, but the signature active attacks are far more devastating.
>
> - In the passive attack you need to record data and store it for decades (this is not free and anybody wanting to do this need to prioritize as you can very likely not store all data). Then when you have a CRQC you calculate the private key echange key and decrypt. If the communication followed best practices, a single private key only gives limited decades old data.
>
> - In the active attack you do nothing until you have a CRQC, then
> you calculate the private authentication/firmware signing key and completely compromise a device. In many cases the attacks are trivial. The attack gives the attacker access to large volumes of data, real-time data, enables active attacks, and avoids the need to harvest and store traffic for many years.
>
> >Once it becomes practical to use hybrid KEMs, such as X25519MLKEM768 for TLS, we do NOT RECOMMEND use of non-hybrid/classic groups or "pure" PQ KEMs.
>
> I think you intend to say that "pure" PQ KEMs is NOT RECOMMEND also before it becomes practical to use hybrid KEMS.
>
> groups is TLS specific. RSAES-PKCS1-v1_5 and RSAES-OAEP should also be disabled.
>
> While non-hybrid/classic algs should be phased out, I don't think standalone PQ KEMs should be NOT RECOMMENDED for ever. They are clearly better than standalone quantum-vulnerable algorithms and performance matters a lot for security. TLS 1.3 has a quite weak rekeying mechanism instead of rekeying X25519, which would be best practice. I assume this was chosen for performance reasons. People on the TLS list has also said they would like reuse X25519MLKEM768 keys for performance reasons, (unlear if they still want to do that as it now violates NIST requirements).
>
> >Hybrid KEMs are combinations ...
> >Any reasonable Hybrid KEM construction ...
>
> I think the IETF should only use well-constructed hybrids following the definition in SP 800-227
>
> "A well-constructed composite KEM C[Π1, Π2] should preserve the security properties of its component KEMs Π1 and Π2."
>
> >I do not believe the IETF should take it up.
> >I think that discussion would be a lot more productive if it
> didn't happen in the context of this draft and the implicit
> request for it to be worked on in the IETF.
>
> I agree with most EKR says. I read the draft again. It is unclear to me, which problem the draft want to solve, and what the assumptions are for making the recommendation in 3.2 that I don't agree with. Any recommendations will be age very quickly so I think a BCP is wrong.
>
What are the changes that can be made to the draft that address those issues ?

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