Sent from my HTC Touch Pro2 on the Now Network from Sprint®.
-----Original Message-----
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
Sent: Tuesday, December 31, 2013 12:48 PM
To: Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>; Brian E
Carpenter <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>;
ietf(_at_)ietf(_dot_)org <ietf(_at_)ietf(_dot_)org>
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive
Monitoring is an Attack) to Best Current Practice
Hi.
As I indicated in my earlier note, I've been extremely reluctant
to be drawn into this very extensive discussion. As a result,
I've waited until the last day of the LC period to post this
although most of it was written shortly after receiving your
note on the 11th (I have reviewed -03 to be sure that anything
that changed after my earlier comments has been appropriately
reflected(. The reason for my reluctance is rooted in a matter
of principle that I believe many of the people who have
commented do not share and I don't actually expect to change
anyone's mind (especially yours). So I am really not expecting
a response to this note -- I just want it on the record that the
likely decisions do not reflect anything significantly better
than rough consensus.
That principle is that I do not believe the IETF should be
making statements supporting any particular religion or set of
religious principles or, as we might say on this side of the
pond, expressing strong support for motherhood and apple pie.
Statements of general concern are ok, but apparent commitments
to action without specifics seem to me to be ill-advised. To
me, your document, and much of the discussion, reflects the
reason why that principle is important: No matter what
assurances are made to the contrary, we've seen example after
example, general guideline after general guideline, turned into
rigid rules during or after Last Call on particular documents
because some AD decides that a document that doesn't match his
(usually -- I think we've yet to have a really abusive,
testosterone-poisoned, woman AD) ideas of how things should work
and should therefore be blocked until the authors or WG either
conform to whatever "requirement" supports his conclusion or
produce an overwhelming proof that should not be necessary.
I think much of that case had been made by others and was
writing my note in that context (see below). But maybe not.
So, at the risk of repeating something others have said, I don't
want to see a Last Call (or, worse, post-Last Call) debate about
whether the authors of a document that isn't seen to be secure
enough against persuasive surveillance has done everything that
might be possible to mitigate that risk. I'm in favor of
mitigation being considered an important consideration, just as
I'm in favor of privacy considerations more generally being
considered important considerations. But I'm also in favor of
congestion control, operational reasonableness, security
considerations that don't directly relate to privacy including
strong authentication when it is warranted,
internationalization, and a slew of other things that I think we
should be considering when protocols are adopted... and
considered without the impediment of someone saying "well, the
IETF adopted a formal statement that says 'Particular issue XYZ
should be mitigated where possible' so that consideration should
dominate the others."
My problem with going in that direction interacts with your
draft in many ways even though I'm in agreement about the
high-level issue. As a description of an issue, I think it is
fine. When you describe and rely on the consensus reached at
IETF 88, I start having objections because I think the questions
were stated in a way (and context) that made disagreement with
them, or examination of the implications and details, nearly
impossible.
To take an example I hope is not taken as a proposal, the
security of SMTP against in-transit interception and monitoring
of messages could a considerably improved by eliminating
relaying (i.e., the application-level store and forward design
of the protocol). That would have a number of profoundly bad
effects, at least IMO, but it would enable some rather simple
methods of mitigating the threat that are of arguable or complex
utility if relaying is permitted. If the Apps ADs ever get
around to getting back to me about a months-old request to
discuss practical methods of moving RFCs 5321 and 5322 forward
to Internet Standard, I don't think it is reasonable to
legitimize an attempt to impose a requirement that starts with
"RFCnnnn says that monitoring threats should be mitigated where
possible, so we have to return to first principles and debate
whether SMTP should have relaying" when, without such a
statement, we'd be able to say "widely deployed, useful, and
working that way for a few decades, we just don't need to have
that discussion about the base protocols".
From that point of view, when you say "Those developing IETF
specifications need to be able to describe..." [Section 2,
paragraph 4], I get the chills because, despite the mitigating
(sic) second sentence, the third, and the subjectiveness of "a
good answer", allows someone with the inclination to block
almost any application-layer protocol until it is encumbered
sufficiently with privacy decorations to make it unattractive
and unlikely to be adopted in practice. I would like the 5th
paragraph of Section 2, except that I don't look forward to the
pain I believe this document is likely to cause as that
"appropriate balance" emerges and is visited and re-visited.
Now to put my earlier note and your questions about it and its
relevance in context...
--On Wednesday, December 11, 2013 21:19 +0000 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
I've a question about the relevance of your comment
John:
On 12/11/2013 08:53 PM, John C Klensin wrote:
if encryption
were pervasive
The draft in question does not call for that. It calls
for proper consideration of the pervasive monitoring
attack and work to mitigate that.
Use of encryption for confidentiality will be a relevant
mitigation for various protocols, but to comment as if
this draft called for ubiquitous confidentiality seems
very odd if one has read the draft.
Oh, I had read the draft, and read the newer version this week.
What I tried to do was to think about making the broad and
general statements in the draft actionable and what that would
mean. Remembering that I work at the application layer where
almost all data that users might consider sensitive occurs
directly rather than by side-effect, our toolkit is rather
limited. At least at the application level, if there are ways
with most protocols to significantly mitigate pervasive
surveillance that do not replace it with ubiquitous
confidentiality (or with pervasive encryption, which is what I
actually said) and that fall within the scope of IETF protocols,
I don't know what they might be.
Actually, I do, but I think the IETF would find them
unpalatable, and that brings me back to my concern about this
document and its apparent attempt (whether you intended it or
not) to move mitigation of pervasive surveillance to the front
of the tradeoff line. For example, effective surveillance of
traffic content by monitoring of Internet links would become
considerably more difficult if we (pervasively) went back to
routing at the packet (or datagram) level and optimized our
routing algorithms to prefer diverse paths within a stream or
flow. At least as I understand it, that would largely eliminate
the use of MPLS and would slow things down overall unless ISPs
started engineering their networks for more path diversity
between any two endpoints (presumably increasing costs for the
amount of traffic handled). But it would make interception of
a single flow for surveillance purposes a lot more unpleasant
and costly for the monitoring body without requiring encryption.
There are other examples but, as far as I know, they are equally
unattractive... unless frustrating pervasive surveillance
becomes out primary objective (and, as you point out in the last
paragraph of Section 2, that of others).
John - can you say what part of the draft caused you to
incorrectly conclude that "pervasive encryption" (whatever
that means) is even being discussed never mind recommended?
I hope that the above responds to that question, whether we
agree about the conclusions or not.
best regards and best wishes for the new year,
john