[saag] Re: post quantum guidance draft

Stephen Farrell <[email protected]> Mon, 1 Dec 2025 20:30:37 +0000
Newsgroups	gmane.ietf.saag
Message-ID	<[email protected]>
Hiya,

Answering various postings in one to reduce noise a bit...

Cheers,
S.


On 01/12/2025 17:49, Tim Hollebeek wrote:
 > I think IETF is at it’s best when we spend our time telling people
 > how to do things correctly

I agree. And we're not doing that currently when we're defining
every possible variant of every PQ thing without any guidance as
to what to use.

As to a BCP dating, yep that's true. And IMO is the correct thing
for this situation where our opinion of the best current practice
is changing and will continue to change for some time.

------------------

On 01/12/2025 18:07, John Mattsson 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.

The point of the proposal on signatures is to admit that we don't
know what is generally best to do today (e.g. which combination of
sig-algs/hybrids/whatever). The fact that a CRQC would be devastating
for signers doesn't change that.

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

Yep, the above two points are correct. (I won't update the doc just
yet, but have made a note to do those if/when I make an update.)

 >
 > While non-hybrid/classic algs should be phased out, I don't think
 > standalone PQ KEMs should be NOT RECOMMENDED for ever.

Nothing in the proposal is for ever. This is aimed at being a fairly
short-term BCP updated as we learn more, which may include gaining
sufficient confidence in some PQ KEM over time.

 > I think the IETF should only use well-constructed hybrids following
 > the definition in SP 800-227

Fair enough, but given different protocols have done this differently,
I think it's too late to aim for full consistency there.

 > I agree with most EKR says. I read the draft again. It is unclear to
 > me, which problem the draft want to solve,

Really? I've done a bad job so - ISTM abundantly clear the the IETF
is mucking up by defining too many options related to PQ things and
we've a history of such overabundant options damaging interop.

 > and what the assumptions
 > are for making the recommendation in 3.2

Not really an assumption, but an opinionated assertion that we do
not currently know what's best to do about signatures.

 > that I don't agree with.
 > Any recommendations will be age very quickly so I think a BCP is
 > wrong.

The best practice is actually changing that fast though. I think a
BCP that changes similarly is a good target in that situation.

------------------

On 01/12/2025 18:10, Salz, Rich wrote:
 > At least this conversation is better than the multi-headed appeal-o-
 > rama hydra.

Heh:-) I promise to not appeal the outcome here. (It's so clearly
popular:-)

 > My principal objection is that I do not know who the target audience
It says who. People deploying.

 > is; who would benefit from this, and — most importantly — follow it
 > ?

Who'd benefit? Users getting better interop and maybe hybrid KEMs
more widely deployed sooner. And those deploying by not wasting time
and effort on signatures until the technology is more ready (which
it's currently not).

Who'd follow it? Fair question and hard to tell. My position is that
we owe it to Internet users to give it a try.

------------------

On 01/12/2025 18:11, Loganaden Velvindron wrote:
 > What are the changes that can be made to the draft that address
 > those issues ?

I'm entirely fine if the discussion doesn't focus on the draft.
(Though I think we might end up back there anyway:-)

------------------

On 01/12/2025 18:59, Nico Williams wrote:
> Directives could be to any one, two, or three of
> 
>   - IESG (no protocol action for I-Ds that either specify or make
>     algorithms RECOMMENDED or MTI; could be just about MTI))
> 
>   - RFC-Editor (do not publish <ditto>)
> 
>   - IANA (do not allocate ...)
> 
> For example, I would_not_ be in favor of directives to IANA.

I can't see any of that happening, and it'd be too late in some
cases anyway. I think it seems pretty clear that we have enough
IETF participants who want to define all the PQ things we could
possibly imagine, and if there's consensus to do that (and it
seems there is) then that's that. We can try provide advice as
to what to use now though maybe.

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OpenPGP_signature.asc (application/pgp-signature, 236 B)