[saag] Re: post quantum guidance draft

> 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.


Agreed

On Mon, Dec 1, 2025, 1:09 PM John Mattsson <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.
>
> 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]
> <[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/
> <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]
> <[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/
> <https://datatracker.ietf.org/doc/draft-farrell-tls-pqg/>*
> >>
> >> _______________________________________________
> >> saag mailing list -- *[email protected] <[email protected]>*
> >> To unsubscribe send an email to *[email protected]
> <[email protected]>*
> >>
> >
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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