John,
In a number of places below, you appear to make hugely
misleading and inaccurate characterisations of the text
of the draft, to the point where I think you seem to be
spreading FUD. Can you please explain how I'm wrong in
that conclusion? Ideally via reference to the actual
text, and justification for how you make the gigantic
leaps from that text to your vastly overstated
mischaracterisations below.
Or, since I'll separately address what I guess might be
the potential concerns behind the FUD that is here, you
can if you like ignore this message and just respond to
a mail I'll send later today.
On 12/31/2013 08:48 PM, John C Klensin wrote:
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.
I'm sorry but I think the term religion above is purely
being used as a pejorative, and wrongly in this case. Or
maybe you can justify the use of the term via at least
some reference to the actual text of the draft?
Statements of general concern are ok, but apparent commitments
to action without specifics seem to me to be ill-advised.
Disagree. Ted Lemon put it well. This draft represents the
high-order bit but there's more work on going and to be
started.
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 that's spreading FUD to be honest. I can't see how its
anything else.
And again, as Ted said, if some AD wanted to be a pain in that
way, there's plenty of ammunition available today for that (see
the 2119 references in 3552 for an example of such ammunition
that is not used). Indeed 3552 is a fine example of why we do
not want BCPs that contain too much detail - that detail will
go out of date or not apply to new situations and overall
adds to the potential ammunition that a misguided AD could use
to badly affect ongoing work. Any such detailed guidance should
be based on reality and not be theoretical IMO and so should
emerge from what we find can actually be deployed.
This BCP will not change the potential for any AD to abuse the
IETF. Not a whit. And it really doesn't matter what happened
10 years ago or whenever you care to pick.
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.
"Everything that might be possible" is a serious mis-reading of
the draft and *nothing like* what's stated in the draft. I can't
see how you get that from the text. If there is text there that
could really be mis-read that badly then please point at it so
we can fix it.
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."
"Dominate the others" is another serious mis-reading. Again, please
point at the text that has so confused you. (To be honest, I don't
think its there so am mystified that you can get this meaning
from the current text.)
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.
You expected to examine all the implications and details in a
room with ~1000 people?
In any case, this draft does not, and should not, try to
examine all the implications since we don't know them all yet.
Nonetheless if we don't have this BCP then we will have to
re-litgate the overall discussion many times, which will
(I predict) effectively prevent us from making progress on
the more substantive issues with protocols. That is one harm
in your position and those of others who want to wait and
do nothing until everything is "clear."
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".
I have no idea how that is relevant. Are you suggesting that
this BCP will suddenly mean that bad ideas get airtime when
they previously would have been discarded? That seems silly.
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.
See above. I think that's a frankly weird mis-reading of the text
which is pretty clear that pervasive monitoring is to be addressed
in the same way as any other vulnerability.
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.
Eh... not sending PII when its not needed in a protocol? I
believe I answered that last month. [1] What's not clear
about that answer?
[1] http://www.ietf.org/mail-archive/web/ietf/current/msg84918.html
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.
That is not an accurate description of the text. You are
radically mis-interpreting what it says. There is nothing
in the draft that moves anything to front of any 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
Saying that this BCP would eliminate MPLS approaches being
purely FUD.
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).
"Primary objective" bears no resemblance to the draft at all.
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.
The above does not quote any text and IMO hugely mis-states
what is in the draft. I have no clue how you could interpret
the text as you claim to have above.
S
best regards and best wishes for the new year,
john