[saag] Re: post quantum guidance draft

On Mon, Dec 1, 2025 at 10:07 AM John Mattsson <[email protected]>
wrote:

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

I'm not sure I would call KeyUpdate "quite weak". It's designed to provide
forward security, that's all.

IIRC this design wasn't really chosen for performance reasons but rather for
simplicity reasons. The existing KeyUpdate mechanism is unilateral
(one side can change their keys without the other changing) but KEM-based
rekeying requires a round trip as shown in
draft-ietf-tls-extended-key-update,
and so that makes the state a bit more complicated, or at least that
was the feeling at the time. At least one of the original designs had
an optional DH exchange in it, but we ultimately decided to remove it
in the name of simplification.

-Ekr









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