Re: IAB statement on draft-farrell-perpass-attack-00

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 27 November 2013 20:49 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939541AE06C for <ietf@ietfa.amsl.com>; Wed, 27 Nov 2013 12:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-mj7STF4c6v for <ietf@ietfa.amsl.com>; Wed, 27 Nov 2013 12:49:32 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0507A1ADFEC for <ietf@ietf.org>; Wed, 27 Nov 2013 12:49:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D8BC9BE60; Wed, 27 Nov 2013 20:49:30 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff4zGMS7Cyby; Wed, 27 Nov 2013 20:49:29 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.45.61.161]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 29212BE58; Wed, 27 Nov 2013 20:49:29 +0000 (GMT)
Message-ID: <52965A8F.9090003@cs.tcd.ie>
Date: Wed, 27 Nov 2013 20:48:15 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: SM <sm@resistor.net>, ietf@ietf.org
Subject: Re: IAB statement on draft-farrell-perpass-attack-00
References: <E2DA1477-C86E-441E-A33D-D47A0D67AFF3@iab.org> <6.2.5.6.2.20131127084710.0dd761c0@resistor.net>
In-Reply-To: <6.2.5.6.2.20131127084710.0dd761c0@resistor.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2013 20:49:35 -0000

Hi SM,

On 11/27/2013 06:56 PM, SM wrote:
> At 08:13 27-11-2013, IAB Chair wrote:
>> At the Vancouver IETF meeting, the IAB held a technical plenary that
>> discussed pervasive monitoring.  The IAB believes that pervasive
>> monitoring represents an attack on the
> 
> The minutes for that plenary is not available at the moment.  I would
> appreciate if the minutes could be published.

See Mary's mail.

>>  Internet in as much as large amounts of information that is intended
>> to be confidential between sets of individuals is in fact gathered and
>> aggregated by third parties.  Such a broad scale attack can undermine
>> confidence in the infrastructure, no matter the intent of those
>> collecting the information.
>>
>> draft-farrell-perpass-attack-00 is intended to establish an IETF
>> community consensus on this matter.  We encourage the community to
>> read and engage in discussion about this draft, and also to take
>> practical measures to limit pervasive monitoring within their
>> environments.
> 
> In Section 1:
> 
>   "that should be mitigated where possible via the design of protocols
>    that make pervasive monitoring significantly more expensive or
>    infeasible"
> 
> That sounds like an arms race [1].

Well, only to the same extent that any cycle of threats emerging
and us figuring out mitigations is an ongoing process, so I don't
see this as being different in that respect, after we've taken the
step to recognise that its an attack that we ought try mitigate.

>   "A fuller problem statement with more examples and description can be
>   found in [ProblemStatement]"
> 
> That document is not available.

Yes. (As stated in the References section.) The idea there is
to start by collating text from the various drafts that people
have already sent to the perpass list. I hope we'll get a draft
of that in the not-too-distant but I'm pretty sure that most
everyone is already familiar with the gist of the problem
here - certainly well enough to express support or not for
this draft when it gets to a last-call.  (And personally I'm
hoping that LC on this one will start in the near future.)

>   "In particular, the term, when used technically, implies nothing about
>    the motivation of the bad-actor mounting the attack, who is still
>    called a bad-actor no matter what one really thinks about their
>    motivation."
> 
> The usual term in the IETF is "adversary" and not "bad-actor".  "bad
> actor" is sometimes defined as "contentious individual".

That term was a bikeshed [2] on the perpass list already  (including
a mail from your good self:-)

I figure s/bad actor/actor/ as suggested by PSA was the best
change. (I've a few other minor changes to make as a result
of discussion on that list as well, hope to get -01 out with
those over the weekend.)

  [2] http://www.ietf.org/mail-archive/web/perpass/current/msg01083.html

> The Security Considerations section that the intended BCP is all about
> privacy.  The Introduction section mentions "illegal purposes by
> criminals".  I would describe the problem as having different angles;
> bad people could capture the information being exchanged and use it for
> nefarious purposes, nation states [2] can capture the information and
> use it to find out what the people are discussing.

I'm not sure if you're suggesting some change there but I think the
point you make above is already made in the (very short) draft in
which case repeating it wouldn't be that useful.

> The draft is well-written.  Given the catchy title 

Thanks:-)

> I am left to wonder
> which parts of the document is polite fiction (a social scenario in
> which all participants are aware of a truth, but pretend to believe in
> some alternative version of events to avoid conflict or embarrassment). 
> In very simplistic terms the draft says:
> 
>   "consensus to design protocols so as to mitigate the attack, where
>    possible."

Yep.

> 
> Quoting  Martin Thomson: we trusted you; we were naive; never again.

Yeah, I like his draft too. I was quite tempted to AD-sponsor partly
to see how it irritates overly-process-oriented folks :-)

Cheers,
S.

> 
> Regards,
> -sm
> 
> 1. the continuing competitive attempt by two or more nations each to
> have available to it more and more powerful weapons than the other(s).
> 
> 2.
> http://ir.elbitsystems.com/phoenix.zhtml?c=61849&p=irol-newsArticle&ID=1810121&highlight=
>