RE: Security for various IETF services

ned+ietf@mauve.mrochek.com Thu, 03 April 2014 23:48 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 26B8E1A03AA for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 16:48:29 -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 vhURAjUSmOOr for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 16:48:24 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 72B981A0210 for <ietf@ietf.org>; Thu, 3 Apr 2014 16:48:24 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P67T1Z25A80052KU@mauve.mrochek.com> for ietf@ietf.org; Thu, 3 Apr 2014 16:43:20 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="iso-8859-1"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P5NOFJJ0Y800004W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Thu, 3 Apr 2014 16:43:15 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01P67T1X0MI000004W@mauve.mrochek.com>
Date: Thu, 03 Apr 2014 16:35:41 -0700
Subject: RE: Security for various IETF services
In-reply-to: "Your message dated Thu, 03 Apr 2014 16:24:29 -0700" <p06240601cf639cb2113b@[99.111.97.136]>
References: <533D8A90.60309@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E779EEB6@EXMB01CMS.surrey.ac.uk> <p06240601cf639cb2113b@[99.111.97.136]>
To: Randall Gellens <randy@qti.qualcomm.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/rxR2a7TAtS_lVkdoDLl57RxlKqk
Cc: 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: Thu, 03 Apr 2014 23:48:29 -0000

> My reaction is also to ask "Why?"  Security and privacy involve
> trade-offs where various costs (including operational difficulty) are
> weighed against the benefits, such as protecting information from
> unauthorized disclosure or modification.  So, I'd suggest that a
> blanket statement isn't a good idea, but rather, a service-by-service
> decision should be made.  For example, XMPP and document submission
> may justify requiring encryption while email and document retrieval
> might not.

Bingo. There's a perfectly reasonable case to be made for protecting any sort
of authorization/authentication exchange and not allowing alternatives.

But in the case of document distribution, our primary goal should be to insure
maximum availability and access to the information we provide, including
to those who are unable to whatever reason to use protected services.

And yes, I'm aware of the argument that access to certain standards, especially
ones themselves having to do with security, might be problematic to folks
living under some repressive regime or other. I don't buy it, mostly
because that level of paranoia is going to regard any sort of access to
IETF materials whatsoever as a red flag, especially it was conducted over
TLS/SSL.

				Ned