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

Russ Housley <> Mon, 04 October 2010 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA7C23A6E38; Mon, 4 Oct 2010 12:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4JcvnnssxnZn; Mon, 4 Oct 2010 12:16:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 080633A6C09; Mon, 4 Oct 2010 12:16:16 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 0D58CF2404D; Mon, 4 Oct 2010 15:17:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yE2gOOq069no; Mon, 4 Oct 2010 15:17:02 -0400 (EDT)
Received: from [] ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 40030F2403D; Mon, 4 Oct 2010 15:17:15 -0400 (EDT)
Message-ID: <>
Date: Mon, 04 Oct 2010 15:17:19 -0400
From: Russ Housley <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Stephen Hanna <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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