Re: Security for various IETF services

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 04 April 2014 00:26 UTC

Return-Path: <brian.e.carpenter@gmail.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 1807A1A0025 for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 17:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ZhVeMe1KZZKv for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 17:26:52 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6101A03F5 for <ietf@ietf.org>; Thu, 3 Apr 2014 17:26:52 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id fp1so2521413pdb.14 for <ietf@ietf.org>; Thu, 03 Apr 2014 17:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5cQj37wLWknYQ5kYhuTrLKMtbLl/E0s0txdLCUjexf0=; b=XNKASzvkjkDoT1BrjUWhizEd91zPwAy77yTkVrv4BB8Dd54v85r6L+rLzlDunt07OJ 7mjtqoAMwO+hS2PsRtcYGfG6euk0bpJWa0O9JjIW1fZuKTl+pj1S7Drc8vSwudjonzjp 7AzWchVmt4FAVM9CyGqpVkzlkWkIMNJAS9tQe+CnenN0JkgWBM9VIOVLgPXff/EXZgoF xUQq9W0kvyVcQLws+Fax2otXSvd28IQDZpKTaKVXIUjjCzGP3Izel8AV7JnWC+y5hQir u1dYzvps/lxiefiWkTb3CO6oWIqjtuzqtADGnjdYxgmioU4jA3GbSBoYDmbg7MRFSYyN xjYw==
X-Received: by 10.68.160.163 with SMTP id xl3mr11191295pbb.39.1396571208239; Thu, 03 Apr 2014 17:26:48 -0700 (PDT)
Received: from [192.168.178.23] (203.202.69.111.dynamic.snap.net.nz. [111.69.202.203]) by mx.google.com with ESMTPSA id xk1sm31927475pac.21.2014.04.03.17.26.46 for <ietf@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 17:26:47 -0700 (PDT)
Message-ID: <533DFC4F.2040902@gmail.com>
Date: Fri, 04 Apr 2014 13:26:55 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Security for various IETF services
References: <533D8A90.60309@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E779EEB6@EXMB01CMS.surrey.ac.uk> <p06240601cf639cb2113b@[99.111.97.136]> <01P67T1X0MI000004W@mauve.mrochek.com>
In-Reply-To: <01P67T1X0MI000004W@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/dK0n_3ik1q-xSaz7BLwn8oXWEUA
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: Fri, 04 Apr 2014 00:26:57 -0000

On 04/04/2014 12:35, ned+ietf@mauve.mrochek.com wrote:
>> 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.

That may be, but that doesn't mean we shouldn't offer privacy of
access to those who want it. I think we need to distinguish various
quite separate issues. Off the top of my head, I can see:

* authenticity and integrity of data coming from the IETF site;
* privacy of the fact of access, if the user wants it;
* preventing access to the IETF site being used as an attack
  vector for either the site itself or the remote user
  (which indirectly includes protecting the privacy of
  personal information held at either end);