Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

[Tim Bray <tbray@xxxxxxxxxxxxxx>]

On Wed, Jan 1, 2014 at 4:08 AM, Eliot Lear <lear@xxxxxxx> 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.wood@xxxxxxxxxxxx" <l.wood@xxxxxxxxxxxx> 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@xxxxxxxx] On Behalf Of Melinda Shore [melinda.shore@xxxxxxxxx]

Sent: 01 January 2014 05:38

To: ietf@xxxxxxxx

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