Re: Security for various IETF services

John C Klensin <john@jck.com> Fri, 04 April 2014 13:25 UTC

Return-Path: <john@jck.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 6D4CA1A0182 for <ietf@ietfa.amsl.com>; Fri, 4 Apr 2014 06:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zdNbdxF4BmMr for <ietf@ietfa.amsl.com>; Fri, 4 Apr 2014 06:25:42 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 24C321A017C for <ietf@ietf.org>; Fri, 4 Apr 2014 06:25:42 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1WW47k-000DGu-1J; Fri, 04 Apr 2014 09:25:36 -0400
Date: Fri, 04 Apr 2014 09:25:30 -0400
From: John C Klensin <john@jck.com>
To: ned+ietf@mauve.mrochek.com, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Security for various IETF services
Message-ID: <FEACD58B167F6AA60980844A@JcK-HP8200.jck.com>
In-Reply-To: <01P67VFG3GTG00004W@mauve.mrochek.com>
References: <533D8A90.60309@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E779EEB6@EXMB01CMS.surrey.ac.uk> <p06240601cf639cb2113b@[99.111.97.136]> <01P67T1X0MI000004W@mauve.mrochek.com> <533DFC4F.2040902@gmail.com> <01P67VFG3GTG00004W@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/z4DsWculJCTlY8t6TxlzVn_UFJI
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: Fri, 04 Apr 2014 13:25:46 -0000

--On Thursday, April 03, 2014 17:44 -0700
ned+ietf@mauve.mrochek.com wrote:

>...
>> * authenticity and integrity of data coming from the IETF
>> site;
> 
> Your problem here is people get IETF data from many sources
> besides the IETF site. Indeed, alternative data stores may
> provide access alternatives for those concerned about being
> seen accessing IETF data in the obvious way.
> 
> As a result I don't see how transport security offers a
> meaningful solution here. We should instead be looking at
> various signature mechanisms.

Concur.  

If we think there is a real threat and problem that needs to be
solved in this area, we should see documents signed at the time
of posting and those signatures either made part of them or made
readily, easily, and obviously accessible along with any tools
needed to apply them.  We should also be sure that careful
questions are asked the relationship between signatures (or
other integrity-assurance) methods and the current IPR policies
allowing duplicates (should we require that the signatures be
preserved or explicit pointers to the authoritative, signed,
copies be provided?) and the RFC Editor's plans about multiple
output formats (e.g., is an integrity check over the XML file
adequate if there is no guarantee the that file recipient can
generate the user-accessible version?) and that answers
evaluated by experts.  Those are mostly technical issues --the
stuff we supposedly do well-- and need not be carried out on
this list, just competently reported to it.

More generally, I think the conclusion from Brian's remarks and
those of several others is that what is really needed here is a
serious analysis of what threats actually exist and whether we
care about them.   In the absence of a clear statement and
understanding of a problem and explanation of how a particular
technique will significantly mitigate it, these "we have a
technique, should we apply it" questions are, IMO, fairly
meaningless and a very bad example of the kind of engineering
the IETF should be advocating and demonstrating.

Back to trying to get substantive work done.
 
   john