Re: Security for various IETF services

Dave Crocker <dhc@dcrocker.net> Fri, 04 April 2014 02:04 UTC

Return-Path: <dhc@dcrocker.net>
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 DAE2D1A0056 for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 19:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 79zVfJulMod4 for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 19:04:34 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 733A41A0055 for <ietf@ietf.org>; Thu, 3 Apr 2014 19:04:34 -0700 (PDT)
Received: from [192.168.2.36] (adsl-108-81-170-124.dsl.pltn13.sbcglobal.net [108.81.170.124]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s3424Pcl025825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Apr 2014 19:04:28 -0700
Message-ID: <533E12BF.9080308@dcrocker.net>
Date: Thu, 03 Apr 2014 19:02:39 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 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> <533DFC4F.2040902@gmail.com>
In-Reply-To: <533DFC4F.2040902@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 03 Apr 2014 19:04:29 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Bk---N09xeD1xmW05YJnvrhPkhY
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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 02:04:39 -0000

On 4/3/2014 5:26 PM, Brian E Carpenter wrote:
> I think we need to distinguish various
> quite separate issues. Off the top of my head, I can see:

What I like most about Brian's list is that it seeks to gain some 
discipline an clarity about what might be done and why.  As Ned's 
responses shows, this requires even more clarity and -- depending on 
what answers we give -- different difficulty.



On 4/3/2014 5:29 PM, Randy Bush wrote:
 > because we blew it way back when, by designing a completely insecure
 > and un-private internet.  as supposedly responsible and occasionally
 > competent engineers, we should rectify our mistakes.

This promotes a collection of popular myths which both give a false 
history and a false (and counter-productively distracting) present.

The presumption that 'security' was ignored "way back" is simply wrong. 
  Both in the 70s and again in the 90s, security issues were given 
attention.  In the 70s, the primary answer was encryption boxes, for 
those special cases deem to need them.  In terms of the technology of 
the day, when combined with the nature of the scale and use of the 
Arpanet and eventually Internet, that was a reasonable choice.

In the 90s, we got PEM, PGP, S/MIME and the beginnings of DNSSec.

The experience of the 90s nicely highlights the problem with the second 
myth, that we merely needed to 'decide' to do 'security'.  As the 
increasing list of problematic security-related efforts over the last 25 
years demonstrate, doing 'security' for Internet scale and diversity is 
a challenge, often appearing to be beyond the state of the art.

Note how little DNSSec we still have.  Note how little PGP and S/MIME 
use we still have.  All three of those were diligent, reasonable design 
efforts.  Yet their deployment and use remains problematic.

Added to this is that the word 'security' is almost completely 
meaningless in technical terms.  For most technical discussions, it's so 
vague there's no way to know what specific problems are of concern or 
what functions are intended.

So please, let's focus on the kind of disciplined, targeted effort that 
Brian is promoting to consider needs and solutions, and move away from 
mythology.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net