I think that consideration of perpass at the architectural level, being
prepared to justify decisions, and seeking adequate review of those
decision early enough to make changes if we're wrong are critical to
this document.
strongly object to publication of this document without that.
I value integrity and honesty very highly and am feel sick when I think
about claiming to the world that we're going to address perpass
mitigations without being willing to commit to ourselves to do the
architectural work.
You cannot simply take a protocol and mitigate these sorts of issues.
Many of our existing technologies leak a lot of information to
attackers.
One of the most important decisions when we start work on new protocols
in terms of perpass mitigation will be what building blocks we use.
If we're not willing to commit to having those discussions up front,
reviewing them and when questions arise during that review , I don't
think we're being truthful or acting with integrity if we claim that
we're mittigating perpass threats.
I'd much rather us be honest that we're not willing to do what it takes
to deal with perpass threats than to claim to try and mitigate them with
a solution that I think will be unsuccessful.
I do understand being concerned and worried that an AD would block
something late in the process because of bad architecture.
If the architecture was appropriately reviewed, I think that's the right
wrong approach. I'd support language making that more clear.
If the architecture was inadequately reviewed, I strongly feel that
should be handled like any process problem. Some process problems are
blocking; some cases of inadequate review of an architecture also should
be blocking.
Yes, some of that is subjective and needs to be argued by the IESG and
community if there is conflict.