[secdir] secdir review of draft-ietf-dhc-dhcpv4-vendor-message

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 05 February 2010 11:26 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 CFDA83A6D68; Fri, 5 Feb 2010 03:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8rWxDt1mSPk2; Fri, 5 Feb 2010 03:26:32 -0800 (PST)
Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 061353A6BDB; Fri, 5 Feb 2010 03:26:31 -0800 (PST)
Received: from mail121-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 8.1.340.0; Fri, 5 Feb 2010 11:27:21 +0000
Received: from mail121-tx2 (localhost [127.0.0.1]) by mail121-tx2-R.bigfish.com (Postfix) with ESMTP id B5F5E4681F6; Fri, 5 Feb 2010 11:27:21 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh6bh87h62h)
X-Spam-TCS-SCL: 1:0
X-FB-DOMAIN-IP-MATCH: fail
Received: from mail121-tx2 (localhost.localdomain [127.0.0.1]) by mail121-tx2 (MessageSwitch) id 1265369241291746_21862; Fri, 5 Feb 2010 11:27:21 +0000 (UTC)
Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.242]) by mail121-tx2.bigfish.com (Postfix) with ESMTP id 4377F1090050; Fri, 5 Feb 2010 11:27:21 +0000 (UTC)
Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server id 14.0.482.39; Fri, 5 Feb 2010 11:27:19 +0000
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 22A4E68008; Fri, 5 Feb 2010 11:27:19 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A03BEE1E211; Fri, 05 Feb 2010 11:27:19 +0000
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 0F42268008; Fri, 5 Feb 2010 11:27:19 +0000 (GMT)
Message-ID: <4B6C0099.3080202@cs.tcd.ie>
Date: Fri, 05 Feb 2010 11:27:21 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.23 (X11/20090812)
MIME-Version: 1.0
To: draft-ietf-dhc-dhcpv4-vendor-message@tools.ietf.org, dhc-chairs@tools.ietf.org, secdir@ietf.org, IESG <iesg@ietf.org>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A13BEE1E211
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.5 VDF=10.119.38)
X-Reverse-DNS: imx2.tcd.ie
Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv4-vendor-message
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: Fri, 05 Feb 2010 11:26:32 -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.
Document editors and WG chairs should treat these comments just like any
other last call comments.

The document defines a way to include vendor-specific messages
in DHCPv4. I've only one relatively minor comment:

Is this new message type likely to be used for passing sensitive
information like user credentials? (E.g. username/password) If that's
not the intent it might be worth stating that in the security
considerations, just to discourage folks from doing that unless
they provide their own confidentiality service. (I'm assuming
there's no general confidentiality mechanism available.)

Aside from that you may or may not want to capitalise the "should"
in the last paragraph of the security considerations. (I don't care,
but it might be an oversight.)

On a non-security point: I didn't get the real need for this from
reading the text and the references to the "Vendor-Identifying
Vendor Options" I found confusing. So you could improve that a
bit, but I assume that DHCP implementers would find it sufficiently
clear.

Stephen.