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

Stephen Hanna <shanna@juniper.net> Sat, 02 October 2010 03:04 UTC

Return-Path: <shanna@juniper.net>
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 98C7B3A6C59; Fri, 1 Oct 2010 20:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.153
X-Spam-Level:
X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KT3139eWznD5; Fri, 1 Oct 2010 20:04:18 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id E3DE73A6BBA; Fri, 1 Oct 2010 20:04:15 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTKahYTCggBOgQGB9ff1qt5xtSTt/geye@postini.com; Fri, 01 Oct 2010 20:05:08 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Oct 2010 19:56:26 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 1 Oct 2010 22:56:25 -0400
From: Stephen Hanna <shanna@juniper.net>
To: "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org" <draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org>
Date: Fri, 01 Oct 2010 22:56:24 -0400
Thread-Topic: secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt
Thread-Index: Acth3WZtFoUbk+23ReaFVG39Xm1qzw==
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AE9068781869@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Sat, 02 Oct 2010 03:04:19 -0000

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