Re: Security for various IETF services

ned+ietf@mauve.mrochek.com Sat, 05 April 2014 17:25 UTC

Return-Path: <ned+ietf@mauve.mrochek.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 077541A0491 for <ietf@ietfa.amsl.com>; Sat, 5 Apr 2014 10:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YqZykCJIyFAs for <ietf@ietfa.amsl.com>; Sat, 5 Apr 2014 10:25:23 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A58741A02FC for <ietf@ietf.org>; Sat, 5 Apr 2014 10:25:23 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P6A89R7I5C00513E@mauve.mrochek.com> for ietf@ietf.org; Sat, 5 Apr 2014 10:20:18 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P6A66V86WW00004W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Sat, 5 Apr 2014 10:20:13 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01P6A89PP18Q00004W@mauve.mrochek.com>
Date: Sat, 05 Apr 2014 10:19:30 -0700 (PDT)
Subject: Re: Security for various IETF services
In-reply-to: "Your message dated Sat, 05 Apr 2014 08:50:21 +0000" <27993A73-491B-4590-9F37-0C0D369B4C6F@cisco.com>
References: <533D8A90.60309@cs.tcd.ie> <533EEF35.7070901@isdg.net> <27993A73-491B-4590-9F37-0C0D369B4C6F@cisco.com>
To: "Stewart Bryant (stbryant)" <stbryant@cisco.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/5npq6ciaBRmdjTVC6dwuzyyq34Y
Cc: The IESG <iesg@ietf.org>, IETF-Discussion <ietf@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 17:25:31 -0000

Agreed on all points. This is rapidly turning into the IETF's own version
of "if we can, we must" thinking.

				Ned

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