Hi Stephan,
Some non-trivial points below, but actually I think your posting
is a great example of why the IETF needs this draft published.
If we do not get that done, then anyone proposing to consider or
mitigate pervasive monitoring is liable to have to re-litigate
this entire debate in whatever WG is involved, because absent an
IETF consensus position on this, you and those who agree with you
will, holding the position you do, feel bound to question such
work, which could be quite disruptive overall. (I'm not saying
you'd be disruptive btw, the ultimate fault if any lies with the
signals intelligence agencies IMO.)
On 01/07/2014 03:41 AM, Stephan Wenger wrote:
Hi all,
As the time window for the last call comes to a close shortly, I want to
chime in. This is going to be my first and last message on this
subject--I will not have time to argue my viewpoints due to other, for me
more important, commitments.
I¹m against publishing this draft in any form. I¹m convinced, based on
the mailing list discussion up to now, and on my own reading, that
publishing this draft has more risks than benefits for myself and for the
IETF. Here are a few condensed points.
1. My personal risk/benefit equation:
The main disconnect I see in the draft is its implicit assumption that an
³attack² is a Bad Thing.
Actually no that terminology (more fully explained in RFC 4949) is
standard in computer security/risk analysis in general and has been
since before my time, so for 40 years or more. While you may not be
a "security guy" that terminology is sufficiently widespread that
I'm very surprised that you don't already know its meaning. What
you're asking would be similar to asking to re-interpret the term
octet and should be similarly regarded IMO.
It¹s an implicit assumption, because after the
very clear definition for ³attack² provided in section 1, the draft
immediately jumps to the subject of the need for the IETF to work towards
mitigation, which implies that there is something (namely the ³attack")
that needs to be mitigated. That is an immensely political statement that
has not been addressed in the draft. There are countless examples where
³attacks² (as defined in the draft) have saved lives and generally have
done good to the world.
There are countless examples of when falling over saved lives too.
That doesn't mean falling over is a good plan.
I¹m personally convinced that, on balance, the
world would be a much worse place without ³attacks² than with.
I see. So you're all for hacking into Belagcom then? I'm sure they'll
be a little sad to hear that. Esp. if the next attacker is not a
government agency.
Without
³attacks², we would probably not have safe mass transportation, terrorist
of different colour would run wild, organized crime would be widespread,
and so on. I DO WANT my communication to be ³attackable² (albeit not
necessarily easily attackable),
So you would like security mechanisms with government-backdoors
but that are hard for anyone else? I want a pony:-)
But seriously, we don't know of a way to do that. Please see
RFCs 1984 and 2804 for some IETF history on that.
based on the assumption that, generally
speaking, me, being a moderately good guy myself, will probably not be
subject to too many attacks by the good guys because my views are
generally better aligned with the good guys than with the bad guys. Even
if the good guys were spying on me, they could hardly use that information
in a way that would hurt me.
That's optimistic.
OTOH, I want that the communication of the
bad guys, be they terrorists, organized crime or whatever, to be broken
into, and their schemes to be disrupted by law enforcement, before they
have a chance to attack (without quotes) me in the very real sense of
flying bullets and blown up planes. For that, I¹m willing to accept that
the bad guys can break my communication as well. This logic obviously
works best, today, when living in a western democracy (like I do),
generally trusting the government (as I do), and having the resources and
the will to fight (like I think I have) if I am ³attacked² by the
government or anyone else for illegitimate reasons (Note that I didn¹t
write ³illegal²).
Note that I have labeled this section ³My personal risk/benefit equation².
I can fully understand if others set other priorities. However, I
participate in the IETF as well, and my viewpoint should (and. I¹m quite
confident, will) be taken into account as those of others, despite it
being perhaps somewhat politically incorrect in the current climate.
That's fair. I'd guess you're fairly clearly in the rough in that
respect. But, taking contrarian views into account here (as should
be done) does not mean making contrarians happy. In this case, as
soon as there are a significant number of people who do not share
your views (and there are) and who would like not to be so vulnerable
to pervasive monitoring, then I think that viewpoint wins, in terms
of what the IETF should be considering and the technical proposals
that we develop since only then is it possible to satisfy both sets
of opinions on this topic. (Folks such as yourself can turn things
off, but the other set can only turn things on after they've been
defined and implemented.)
And in labelling your own view as currently "politically incorrect"
you are accepting that most participants do not share your view,
which implicitly therefore also accepts that the IETF should be
working to develop mitigations to pervasive monitoring as explained
above. The logical position for a self-recognised contrarian such
as yourself is therefore in fact to support the draft!
2. IETF¹s risk/benefit equation
2.a declaring consensus on something like this. The assertion in the
document that it represents IETF consensus (based on the plenary) has
already been competently challenged. No need to repeat.
I'm sorry but that's wrong. First, nobody asserted that the
plenary in Vancouver means that this draft already has consensus.
Second, the plenary in Vancouver did happen, so claiming that it
can be ignored is not credible.
From my POV, I consider the Vancouver plenary in the same way as
I'd consider a huge set (hundreds) of +1 mail messages - there's
no thoughtful statement that the draft captures the hums correctly,
but the draft IMO fairly obviously does that at least imperfectly,
so those hums can be considered to be +1 messages. And in saying
that I do consider a +1 mail as only being a very weak contribution
to establishing rough consensus. I'm not sure how or if Jari will
factor the hums in Vancouver into his evaluation of this LC, but
pretending they never happened would be very wrong.
But let me add
that in this case we have an even stronger problem with the ³silent
majority² than usual. I could imagine that a large percentage of the IETF
participants, especially those living in areas less fortunate than the
western democracies, cannot voice their opinion safely and freely, even if
they wished.
I've no idea what you mean. If you're saying that people in "less
fortunate" areas are less likely to oppose this draft then I think
that's silly.
As stated above, I believe this is an immensely political
draft (for the reason that it makes implicit assumptions), and some folks
have to be more careful than others commenting. I carefully tried to stay
away speculating what their view may be, and I invite others to do the
same--this is not only a political but also a cultural question.
In fact, you are speculating above.
2.b there is the further risk that even more of our standards get silently
disregarded in large parts of the world, potentially leading to less
interoperability and an even more pronounced split between a ³western
democracy Internet² and ³rest of the world Internet". Already, there are
countries where any form of encryption of media data and emails is
forbidden, and one goes to jail (or worse) if one does.
I hear that from time to time. Never accompanied with references though.
And RFC 1984 is our position on that, this draft is not needed.
I don¹t say that
this is a good thing, but fighting the situation is once more an immensely
political process, and I don¹t think the IETF is particularly good at
that, nor does it need to be.
2.c for my own work in the IETF, I do not want to see yet another opening
that potentially allows the security lobby to require me to load up my own
drafts, which have nothing to do with security, with additional security
oriented language. I¹m not a security guy. I don¹t care about pervasive
monitoring; I view it generally as beneficial (see above). Why should I
have answers ready when competent others ask me questions about it? Why
should I see my documents delayed for this stuff? They may well be very
good documents in what they are describing. We have enough boilerplate
and process already, thank you.
The draft does not require any new boilerplate or process. 2c seems
to be back to you personal view.
2.d risk of misrepresentation by the media. The language of the draft is
flashy enough to invite misrepresentation by the media. It cannot be in
the interest of the IETF to see one of its future core docs (process BCPs
are just that, right?) be misinterpreted by journalists, many of which
probably having spent even less time with this doc than myself.
I just disagree about flashy. Its fairly boring now:-)
Readers of RFCs can always mis-represent them. Your claim amounts
to a claim that we should never say anything I think. And you don't
even quote a single sentence that you say could be misrepresented
or that is "flashy." That's not really credible as a criticism.
2.e as for the benefits, where are they? The IETF would be viewed in
certain progressive circles in the western democracies as sensitive
people, especially in year 1 past Snowden. (I¹m not so sure how we would
look in year 1 after the next large scale terrorist attack.) The security
guys would have more work. Nothing against good biz-dev, but does it
really have to be an IETF BCP? :-) What else? Nothing comes to my mind.
See the top-post for one benefit.
Those who do think that attacks are bad things will see benefits
in terms of being less vulnerable.
S.
Thanks for reading.
Best regards,
Stephan
On 12/3/13, 20:45, "Jari Arkko" <jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
I wanted to draw your attention on this last call:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Pervasive Monitoring is an Attack'
<draft-farrell-perpass-attack-02.txt> as Best Current Practice
http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/
It is a short read and important, so please comment. The last call ends
in four weeks and covers holiday time, but we'll deal with this document
on the January 9th telechat in the IESG, so in practice there should be
enough time to comment.
I would like to see this document as a high-level policy we have on
dealing with this particular type of vulnerabilities in the Internet. A
little bit like RFC 3365 "Danvers Doctrine" was on weak vs. strong
security. Please remember that the details and tradeoffs for specific
solutions are for our WGs to consider and not spelled out here. The draft
does say "where possible" - I do not want to give the impression that our
technology can either fully prevent all vulnerabilities or do it in all
situations. There are obviously aspects that do not relate to
communications security (like access to content by your peer) and there
are many practical considerations that may not make it possible to
provide additional privacy protection even when we are talking about the
communications part. But I do believe we need to consider these
vulnerabilities and do our best.
Jari