On Jan 03, 2014, at 14:22, Ted Lemon <ted(_dot_)lemon(_at_)nominum(_dot_)com>
wrote:
On Jan 3, 2014, at 12:33 PM, Eric Rosen <erosen(_at_)cisco(_dot_)com> wrote:
Ted> The point of the IETF stating a position on this is not to give ADs
Ted> another thing they can hassle document authors about.
One has to look at the likely impact of the draft, not merely at the
intentions of the authors.
I'm sorry, I know that there have been some really painful incidents in the
past, and that people are sensitized to the potential for a repeat, but I'd
like to think that the IETF has learned from those experiences.
You say that we are edging into politics here, but I don't think that's true.
I think that it's entirely appropriate for us to document pervasive
monitoring as an attack, because it is one. If you disagree with that,
that's fine, I'd like to hear your explanation. If you agree that it's an
attack, but think the IETF doesn't need to address it, I'd like to hear about
that. But it seems to me that you are doing neither of those things.
I think one likely impact of this draft is that authors and working groups
will take pervasive monitoring more seriously as a threat when they are
designing their protocols. It's also possible that ADs will use this
document as a bludgeon. I don't think anyone on the current IESG wants to
see that happen. If you completely disagree that authors and working groups
ought to be thinking about this, then I can see why you would argue for
simply scrapping the document. But if you are solely trying to address the
concern that the IESG will go mad with power, then let's talk about how to
tweak the document to address that concern.
Ted’s one likely impact is pretty much exactly why I agreed to sponsor this
draft; I also hoped that the end result coupled with RFC 6973 would be akin to
the two punch combo of BCP 61 & 72.
I guess I’m not shocked and a little amused that we ended up discussing process
impacts especially wrt to this draft knowing Stephen and how much he absolutely
loves process. But, I guess that’s because everybody wants to know how
publication of this draft will affect their standard’s experience (or that we
“engineer" everything). But, the word reasonable in Tim’s message jogged my
memory about another conversation I had:
From: Tim Bray <tbray(_at_)textuality(_dot_)com>
There are very few (any?) absolutes in any of the protocols we build, just a
wealth of often-conflicting design criteria, which force us to trade off and
make judgment calls. draft-perpass-attack says that mitigation of pervasive
surveillance should be seen as one of the design criteria, and it’s not OK to
ignore it. A reasonable take is that a specification could be held up if
there are plausible arguments that this criterion has not been given
appropriate consideration, and I see nothing wrong with that. Similar
hold-ups regularly occur when there are concerns that there hasn’t been
appropriate consideration for efficiency or error-handling or, well, lots of
other criteria.
When I read this draft for the first time, I wondered among other things:
Could publishing this draft make the Internet work better? Some consider
better to be more secure/private so sure I can see that it could and in fact
support that thinking.
Could publishing this draft harm the Internet? (I guess I’m probably not
supposed to be sarcastic here but I can’t help myself) I couldn’t think of a
reason, but I guess I’m not paranoid enough to have thought about the DoS
attack that the IESG can levy against authors ;) More seriously, there’s
plenty of checks on abuse of power in the IETF (appeals, recalls, negative
re-up comments). What you might not know (or believe) is that the IESG does
also self-regulate itself somewhat - if an AD is going off the deep end they’re
going to hear about it from another AD.
Is the draft requesting anything unreasonable or overly burdensome? In my mind,
no on both accounts. In fact, there are already protocols/directorates that
require this; thank you MIB Doctors for requiring of MIBs that sensitive
information or information that raise significant privacy concerns be
explicitly listed by name and the reasons for the sensitivity/privacy concerns
MUST be explained (see RFC 4181).
Is there an out? Yes. If you’ve got a reason to “monitor”, then you just need
to explain why, which is not unlike other “outs”: confidentiality not always
required if you explain why (BCP61), AKM unless … (BCP 107), we also give outs
to experimental protocols (lisp and mptcp comes to mind), etc.
Is there unnecessary process being introduced? I thought not.
Is BCP appropriate? Sure! We’ve published BCPs that document what we want done
as a best practice and what is a best current practice. I’ve tilted at this
windmill both ways and no longer tilt.
Is it all figured out? No, but that is just fine in my book. There’s some
wicked smart people that participate in the IETF and we’ll figure the
process/impacts either now or as we go along. So we can:
1) Publish now, learn as we go, and then publish the normative bits later.
2) Study for [insert timeframe] and then publish the normative bits later way
we know how later.
Possibly naively, I think that publishing now and dealing with the growing
pains of learning as we go option is a bit more in spirit of what the IETF is
supposed to be about. The latter option to me sounds a lot like what people
complain about wrt the IETF process taking too long and having the bar be too
high for the proposed standard level.
spt