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

[Russ Housley <[e-mail]>]

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