Hi Sam,
On 12/13/2013 11:49 PM, Sam Hartman wrote:
Hi.
I strongly support the consensus statements that were the sense of the
room at the IETF 88 technical plenary.
Cool.
I strongly support publication of a document like this, but I believe
this document should provide more guidance before publication.
I think we disagree about that. More below.
We have a history of publishing vaguely worded security BCPs that are
really hard on our area directors and chairs. As an AD, I found
aspects of RFC 3352, BCP 61 and RFC 4107 very challenging.
Not sure. I've not found our BCP text problematic actually
and I'm not sure that vague wording is the cause of problems.
For example, bcp107/rfc4107 is pretty clear but often difficult
to apply if a WG actually aren't keen on doing the work for
automated key management - I don't think the wording is the
problem at all in cases I've seen.
The big questions tended to surround protocols already in progress and
architectural re-use.
Let's not do that again.
As you'll guess from the above I don't think we have that problem
with vaguely worded BCPs. And I don't think this one is vaguely
worded either - it is high level but not IMO vague.
Protocols already in progress is a fairly obvious problem. I don't
think we want Stephen and Sean to hold a DISCUSS on every document on
the telechat following approval of this BCP because none of them explain
how they mitigate pervasive monitoring. Stephen and Sean wouldn't do
something that ridiculous,
Absolutely. And I don't think any AD would or should do that.
As it happens, my experience over the last 3 years is that the
IESG have self-regulated in a way that would have addressed
this anyway. Many or maybe all new ADs (me included) seem to
start out being a bit too enthusiastic about some aspect of
the IETF but after a while, and sometimes a quiet chat or two,
we've all settled down to a better balance between making
progress and being picky. (Not sure if all authors would
agree mind you:-)
but I believe they and the community could
use better guidance than "use good judgment." I know as a document
author, chair and former AD I sure could.
I'm not sure of that, and I think that's the kernel of where
you and I perhaps disagree here. I don't believe we're in a
position where we can say much more than "use good judgement
and our existing knowledge of the attack and mitigations"
and we won't be in a position to do better for a few years
until we've seen what tends to work in terms of conforming
to the BCP *and getting deployed*.
I really don't want our reaction to Snowdonia to be a work
of fiction and that could happen if we do too much guessing
now.
I also don't want to see us wait years before we reduce the
real consensus that exists to words in an RFC. Doing the
most-significant-bit of that now is important IMO.
my recommendation is that protocols with no significant solution work
accepted by a WG need to address this BCP the same way new protocols
would. Protocols with significant solution work within a WG need to
address this BCP to the extent that doing so is consistent with the
existing work antd doesn't involve reopening decisions that would
otherwise be closed or revisiting earlier stages in the process that
would not otherwise be revisited. So, if you haven't decided on your
security mechanism yet, take this into account. If you're working on
security considerations but your protocol is basically done, write up
how well you did but don't revisit things. If you're in last call, move
on as usual.
The architectural re-use question is harder to explain. Imagine you're
desiging something new. You could use enum-like things or some other
directory. It would be convenient to use DNS because similar
technologies you care about use DNS. If you use DNS, then people can
more easily monitor the queries to your service. How much do you need
to consider pervasive monitoring in your technology choice. We've had
this sort of thing come up lots with previous security BCPs; I most
especially remember being told by PCE that they had chosen not to follow
RFC 4107 because they wanted to be like other routing protocols and use
TCP-AO even though it doesn't provide key management.
The issue of architecture re-use is important to discuss in the
community because it significantly affects how much impact this BCP will
have. If we say "use good judgment," and nothing more, then we're
basically leaving it entirely up to the WGs, because cross-area-review
time is really late for telling someone they need a new fundamental
technology. Obviously the WG will have significant impact on this, but
I think if we provide useful guidance here it can really help. My
personal preference is that this BCP should impact future architectural
choices more than RFC 4107 has managed to but that architectural re-use
is quite important.
A related issue is how to treat extensions to existing protocols.
Again we've had a lot of heart-ache from not specifying that.
I think it is important for the community to receive guidance on these
issues. I think it would be fine for this BCP to delegate that
guidance. I'd support a paragraph describing each issue plus a
paragraph saying that the IESG would provide guidance if the IESG would
be willing to do that. Obviously that would mean we're trusting the
IESG to make that decision; I'd be happy to do that. I'd also be happy
to work on guidance to be included in the BCP on these issues.
I think the above is really useful and should feed into our
analysis of how to deal with the attack. For example, I'd like
to see it reflected in the threat-model document we've discussed.
I think text based on that would fit really well into a section
with a title like "what do I do about this for my protocol?"
maybe.
I do not support the document remaining silent on these issues.
I'm afraid that that would lead to years of delay.
Please, whatever you do, remove section 3 on the process note.
As it stands, it reads as follows:
* We're unable to find a way for the IESG and IAB to publish a document
together
That's accurate. Bit, isn't it;-)
* We really wish the IESG and IAB could publish a document together bbut
reluctantly being unable to do that we'll settle for a community
consensus document.
That's not accurate though. In the IESG/IAB discussion on this,
after a bit of process-flapping, we quickly settled down on the
current plan and I think everyone recognised that this plan will
give a better outcome - IETF consensus being far better than
just IESG/IAB-say-foo.
If you must say something how about:
In the past, architectural statements of this sort have been published
as joint products of the IESG and IAB. This document represents the
community consensus of the IETF and was published in accordance with the
processes in affect at time of publication.
In particular, I think a community statement of the whole community is
stronger than a joint IAB/IESG work product. I'd hope that the IESG and
IAB would support the team and say that "Hey, we're part of the
community, and a community consensus is how we present really strong
statements."
Fair point. Will think about re-wording to make the above clear.
I do think we need section 3 though to say why this is being
done differently from 1984 and 2804.
The IAB also has an ISOC role beyond the IETF. If they want to
emphasize support in that role, they could release a statement on their
own making that clear. However I think it would be more powerful if the
IAB worked with ISOC to release such a statement and was included in
that statement.
One for the IAB.
I'm also still sputtering at the idea that our leadership cannot find a
way within the current process for the IESG and IAB to publish a
document together ifg they wanted to. I don't think that would be
desirable in this instance. We've changed and there's more focus on the
community than there was in the RFC 1984 days. However, I hope that if
it were the right thing to do our leadership could work together and
publish a joint document. The current text really sounds like you
believe you couldn't. Let's try and be better team players than that.
I believe we couldn't and that that's silly. Folks who care more about
process than me would disagree that it's silly. I don't think anyone
is not being a team-player though. (And if this generates more mail,
please make it a separate thread since its tangential to this last
call.)
In response to other last call comments:
I do not support the idea of taking the time to figure out how each WG
is impacted by this document.
I agree.
I understand the desire to figure out whether we have consensus that
pervasive monitoring is a threat quickly. If we find that we have some
open issues to resolve like the ones I bring up, but that we have
consensus on the basic point, we have a quick way forward. Jari could
announce that the consensus of the IETF 88 plenary has been confirmed on
the list and we could move forward. It's rare that the IETF acts in
plenary, but not rare that we make consensus calls about the big points
in documents while details are still open.
As I said above I think the more detailed guidance should not go in
here and will take a long time so we should approve the document and
move forward.
Thanks for the insightful comments,
Cheers,
S.