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

>>=20
>> "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=20
appropriate, and that their applications and devices are not=20
encumbered  with the overheads unless they choose to invoke
the privacy and security mechanisms.
=20

>> 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."
>>=20

That is worrying, because it seems that you are intent on
encumbering transactions, without requiring a case by=20
case study of the threat model, and applying a security
and privacy model that is appropriate to the specific=20
transaction.

Stewart.

