On Wed, Jan 1, 2014 at 4:08 AM, Eliot Lear <lear(_at_)lear(_dot_)ch> wrote:
If, on the other hand, developers of a specification discussed the matter
in earnest and there was consensus on the way forward, even if some
pervasive threats were not eliminated, and if that work is held up by
claims relating to this draft, then this draft will have caused harm.
This paragraph seems ridiculous to me. The perpass-attack draft says that
pervasive monitoring has the characteristics of an attack, and that the
protocols we design SHOULD include appropriate mitigation measures. I quote
from the draft:
"Mitigation" is a technical term that does not imply an ability to
completely prevent or thwart an attack.
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.
That is nothing more or less than common sense.
As to whether this draft is political, it cannot be stressed enough that
if one group of people can subvert our architecture, others can as well.
Our political statement, such as it is, is that in order to maintain
confidence in the Internet, our protocol suite should be resistant to this
sort of thing, but within the bounds of pragmatism.
Eliot
On Jan 1, 2014, at 6:08 AM, "l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk"
<l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk>
wrote:
what it means for work moving through the IETF process
is that any work becomes subject to security veto.
if security types don't like your work - tough. it's
going nowhere. draft-farrell really widens that scope.
and this is going to mean arguments about
much more than the tradeoffs of using MD5.
for a self-described technical organisation that
does not make policy pronouncements (which is
itself a very political position, but never mind)
this draft is awfully political.
Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Melinda Shore [
melinda(_dot_)shore(_at_)gmail(_dot_)com]
Sent: 01 January 2014 05:38
To: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive
Monitoring is an Attack) to Best Current Practice
On 12/31/13 3:23 PM, Dave Crocker wrote:
We should not approve an IETF policy statement
until we have a good idea of the way we will use it.
I think this is a critical point and I agree quite strongly
with it. I've mostly been baffled by the IETF response to
revelations about internet eavesdropping, to be honest,
and it's struck me that work on some of the problems that
need to be solved to provide better privacy guarantees (for
example, fixing PKI and providing better keying) have been
pushed to a back burner in a scramble to make grandiose
pronouncements. It's not that draft-farrell is a bad
document on its own merits, it's just that I cannot for
the life of me understand what it specifically means for
work moving through the IETF process.
Melinda