[saag] Re: Fragmentation, crypto drafts, and a way forwa rd

On Wed, Oct 22, 2025, 7:01 PM Paul Hoffman <[email protected]> wrote:

> Haven't we been here before? Many times in the past 30 years?
>

Not really because the details matter. Also there are some significant
shifts in recent years or even months that have made the situation worse.

>
> 1) Protocol $a needs an algorithm, the WG uses $p, which is recommended by
> NIST, because the WG believes that it is well-studied and secure.


If we're lucky. Sometimes it's $r which was cryptanalyzed within the month
of release (RC4) or dangerously broken for decades (MD5). Or it's some
unfortunate deviation from what NIST recommended that's extremely insecure
(a lot of DH things: leaking the secret length is surprisingly common due
to use of bignum encodings).


> 2) A WG member who is a cryptographer suggests that $a should also allow
> algorithm $q. $q is inherently less studied than $p because more people
> want to find a problem with a NIST-recommended algorithm than some other
> algorithm.
>

There's a lot of important subtleties here. First off, there is no protocol
police. Secondly many registries have moved away from standards action to
spec required, or even loser policies. This means that $q can get deployed.
However, people don't deploy it without reasons. Sometimes those reasons
are regulatory fingerprinting. Other times they are cpu performance due to
changes in how things work (X25519: it would not have been possible to
encrypt all connections to Facebook or Google without it, or encrypt
messages on Apple devices while sleeping), primitives or protocols NIST
hasn't wanted to standardize (any of the pairing stuff or PPM stuff),
tradeoffs NIST hasn't wanted to make (we'll need SQISign for roughtime over
UDP: no way to fit an ML-DSA message easily in there, even if signing and
verification are dog slow).

To the extent do it for the heck of it happens it's largely confined to
CFRG, but that's not really within SAAG's purview (as much as between
muscle mismemory and it makes little sense there I keep typing IETF when
talking to it). And even there there is usually a rationale: we need a
feature AES-GCM doesn't have (committing, nonce reuse resistance, performs
well in side channel resistant way on hardware without a Galois
multiplier), or it does something NIST doesn't, or an IETF WG is basing its
work on it.


> 3) Hilarity ensues.
>

> 3a) People question whether the IETF should even have a second possible
> algorithm for $a because doing so would confuse "the market".
>
> 3b) People say that the WG should even consider $q until it has more study
> (note the lack of actual goalposts).
>
> 3c) People say that the WG is too focused on NIST algorithms, and since $q
> was developed by good cryptographers in {Europe | Asia} it should have
> equal footing as $p for $a.
>
> 3d) Someone produces a paper that shows an attack that indicates that $p
> is {better | worse} than $q for a reason that only a small handful of
> people can understand. The WG goes wild with speculation about how
> important that attack is for $a, or for $b that relies on $a. Later papers
> that describe the effects of the attack come out 6-18 months later; they
> disagree on the severity of the attack. (If the initial paper did not
> reserve a cute name for the attack, the later papers will pick more than
> one.)
>
> 3e) Some of the above appears, badly summarized, on some technical social
> media site. Many people who have never been active in the WG, much less the
> IETF, now have strong opinions that they want to be heard. At least a few
> people use the lack of action in the WG to accept these opinions as proof
> that the IETF is dying.
>
> 3f1) As the above evolves, $a has been successfully deployed with just $p
> for a few years. Many of the WG members start to believe "why should we
> bother with anything else". Others still feel strongly about the not-NIST
> arguments. Some still think that the attack might be significant. The
> discussions polarize.
>
> 3f2) The WG allows the registration of $q with a bit of taint of
> "experimental" or "informational". As the above evolves, $a has been
> successfully deployed mostly with just $p being used, but with a small
> amount of use of $q. People argue about whether that is enough deployment
> to make $q have equal standing with $p. Some people still talk about the
> attack paper.
>
> I'm sure there are other things with multiple instantiations for different
> WGs that can be added above. (I have purposely omitted bullying and
> conspiracy theories, for example.)
>

Working groups have opened up registries to avoid needing to gate
registrations: anyone can go get a registration with a spec attached.
However, there's reasons people want to publish RFCs, either to explicitly
recommend things, document things that could not be easy to find elsewhere,
or career advancement. There's also value in having widely deployed options
published as RFCs.

Why do we view the need to provide advice on what to choose? Well, just
look at what PCI did in response to attacks when we didn't have UTA: they
mandated RC4!

To some extent the ISE and AD sponsorship were relief valves on the
situation, but they have now been closed.

I also notice an absence of actual technical discussion. I completely agree
that that is often a feature of these debates.

>
> There are no guardrails that can prevent this. People will people, and the
> IETF will certainly IETF. Wg participants showing kindness, patience, and
> compassion will reduce some of the damage, but the end results will still
> likely be the same.
>

We could at least localize the damage.

>
> --Paul Hoffman
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
Astra mortemque praestare gradatim

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