Hi Wes, Steve,
You (Wes) have elaborated nicely what gap this draft is filling (namely: there
is currently no RFC describing an ideal transition), and then concluded by
saying it is needed, while acknowledging there will be situations where the
ideal transition isn't followed (e.g., phases skipped etc.).
We've been living this approach already, both slowly (with introduction of EC
algorithms, close to what the ideal transition would have been) and quickly
(SHA-1 phase-out).
I therefore have difficulty seeing what this document would change in practice;
I'm also not convinced the document would have prevented RedHat from
prematurely turning off SHA-1 support in their OS release, had it existed at
the time.
And as I'm not sure I see the practical impact, I'm confused why it would then
be needed, if things essentially stay the same.
Of course, there's the expert group that would be installed, but that is only
an administrative novelty. Something equivalent could be achieved by adjusting
the gating rules for changing things in the algorithms IANA registry [1].
I'll be very happy to be educated that I'm just missing some essential point.
Best,
Peter
[1]:
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
On 2/2/26 18:22, Wes Hardaker wrote:
Steve Crocker <[email protected]> writes:
Originally I actually didn't see the point of this draft, but obviously
came around in the end. So let me explain my thinking, which may help
others come to a decision (either for or against!) who might be on the
fence or don't understand the "why".
Implementers, i.e. the folks in control of software crypto packages,
will make their own decisions, of course, but the intent here is to
give them clear guidance, with accompanying data, to make their
decisions much easier. Similarly, operators, i.e. the folks in
control of which algorithms in the crypto packages are enabled or
disabled in their services, will also find the guidance helpful.
As Steve has put it multiple times, right now there is a lack of
guidance on what an "ideal" transformation over time would mean. In the
RFC9904 document we carefully laid out how each algorithm can have
different recommendation values for implement vs usage combined with
implement vs deploy. This allowed us the assembly language to document
how the current world and standards sees "right now".
But there isn't a document that specifies the hopeful steps that an
algorithm will progress through over time. Steve, Russ, and I along
with some others had disagreements about RFC9904 and whether it should
be prescriptive in this regard. My stance was "no" because 9904 was
designed to be the assembly language that could encode *any* state, not
just the ideal ones that we believed would be the perfect transmission
path.
The algorithm-lifecycle document fills the hole that provides guidance
over the longer term path an algorithm *might/should* take (and this may
be where Steve and I disagree). There is no way we'll encode the
perfect path sometimes, and the SHA1 case is a fairly good example of
that where the rush to deprecate an algorithm made us move faster than
was otherwise planned.
And this is the important point: I've seen arguments against this draft
saying "you can't always go through phases; what happens when an
algorithm is truly, suddenly broken?". Absolutely! I don't think
anyone has said there aren't times where you must jump straight to "MUST
NOT" in all fields because the cryptography world flipped faster than
expected. The algorithm-lifecycle document prescribes advice *only* on
"if we had the best forward vision, this is what responsible adoption
and deprecation would look like".
That's at least my view. So in the end, I think the document is needed
as it does fill that hole. Is it exactly where I want it to be yet?
probably not. Do I think DNSOP should take it on so we can get it to
where it needs to be, including making sure that it doesn't force an
algorithm to only fit specific values to the 9904 table? Yes. Should
it force a row in the 9904 table to only encode specific values? No,
which I've argued many times. There will always be exceptions to the
perfect.
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
