Re: [perpass] "Its an attack" BCP draft

Rob Stradling <rob.stradling@comodo.com> Wed, 20 November 2013 23:05 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14D21AE16D for <perpass@ietfa.amsl.com>; Wed, 20 Nov 2013 15:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 9DQvGsjhQnHb for <perpass@ietfa.amsl.com>; Wed, 20 Nov 2013 15:05:29 -0800 (PST)
Received: from mmmail2.mcr.colo.comodoca.net (mmmail.mcr.colo.comodoca.net [91.209.196.71]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B71AE165 for <perpass@ietf.org>; Wed, 20 Nov 2013 15:05:28 -0800 (PST)
Received: (qmail 26901 invoked from network); 20 Nov 2013 23:05:20 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 20 Nov 2013 23:05:20 -0000
Received: (qmail 29700 invoked by uid 1000); 20 Nov 2013 23:05:20 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 20 Nov 2013 23:05:20 +0000
Message-ID: <528D402F.9040407@comodo.com>
Date: Wed, 20 Nov 2013 23:05:19 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: joel jaeggli <joelja@bogus.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <528D34D7.1010303@cs.tcd.ie> <528D3A85.5090003@gmail.com> <528D3B28.8020406@cs.tcd.ie> <528D3DA6.1030505@bogus.com>
In-Reply-To: <528D3DA6.1030505@bogus.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 20 Nov 2013 15:07:13 -0800
Cc: perpass <perpass@ietf.org>
Subject: Re: [perpass] "Its an attack" BCP draft
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2013 23:05:34 -0000

On 20/11/13 22:54, joel jaeggli wrote:
> a surveillor and a surveyor are rather different things.

s/surveillor/surveillant/  ?

>> S.
>>
>>>
>>> Regards
>>>     Brian
>>>
>>> On 21/11/2013 11:16, Stephen Farrell wrote:
>>>> Hi all,
>>>>
>>>> Following up on item 3a from the status/plan mail [1] I sent
>>>> last week, Hannes and myself have written up an I-D [2] that
>>>> tries to capture the consensus in the room from the Vancouver
>>>> tech plenary and we're proposing as a BCP.
>>>>
>>>> We're deliberately trying to keep this short and sweet and to
>>>> not (yet) go beyond what was the gist of the hums - we think
>>>> progressing e.g. the threat model or the privacy BCP or other
>>>> bits of related work is liable to take longer and there's value
>>>> in documenting that the IETF as a whole has consensus on the
>>>> most significant bit first so those and other bits of work
>>>> don't all have to re-establish that as they are processed.
>>>> Hopefully we can all easily agree that that's a useful target
>>>> and focus comments on whether on not we've expressed that
>>>> consensus well or not.
>>>>
>>>> <boring-bit>
>>>> We've been bouncing versions of this around amongst the IESG
>>>> and IAB for the last week, and process-wise, that has been
>>>> fun already. As you'll see from section 3 of the draft, we can
>>>> no longer just shoot out an RFC agreed by the IESG and IAB so
>>>> the plan for this is that when Hannes and I figure this looks
>>>> ready, based on your comments, then we'll ask Jari to start a
>>>> 4-week IETF LC for it. When he thinks that's ok he'll start it
>>>> and then we'll see how that goes. Assuming that goes well, then
>>>> sometime during IESG evaluation the IAB will decide if they
>>>> like the final text (or not, which'd be "interesting") and if
>>>> they do then an IAB note saying "yep, we like it" will be added
>>>> sometime during/after IESG evaluation before this goes to the
>>>> RFC editor. In an ideal world, you'll all love the -00 already
>>>> and tell us that and we'll be done with all of the above super
>>>> duper process stuff by the end of the year. (Haven't we built
>>>> ourselves a lovely crazy process? ;-)
>>>>
>>>> I really hope we don't end up with a process debate over this,
>>>> since the above, silly and all as it is, should achieve the
>>>> desirable outcome which is a simple BCP, approved by the IESG
>>>> after an IETF LC and also supported by the IAB. The value in
>>>> that is that it seems to be as close as we can get to the same
>>>> setup as RFCs 1984 and 2804 which is the right kind of heritage
>>>> for this one. So there is a reasonably good reason for the
>>>> process-crap.
>>>> </boring-bit>
>>>>
>>>> Anyway, ignoring process, comments on this are welcome, so
>>>> please take a read of the two pages of content and let us know
>>>> what you think. If you do think its already good enough for
>>>> starting an IETF last call, then saying that is useful as well.
>>>>
>>>> And since the IETF LC will happen on the ietf@ietf.org list,
>>>> using this list for initial processing should be fine.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html
>>>> [2] http://tools.ietf.org/html/draft-farrell-perpass-attack
>>>> _______________________________________________
>>>> perpass mailing list
>>>> perpass@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/perpass
>>>>
>>> _______________________________________________
>>> perpass mailing list
>>> perpass@ietf.org
>>> https://www.ietf.org/mailman/listinfo/perpass
>>>
>>>
>> _______________________________________________
>> perpass mailing list
>> perpass@ietf.org
>> https://www.ietf.org/mailman/listinfo/perpass
>>
>
>
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.