I think this begs the question of whether currently known and
deployable security technologies are actually adequate to the task
of securing our networks and networked protocols.
well, yes, it quite explicitly begs to have such questions
discussed, but in their own forum and before Last Call for
functions that use them, rather than after.
Well of course we'd like to understand such questions as early as
possible. But that problem is hardly limited to security issues.
There's a real conflict here that we keep dancing around - whose job
is it to determine the requirements for a protocol design?
It's certainly understandable that WGs and individual submitters
don't want to be surprised at the last minute by requirements that
they didn't anticipate. But often this is because the WG or
individual submitters did not really try to investigate or ameliorate
the implications of what they were proposing. And on at least a few
occasions a WG or individual has ignored or disregarded information
about such implications, apparently because it was easier to ignore
the problem and hope it would be overlooked by IESG than to actually
understand and solve it.
I don't think this is quite an either-or situation. We as a
community certainly need to keep increasing our collective
understanding of what it means to do good protocol engineering. But
it is also incumbent on WGs (and individual submitters) to make sure
that they have done due diligence in their protocol designs to
understand the implications of those designs, rather than to place
the burden on others to explain every possible risk to each WG. We
also need to give WGs earlier feedback so that they can fix problems
that they don't discover before they've made a significant investment
in the solution. Neither of these will prevent late surprises, but
together they should reduce the frequency of such surprises. And a
WG that anticipates the problems that might be caused by its proposal
will be in a better position to reduce the effects of those problems,
and perhaps provide an upgrade path for when a better solution is
found, even the problems cannot be entirely solved.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf