[saag] Re: post quantum guidance draft

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.

I agree that having an open discussion on what to do and why would be a lot more productive than discussing this specific text and if we should have a BCP.

Cheers,
John

From: Tim Hollebeek <[email protected]>
Date: Monday, 1 December 2025 at 18:50
To: Eric Rescorla <[email protected]>, Stephen Farrell <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [saag] Re: post quantum guidance draft

I agree with ekr’s analysis and comments. In addition, I think IETF is at it’s best when we spend our time telling people how to do things correctly, instead of publishing documents telling them what not to do, and I agree with ekr that telling the entire world unilaterally and generically to not do signatures is not helpful, and possibly harmful. At the very least, this document will age badly and be one more thing that needs to be updated in the future, possibly multiple times. We can avoid the maintenance work by not working on it or publishing it.

-Tim

From: Eric Rescorla <[email protected]>
Sent: Monday, December 1, 2025 9:29 AM
To: Stephen Farrell <[email protected]>
Cc: [email protected]
Subject: [saag] Re: post quantum guidance draft



On Mon, Dec 1, 2025 at 6:15 AM Stephen Farrell <[email protected]<mailto:[email protected]>> wrote:

Hiya,

On 01/12/2025 14:07, Eric Rescorla wrote:
> This revision does not affect my opinion on the value of this work,
> which is not based on the introduction and background.
>
> I do not believe the IETF should take it up.

It's entirely fair to have that opinion but can you say why?

I already did so on SECDISPATCH:
https://mailarchive.ietf.org/arch/msg/secdispatch/2ae8yAjMc98__3jTkhKWi-JHvEg/

These comments are about -03, but as I said, they continue to apply.

-Ekr


Ta,
S.


>
> -Ekr
>
>
> On Mon, Dec 1, 2025 at 4:38 AM Stephen Farrell <[email protected]<mailto:[email protected]>>
> wrote:
>
>>
>> Hiya,
>>
>> We chatted a bit about [1] at the secdispatch session
>> in Montreal and the sort-of outcome was that further
>> discussion should be on this list. I've updated [1] a
>> little bit in the meantime.
>>
>> I heard various reactions to [1] at secdispatch and
>> in subsequent chats with a few people, those included:
>>
>> 1. we need something like this (maybe this text or some
>>      other, but some general guidance is needed)
>> 2. we don't need this, specific WGs should provide whatever
>>      guidance is needed, if any
>> 3. we shouldn't bother with this at all, it's just a waste
>>      of time and will go nowhere
>>
>> There are likely other positions on this too of course.
>>
>> Given that we've probably hit 100 new PQ codepoints over
>> the various IANA registries (anyone counted 'em all?), I'm
>> clearly in favour of #1 above. #2 seems likely to make
>> for more confusion and be quite slow, and while #3
>> might turn out to be the case, I think we owe it to
>> people using our stuff to give it a shot.
>>
>> Cheers,
>> S.
>>
>> PS: For those who don't read the draft:-) It doesn't say
>> anything about what WGs should do, it's only about what
>> people deploying stuff ought do in the near term.
>>
>> [1] https://datatracker.ietf.org/doc/draft-farrell-tls-pqg/
>>
>> _______________________________________________
>> saag mailing list -- [email protected]<mailto:[email protected]>
>> To unsubscribe send an email to [email protected]<mailto:[email protected]>
>>
>

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