On 31/12/20 14:42, Paul Wouters wrote:
On Tue, 29 Dec 2020, Fernando Gont wrote:
Is it that nobody cares? Is it that the topic is not that obvious?
Anything else?
I can only speak for myself. I found the document in question to
basically say the equivalent of "please be careful", and that is not
very useful to me as implementor. I cannot go and check my code
after reading the draft, and I dont really feel that writing new
drafts would be affected by having read this document.
I have no idea how, if you did read the document, you can state that our
document is the equivalent of "please be careful", when it has explicit
and straightforward requirements for protocol spec authors:
* Our document targets protocol spec authors, not protocol
implementers (for instance, RFC3552 targets spec authors)
Our documents tries to get protocol spec authors to do an appropriate
specification and security assessment of the transient numeric
identifiers they employ.
If the resulting specs are better, so will your code. Or at the very
least, it will be pretty evident how/where you screwed up.
* This document specifies requirements for the assessment of transient
numeric identifiers. Protocol spec authors are expected to be aware
about them (that's part of the point of formally updating RFC3552).
This way, if a spec is being progressed without a proper analysis, one
would expect that the wg or responsible AD will quickly spot flawed
numeric IDs, and point them to a document that explains what is expected
from the spec -- with the companion documents providing further details
and examples on how to do it.
In the worst case scenario, the Security AD can spot the problem during
IESG review, and point to this document, with guidance on the topic.
The earlier in the process flaws are spotted and fixed, the better (in
so many different dimensions).
The end result is that the resulting protocol specifications will:
1) Spell out the interop requirements for their numeric IDs. -- so you
(implementer) won't have to second-guess them.
2) have an appropriate vulnerability assessment of the
associated IDs
3) suggest an algorithm that you (implementer) can employ to generate
the numeric IDs, in a way that they comply with the interoperability
requirements in #1, while mitigating the issues found in #2 (if any).
The goal is to result in better protocol specifications, which in turn
will lead into better implementations.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
