Re: Security for various IETF services

Stewart Bryant <stbryant@cisco.com> Mon, 07 April 2014 10:21 UTC

Return-Path: <stbryant@cisco.com>
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 600D01A06E4 for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 03:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.511
X-Spam-Level:
X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 FjdgIHYeyKK4 for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 03:21:06 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 489D61A018D for <ietf@ietf.org>; Mon, 7 Apr 2014 03:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=939; q=dns/txt; s=iport; t=1396866061; x=1398075661; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=R2dHIyqPzd1y8Z5dFS/9SyqdulHBdTxOItQI7fu/5qQ=; b=fFiGdqZBK/KTNxTUWGApcSLaLPKUFSIjT12AnHjVSBVM3VqwXNFBLy0Z r9YzxGVqsT7ztHtu9WUel+bc/MFutm4v9Rz7uSPI9w7OTuYVZLlDZLzBG LuMsU/BKIZNlifUSjRSIoiWPAanljTCHXJnQQwZPXfkqrwcljq/wOwnV4 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAGV7QlOQ/khL/2dsb2JhbABZgwbCHoMOgSIWdIIlAQEBAwE4QAYLCxgJFg8JAwIBAgFFBgEMCAEBh20Irm+cPBeOGV+EOAEDmFuSP4MxgWg
X-IronPort-AV: E=Sophos;i="4.97,809,1389744000"; d="scan'208";a="9749311"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-3.cisco.com with ESMTP; 07 Apr 2014 10:21:00 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s37AKxo4012395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 10:21:00 GMT
Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s37AKwRj000543; Mon, 7 Apr 2014 11:20:58 +0100 (BST)
Message-ID: <53427C0A.6050305@cisco.com>
Date: Mon, 07 Apr 2014 11:20:58 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Christian Huitema <huitema@microsoft.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Security for various IETF services
References: <533D8A90.60309@cs.tcd.ie> <53417832.90405@cs.tcd.ie> <alpine.LRH.2.01.1404061602580.14892@egate.xpasc.com> <ecabb0a4080548d99ab083c0ff0c27ee@BLUPR03MB424.namprd03.prod.outlook.com>
In-Reply-To: <ecabb0a4080548d99ab083c0ff0c27ee@BLUPR03MB424.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/P-QaFFiTY70kxKSJKUASo4agl54
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
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: Mon, 07 Apr 2014 10:21:11 -0000

On 07/04/2014 00:30, Christian Huitema wrote:
>> I agree with those who've said a threat analysis is needed before
>> deciding access is limited to TLS or other secure alternative.
> But we have that threat analysis, and the recommended mitigation is precisely "encrypt everything." The "pervasive monitoring" threat is analyzed by a number of perpass drafts, and Stephen has merely followed the conclusions of that analysis. There is no need to repeat that analysis for each and every tool that the IETF produces,
A (justified) reference to a base RFC is surely allowed, and the degree 
of commonality will surely determine whether it passes on the nod, or 
the covers get taken off for a closer investigation.

> and there is indeed a need for the IETF as a whole to "lead by example."
I am concerned that statement makes too broad an assumption about what 
an application is let alone what a threat mitigation is.

Stewart