Fernando,
Thanks for bringing this discussion to my attention.
This conversation makes me sad and frightened of the future.
I have been involved in teams since 1989 who attempted to crush
attackable numeric identifiers in all layers of software. It started
with RPC XIDs, DNS IDs, TCP IDs, PIDs, UDP/TCP port numbers, pid
numbers, NTP timestamps, it just went on and on. Sadly hundreds of
line-items in standards by IETF, ANSI, and POSIX contain no guidance on
numeric identifier selection, and for decades developers chose the
simplest solutions which generally satisfied the primarly property
("temporal uniqueness"), but failed to consider other desireable
properties (leading to guessability, replay, etc).
Users on the Internet have encountered thousands of attackpoints which
could have been twarted (or been made more difficult) with a bit of
careful consideration.
One path towards solving that problem is introducing crypto layers,
which introduces it's own weight.
Full crypto is not the only path.
Eventually, observance of all the problems converged on the need for
strong random numbers in every Unix subsystem (kernel, libraries,
applications). So our team eventually introduced strong random numbers
into OpenBSD, and inserted utilization of these numbres into every nook
and cranny. (Random numbers also showed up in a few other operating
systems but they did not use them in every nook and crany). We made
per-protocol decisions to retrofit random numbers into each problematic
identifier. We engaged experts where needed, we performed multi-year
interop tests. It took a decade to make safe IDs the default. Then it
took another decade each change to be accepted as safe and correct, and
land in Linux and other systems.
So here we are today -- many legacy layers (such as TCP, DNS, NTP, etc)
use safer numeric identifiers in a majority of implementations, but
often the standards documents have not been updated to state so.
I believe this BCP is being written because it is largely impossible to
update guidance in older documents, and I suspect on a daily basis we'll
see new documents being written which ignore this guidance.
At this point I need to mention two of the authors of this draft were
been involved in two seperate OpenBSD efforts, 20+ years ago, for DNS
IDs, and later for TCP IDs related to RST and ICMP. In each case,
OpenBSD acted as an incubator for their ideas.
BUT WHAT I'M READING IN THIS THREAD ATTEMPTS TO COUNTER NEARLY A
GENERATION OF DEVELOPED WISDOM.
How did a few of you becomes so full of yourselves?
You suggest NO GUIDANCE is needed.
You suggest the guidance is HARMFUL (to your drafts, and to the whole
ecosustem).
In the last 20 years we learned a catagory of simple rules which could
have prevented SIGNIFICANT HARM, but it is written nowhere.
The BCP says a protocol identifiers must be checked for safety, but if
they are safe, the job is done. The BCP provides a checklist against
past problems and details a set of choices good. This is such a simple task,
where is the outrage coming from?
Those rules should be in an IETF document, to ensure that protocol developers
are aware of the guidance.
This process of trying to block the dissemination of guidance to future
protocol developers shocks me.
It makes the IETF teamwork look like a circus.
I believe some of you have an invisible agenda, and your claims for why
this draft is problematic is fake.
I recommend you stop behaving like children.
Please start acting like adults that want a better world, a safer world,
a world where every simple safety measure is considered.
I'd like to close with my theory about what underlies the bogus
criticism that is being provided:
I believe there are people amongst us who recognize that most
recommendations in this BCP collapse to requiring strong random number
generation in all relevant compute environments, and the crypto wars
have begun again and pervasive random numbers are a thread to such people.
As someone who went through the last crypto war, I really hope this BCP
goes through because it will make random numbers generators pervasive.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
