Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
John C Klensin <john-ietf@jck.com> Tue, 02 December 2008 21:01 UTC
Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8F228C1C7; Tue, 2 Dec 2008 13:01:17 -0800 (PST)
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 A71B53A6B58; Tue, 2 Dec 2008 12:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level:
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599]
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 bci+BizSABL2; Tue, 2 Dec 2008 12:54:11 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A7F1F3A6778; Tue, 2 Dec 2008 12:54:11 -0800 (PST)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L7cFr-0001bd-7w; Tue, 02 Dec 2008 15:53:59 -0500
Date: Tue, 02 Dec 2008 15:53:58 -0500
From: John C Klensin <john-ietf@jck.com>
To: Ralph Droms <rdroms@cisco.com>, Samuel Weiler <weiler@watson.org>
Message-ID: <56DEB14D23377D001B19EFE5@p3.int.jck.com>
In-Reply-To: <90AC45ED-BF49-46ED-A35A-14E1BF699959@cisco.com>
References: <alpine.BSF.1.10.0811260255330.4213@fledge.watson.org> <90AC45ED-BF49-46ED-A35A-14E1BF699959@cisco.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Tue, 02 Dec 2008 13:01:16 -0800
Cc: dhc Chairs <dhc-chairs@tools.ietf.org>, Richard Johnson <raj@cisco.com>, IESG IESG <iesg@ietf.org>, IETF Discussion <ietf@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org
--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms <rdroms@cisco.com> wrote: > Sam - I think most of the issues in your review of > draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing > the purposes of RFC 3942 and publishing Informational RFCs > describing DHCP option codes. Fundamentally, the reason to > publish RFCs under the process described in RFC 3942 is to > document existing uses of option codes in the range of option > codes reclaimed for assignment to new DHCP options. The > concern is to avoid conflicts between new options and those > grandfathered ("hijacked") option codes. As such, these RFCs > (usually Informational) simply document the already >... > Responding to some of your specific points: > >>> At the very least, I suggest mandating the use of DHCP Auth >>> and removing the suggestion to use option 66 to enhance >>> security. And, in the absence of a more data about how >>> widely used this option is, I suggest not publishing this >>> document at all. > > The consensus of the dhc WG, to which I concur, is to publish > the document as Informational. The text in the Security > Considerations section about option 66 might be removed. >... > To reiterate, it's not so much a question of whether a new > code point is needed; rather, according to the procedures > described in RFC 3942, this document gives a description of an > existing use of option code 150. That option code is in use >... Ralph, It seems to me that there is a middle ground here. One can stick with Informational publication as the WG intends, but still modify the Security Considerations section, not only to remove the reference to option 66 (if there is consensus that is appropriate) but to add some explanation about why the use of this option without authentication might be problematic. Put differently, your objection to Sam's suggestion seems to hinge on "just describe the existing practice, don't try to change it in this document". Given RFC 3492, that is entirely reasonable. But, if there are relatively obvious difficulties with that practice, it seems to me that documenting them would be helpful (indeed that not doing so borders on irresponsible). john _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
- [secdir] secdir review of draft-raj-dhc-tftp-addr… Samuel Weiler
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Ralph Droms
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… John C Klensin
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Samuel Weiler
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Richard Johnson
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Richard Johnson
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jari Arkko
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Ralph Droms
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Ralph Droms
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Cullen Jennings
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Samuel Weiler