Last call debate on draft-farrell-perpass-attack

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 07 January 2014 16:13 UTC

Return-Path: <adrian@olddog.co.uk>
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 729651ADF9B for <ietf@ietfa.amsl.com>; Tue, 7 Jan 2014 08:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.847
X-Spam-Level:
X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 QXp3MxAF2vFw for <ietf@ietfa.amsl.com>; Tue, 7 Jan 2014 08:13:55 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 973F81ADF98 for <ietf@ietf.org>; Tue, 7 Jan 2014 08:13:55 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07GDjZJ029510 for <ietf@ietf.org>; Tue, 7 Jan 2014 16:13:45 GMT
Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07GDhPW029500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ietf@ietf.org>; Tue, 7 Jan 2014 16:13:45 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: ietf@ietf.org
Subject: Last call debate on draft-farrell-perpass-attack
Date: Tue, 07 Jan 2014 16:13:46 -0000
Message-ID: <015901cf0bc3$72bb75d0$58326170$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8Lw2szjkgNuRQwSuKh07AWp1OQiw==
Content-Language: en-gb
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Tue, 07 Jan 2014 16:13:57 -0000

Hi,

I want to weigh in supporting the publication of this document.

I was a document author and then WG chair in CCAMP at a time when it was
exceeding hard to get a GMPLS RFC published because the security considerations
for GMPLS "were not properly documented". I can confess that I became very
disillusioned with the IETF process and with the serving Security ADs at the
time. It took a lot of discussion for me to be convinced that the ADs were doing
what they genuinely thought was best for the Internet (even though they were
wrong ;-)

But it was not the existence of any document describing security consideration
sections that enabled the ADs to block publication. Nor was it some wrinkle in
the process. It was the right and proper process that enables ADs to worry about
the impact on the stability (which includes security) of the Internet when
looking at publication requests. Furthermore, it was not the process per se that
was at fault, it was the enthusiasm of the ADs, and *that* was perfectly
possible to handle using the existing processes (although it was a steep
learning curve for me) and normal discussions about which we should never be
defensive or paranoid.

So, why do I rake up the past now?

This document in its current form does not, IMHO, represent a tool that can be
used by any AD to block or cause delay to the publication of any RFC. If
anything, it provides assistance to authors to enable them to think about some
new yet key issues and include the right discussions in their documents. The
document goes nowhere near as far as RFC 5706 in "dictating" what has to be
documented in a protocol spec yet I don't recall any fuss about that document.
Far from it: this document simply describes the landscape, explains how privacy
attacks may be happening, and indicates that the authors think that such attacks
should be considered in the design of protocols.

And there is a get-out-of-jail-free card that I would find perfectly acceptable:

   This does not mean a new "pervasive monitoring
   considerations" section is needed in IETF documentation.  It means
   that, if asked, there needs to be a good answer to the question "is
   pervasive monitoring relevant to this work and if so how has it been
   addressed?"

Note that that discussion can be in the shepherd write-up, on the mailing list,
in a conversation with the Sec AD during evaluation or (and only if the
authors/WG want to) in the I-D.

I do not find the discussions of opinions voiced against this I-D to be
convincing, and I support its publication.

Thanks,
Adrian