Re: Security for various IETF services

"Stewart Bryant (stbryant)" <stbryant@cisco.com> Sat, 05 April 2014 08:50 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 A0C151A03B1; Sat, 5 Apr 2014 01:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 SD7Z_DP6qMzP; Sat, 5 Apr 2014 01:50:28 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4713D1A0085; Sat, 5 Apr 2014 01:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1326; q=dns/txt; s=iport; t=1396687824; x=1397897424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vC24JDfr1NZkcJGOR8pfdWLwwiS+D5w+dA2arDHeW7o=; b=gyh7D1Xd+VwjHvMEerpy3OYLawepcpmiZ7QX7ECvTUTDnGGTsMXuYUGw S0NMA3RL/YBBWFMGSDPpW3aKRFrw+dQKmaYUfLsasWQ+7dOXc4rGNWZLK YyQ6dklliOu193P6DfSu3L+VB66vWTldVaUoDnYzfnf6cqowEm/mHSl6+ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcFAFzDP1OtJV2c/2dsb2JhbABZgwbFIoEZFnSCJQEBAQMBOj8QAgEINhAyJQIEDod2CNAmF44gAQFPB4MkgRQEmFuSP4MwgXI
X-IronPort-AV: E=Sophos;i="4.97,799,1389744000"; d="scan'208";a="315532613"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 05 Apr 2014 08:50:22 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s358oMTZ026012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Apr 2014 08:50:22 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.101]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sat, 5 Apr 2014 03:50:21 -0500
From: "Stewart Bryant (stbryant)" <stbryant@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: Security for various IETF services
Thread-Topic: Security for various IETF services
Thread-Index: AQHPUC2GODnIxqXM80KR8vvcGbq07psCt8zG
Date: Sat, 5 Apr 2014 08:50:21 +0000
Message-ID: <27993A73-491B-4590-9F37-0C0D369B4C6F@cisco.com>
References: <533D8A90.60309@cs.tcd.ie>,<533EEF35.7070901@isdg.net>
In-Reply-To: <533EEF35.7070901@isdg.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/2lglnoiOcqv1gImSRQdHBJehcyk
Cc: IETF-Discussion <ietf@ietf.org>, The IESG <iesg@ietf.org>
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: Sat, 05 Apr 2014 08:50:32 -0000

>> 
>> "The IETF are committed to providing secure and privacy
>> friendly access to information via the web, mail, jabber
>> and other services.

Please confirm that "friendly" implies that the user gets to
choose the degree of security privacy that they consider 
appropriate, and that their applications and devices are not 
encumbered  with the overheads unless they choose to invoke
the privacy and security mechanisms.
 

>> While most (but not all) data on IETF
>> services is public, nonetheless access to that data
>> should use best practices for security and privacy.

I agree, but please can you clarify your interpretation
of "best practise" so that we can understand how
liberal or prescriptive this is?

>> However, as there are numerous legacy tools that have been
>> built that require access via cleartext, the IETF will
>> continue to allow such access so as not to break such
>> tooling. New services will however generally only be made
>> available in ways that use security protocols such as
>> TLS."
>> 

That is worrying, because it seems that you are intent on
encumbering transactions, without requiring a case by 
case study of the threat model, and applying a security
and privacy model that is appropriate to the specific 
transaction.

Stewart.