Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07

Derek Atkins <derek@ihtfp.com> Wed, 23 September 2009 14:25 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE7E3A682E; Wed, 23 Sep 2009 07:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level:
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8JMSjsAB1zR; Wed, 23 Sep 2009 07:25:47 -0700 (PDT)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 95E743A67E7; Wed, 23 Sep 2009 07:25:47 -0700 (PDT)
Received: from pgpdev.ihtfp.org (unknown [69.7.239.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 8DE3F8B4005; Wed, 23 Sep 2009 10:26:52 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n8NEQWjB031346; Wed, 23 Sep 2009 10:26:32 -0400
To: Jerald.P.Martocci@jci.com
References: <OF3BF99F7E.D8461727-ON86257638.0055170A-86257638.0057E142@jci.com>
From: Derek Atkins <derek@ihtfp.com>
Date: Wed, 23 Sep 2009 10:26:32 -0400
In-Reply-To: <OF3BF99F7E.D8461727-ON86257638.0055170A-86257638.0057E142@jci.com> (Jerald P. Martocci's message of "Mon\, 21 Sep 2009 10\:59\:52 -0500")
Message-ID: <sjmbpl17n53.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: secdir@ietf.org, nicolas.riou@fr.schneider-electric.com, pieter.demil@intec.ugent.be, iesg@ietf.org, roll-chairs@tools.ietf.org, wouter@vooruit.be, Adrian Farrel <Adrian.Farrel@huawei.com>
Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2009 14:25:48 -0000

Hi,

First, I do think you need to change the structure and re-introduce the
"Security Considerations" section.

Second, I think it's important (even in a requirements document) to
explain the ramifications of different security tradeoffs.

I agree that you don't need to specify "Use AES-256 in GCM mode" in this
document.  However I do think you need to go into more detail about the
various security services that your protocols will need to define, and
the trade-offs that might happen if they choose to define it one way
versus another.  In other words, what are the security requirements for
your sub-protocols?

I don't think the current draft goes into quite enough detail in
answering these questions.  I think the questions I posed below still
apply, even in a requirements document.  Providing guidance to protocol
designers is still appropriate.

-derek

Jerald.P.Martocci@jci.com writes:

> Hi Derek,
>
> As the author of the document, I am trying to describe in this requirements ID
> the flexibility of setting up the security policies (as Adrian notes) rather
> then the application specifics of picking a security policy for a given
> application.  Earlier versions of this ID included this information, but was
> dropped since it was out of scope for the routing protocol.  
>
> I have recently been requested to draft an ID for the 6LowAPP that would deal
> specifically with Building Applications at the application layer rather than
> at the routing layer.  Here, I intend to reinject into this new ID specificity
> as to when different security strategies are required.  I have attached a
> spreadsheet that describes 5 different security policies (rows) that must be
> configurable for many different types of commercial buildings with the varying
> requirements for each building type (columns).  I intend to redraft this
> spreadsheet into a section of the ID.  
>
> I hope this is more of what you're looking for and can accept that I will put
> is into a separate ID.  If you think any of this should be put into the
> existing requirements ID, let me know and I will add it in.
>
> Best Regards,
>
> Jerry Martocci
>
> Adrian Farrel                       To Derek Atkins <derek@ihtfp.com>;,         
> <Adrian.Farrel@huawei.com>;             iesg@ietf.org, secdir@ietf.org          
>                                     cc pieter.demil@intec.ugent.be,            
> 09/20/2009 05:00 AM                    nicolas.riou@fr.schneider-electric.com, 
> ┌────────────────────────────┐         jerald.p.martocci@jci.com,              
> │     Please respond to      │         wouter@vooruit.be,                      
> │       Adrian Farrel        │         roll-chairs@tools.ietf.org              
> │ <Adrian.Farrel@huawei.com>; │ Subject Re: sec-dir review of                   
> └────────────────────────────┘         draft-ietf-roll-building-routing-reqs-07
>
> Hi Derek,
>
> I very much appreciate your review.
>
> It is important to understand that this document specifies requirements that
> must/should/etc be satisfied by a protocol designed by the working group.
> Thus, there is no question of what should be deployed or what should be
> implemented.
>
> That is, the document specifies what must be in the protocol spec. We can
> expect the protocol spec to discuss what must be implemented. And either the
> protocol spec or an applicability statement would describe what must be
> deployed.
>
> So, the concerns you raise would be very important in the final protocol
> spec (and I hope the chairs and authors are paying attention), but do not
> seem to me to fit in this document.
>
> Thanks,
> Adrian
>
>>> The Security Considerations appear to take into account various
>>> requirements for different systems.  What seems to be lacking is
>>> direction about how or when to apply various requirements and what
>>> it means to the deployment.
>>>
>>> For example, what would it mean to a deployment if it has
>>> authentication versus not having authentication?  Also, it's unclear
>>> how these requirements would apply to an implementor.
>>>
>>> Variable security policies is a good idea, but it requires more
>>> guidance because the end user will never understand the ramifications
>>> of choosing one policy over another.
>
>

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant