Re: [secdir] secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt

Russ Housley <housley@vigilsec.com> Mon, 04 October 2010 19:16 UTC

Return-Path: <housley@vigilsec.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 BA7C23A6E38; Mon, 4 Oct 2010 12:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 4JcvnnssxnZn; Mon, 4 Oct 2010 12:16:16 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 080633A6C09; Mon, 4 Oct 2010 12:16:16 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 0D58CF2404D; Mon, 4 Oct 2010 15:17:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id yE2gOOq069no; Mon, 4 Oct 2010 15:17:02 -0400 (EDT)
Received: from [192.168.1.3] (pool-96-231-149-87.washdc.fios.verizon.net [96.231.149.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 40030F2403D; Mon, 4 Oct 2010 15:17:15 -0400 (EDT)
Message-ID: <4CAA283F.7010708@vigilsec.com>
Date: Mon, 04 Oct 2010 15:17:19 -0400
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Stephen Hanna <shanna@juniper.net>
References: <AC6674AB7BC78549BB231821ABF7A9AE9068781869@EMBX01-WF.jnpr.net>
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AE9068781869@EMBX01-WF.jnpr.net>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org" <draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt
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: Mon, 04 Oct 2010 19:16:21 -0000

I entered a DISCUSS balot position on this document.  I said:

>   The direction suggested by this document will undermine the privacy
>   features associated with host-generated CGAs.  In general, CGAs are
>   not used in the same environment as a DHCP server, and I do not see
>   a justification for this to change.
>
>   Without providing a reason, this document asserts that local a
>   administrator ought to manage CGA generation parameters.  I am
>   guessing that the concern is the computation burden, but this is not
>   compelling.  Further, RFC 3315 already allows a DHCPv6 server to
>   reject a CGA generated with unacceptable parameters.
>
>   This document discusses the use of DHCPv6 to assign certificates to
>   CGA address owners.  CGA 'ownership' can already be validated with
>   the private key, so the need for a certificate is unclear.
>
>   This document states: "... the generation of the Modifier field of a
>   CGA address is computationally intensive."  RFC 3972 seems indicate
>   otherwise for most key sizes.  In general, RSA key pair generation is
>   not a big concern on modern processors.  It might be a mild concern
>   on mobile devices, but some detailed explanation is required.

My biggest concern is raised in the first paragraph.  I think we need a
compelling reason to erode the privacy properties of CGAs, and I did not
find such a reason in the document.

Russ


On 10/1/2010 10:56 PM, Stephen Hanna wrote:
> I have reviewed this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG. These comments were written primarily for the benefit of the  
> security area directors. Document editors and WG chairs should treat  
> these comments just like any other last call comments.
> 
> This document discusses several ways that DHCPv6 can be used with
> Cryptographically Generated Addresses (CGA), pointing out benefits
> and concerns. While the document does discuss security issues in
> several places, it often lapses into vague terminology like "one
> should carefully consider the impact on security". Given that the
> primary benefit of using CGAs is to improve security by providing
> address validation without complex key distribution, carefully
> analyzing security issues seems necessary for this document.
> 
> On the other hand, the Document Shepherd Write-up for this document
> says "The WG was not very energetic on this document. The document
> describes possible applications of CGAs and DHCP interaction and
> when the WG was asked whether there was enough interest to work on
> solutions, the reply was silence. As such, the consensus is based
> on most of the WG being indifferent." So maybe this document is
> only intended as a sketch of possible issues that can be explored
> later in a more in-depth document if someone is interested in
> doing so. If that's the case, maybe it's OK to not fully analyze
> all the security implications. However, in that case, I think the
> Security Considerations section should state clearly that this
> document does not contain a complete security analysis and any
> further work in this area should include such an analysis. Nobody
> should implement the techniques described in this document without
> conducting that more thorough analysis.
> 
> I noticed a few typos. On page 6, the word "certificated" should be
> "certified". Three sentences later, "depend on policies" should be
> "depending on policies". And the draft names in the Change Log say
> "dhacpv6" instead of "dhcpv6".
> 
> Thanks,
> 
> Steve