Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 11 August 2015 01:14 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE871A87DE for <saag@ietfa.amsl.com>; Mon, 10 Aug 2015 18:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rit3SqedPPfo for <saag@ietfa.amsl.com>; Mon, 10 Aug 2015 18:14:56 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 84E351A87DB for <saag@ietf.org>; Mon, 10 Aug 2015 18:14:56 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 50EC6F984; Mon, 10 Aug 2015 21:14:54 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id F2021200EB; Tue, 11 Aug 2015 03:14:44 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Joe Touch <touch@isi.edu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu>
References: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> <55C8EBAE.4070704@cs.tcd.ie> <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Mon, 10 Aug 2015 21:14:42 -0400
Message-ID: <87d1yur5h9.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/pAMQVFQcykApU64sRTsx08kV0FA>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2015 01:14:58 -0000

On Mon 2015-08-10 16:34:38 -0400, Joe Touch wrote:
> I disagree with this change of status.

Is your disagreement on process grounds or because you disagree with the
analysis or sentiments expressed in RFC 1984?

> Documents that refer to this RFC informationally would all need to be
> considered for potential impact.

I just did a review of all RFCs that refer to RFC 1984 explicitly [0]

-------------

The RFCs are:

 * RFC 2804 ("IETF Policy on Wiretapping")

  [ reference is aggregated in "References" section, no distinction between
    normative/informative ]
    
   https://tools.ietf.org/html/rfc2804#page-2

>>    - The IETF restates its strongly held belief, stated at greater
>>      length in [RFC 1984], that both commercial development of the
>>      Internet and adequate privacy for its users against illegal
>>      intrusion requires the wide availability of strong cryptographic
>>      technology.

 * RFC 4322 ("Opportunistic Encryption using the Internet Key Exchange
   (IKE)")

   [ reference is in the "Informative References" section ]

  https://tools.ietf.org/html/rfc4322#section-1.1

>>    The Internet Architecture Board (IAB) and Internet Engineering
>>    Steering Group (IESG) have taken a strong stand that the Internet
>>    should use powerful encryption to provide security and privacy
>>    [RFC1984].  The Linux FreeS/WAN project attempts to provide a
>>    practical means to implement this policy.

 * RFC 7258 ("Pervasive Monitoring Is an Attack")

   [ reference is in "Informative References" section; there is no
     normative section ]

   https://tools.ietf.org/html/rfc7258#section-3

>>    In the past, architectural statements of this sort, e.g., [RFC1984]
>>    and [RFC2804], have been published as joint products of the Internet
>>    Engineering Steering Group (IESG) and the Internet Architecture Board
>>    (IAB).  However, since those documents were published, the IETF and
>>    IAB have separated their publication "streams" as described in
>>    [RFC4844] and [RFC5741].  This document was initiated after
>>    discussions in both the IESG and IAB, but is published as an IETF-
>>    stream consensus document, in order to ensure that it properly
>>    reflects the consensus of the IETF community as a whole.

-------------

None of these references (and none of these documents) seems to disagree
in any way with RFC 1984, or to be harmed or modified by its
confirmation after 19 years as a BCP.


Given that 2670 of the 7460 published RFCs have some mention of
cryptgraphy [1], and that at every month since the start of 2000 (i
haven't looked earlier) we've published RFCs mentioning cryptography, it
seems clear that encrypted communications is still something that we
believe in as a community, and are continuing to rely on.

I see no reason to revise our recommendation that we "would like to
encourage policies that allow ready access to uniform strong
cryptographic technology for all Internet users in all countries."

           --dkg

[0]
$ egrep -il 'rfc.?1984' rfc*.html 
rfc1984.html
rfc2804.html
rfc4322.html
rfc7258.html
$ 

[1] 
$ egrep -il '(en|de)crypt|crypt(o|ed|-hash|-pw|analy(sis|ze))' rfc*.html | wc -l
2670
$ ls rfc*.html | wc -l
7460
$