RE: Security for various IETF services

<l.wood@surrey.ac.uk> Sat, 05 April 2014 09:39 UTC

Return-Path: <l.wood@surrey.ac.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 BDF351A03DA; Sat, 5 Apr 2014 02:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 68AULPUE7PYA; Sat, 5 Apr 2014 02:38:59 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77A1A03D8; Sat, 5 Apr 2014 02:38:59 -0700 (PDT)
Received: from [195.245.230.131:5848] by server-2.bemta-3.messagelabs.com id 15/C9-23530-D2FCF335; Sat, 05 Apr 2014 09:38:53 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-14.tower-78.messagelabs.com!1396690732!23839049!1
X-Originating-IP: [131.227.200.35]
X-StarScan-Received:
X-StarScan-Version: 6.11.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20076 invoked from network); 5 Apr 2014 09:38:52 -0000
Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 5 Apr 2014 09:38:52 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.150]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sat, 5 Apr 2014 10:38:52 +0100
From: <l.wood@surrey.ac.uk>
To: <stbryant@cisco.com>, <stephen.farrell@cs.tcd.ie>
Date: Sat, 5 Apr 2014 10:38:51 +0100
Subject: RE: Security for various IETF services
Thread-Topic: Security for various IETF services
Thread-Index: AQHPUC2GODnIxqXM80KR8vvcGbq07psCt8zGgAALbI0=
Message-ID: <290E20B455C66743BE178C5C84F1240847E779EEBE@EXMB01CMS.surrey.ac.uk>
References: <533D8A90.60309@cs.tcd.ie>, <533EEF35.7070901@isdg.net>, <27993A73-491B-4590-9F37-0C0D369B4C6F@cisco.com>
In-Reply-To: <27993A73-491B-4590-9F37-0C0D369B4C6F@cisco.com>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
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/sPl-wK_WY98l09ICGu-F89t6eRM
Cc: ietf@ietf.org, 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 09:39:04 -0000

"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."

yes. not coincidentally, that's EXACTLY what Stephen
encouraged in DTNRG, starting with MD5-is-ALWAYS-bad
and working up to the-security-model-is-everything. As
opposed to the needs of the networking scenario.

we had the perpass debate, and here we go again.
Well, you've been warned.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant (stbryant) [stbryant@cisco.com]
Sent: 05 April 2014 09:50
To: Stephen Farrell
Cc: IETF-Discussion; The IESG
Subject: Re: Security for various IETF services

>>
>> "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.