Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08

Ted Lemon <Ted.Lemon@nominum.com> Fri, 03 June 2016 18:55 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4312D890; Fri, 3 Jun 2016 11:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApfQM9Y9xZry; Fri, 3 Jun 2016 11:55:23 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F32912D79E; Fri, 3 Jun 2016 11:55:23 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 02D5C740057; Fri, 3 Jun 2016 18:55:23 +0000 (UTC)
Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0224.002; Fri, 3 Jun 2016 11:55:22 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-dhc-topo-conf.all@tools.ietf.org" <draft-ietf-dhc-topo-conf.all@tools.ietf.org>
Thread-Topic: SecDir review of draft-ietf-dhc-topo-conf-08
Thread-Index: AQHRvboIwWZ+4oxi9kOjVXNkE7+iIJ/YFijQ
Date: Fri, 3 Jun 2016 18:55:22 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A4F7ED@mbx-03.WIN.NOMINUM.COM>
References: <5751B895.1070400@gmail.com>
In-Reply-To: <5751B895.1070400@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.182.60.179]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/MnuJa9u1CtLhSDg_qQ13XxxWAjc>
Subject: Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 03 Jun 2016 18:55:25 -0000

With all due respect, Yaron, I think that your proposal here is surprising and unrealistic.   Enumerating the security tradeoffs you've proposed would be very difficult, and we would almost certainly get it wrong.   Furthermore, there is no pressing need to do this, or if there is, you have not said what it is.

The scope of what you are proposing here would be an entire new document.  If you are interested in working on such a document, I would encourage you to do so, but to increase the scope of work of this document to talk about address allocation with DHCP from a security perspective is not a reasonable ask.

________________________________________
From: Yaron Sheffer [yaronf.ietf@gmail.com]
Sent: Friday, June 3, 2016 13:04
To: IETF Security Directorate; The IESG; draft-ietf-dhc-topo-conf.all@tools.ietf.org
Subject: SecDir review of draft-ietf-dhc-topo-conf-08

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 describes current practices for configuring DHCP in
complex network scenarios, where the goal is to allow servers to
configure DHCP clients differently depending on the client's network
location.

Summary

This is a very extensive document, but the security considerations do
not do it justice.

Details

The Security Considerations section is essentially empty, saying only
that drafts that define DHCP options each include their own security
considerations. However this document references 12 other RFCs (and they
in fact do have substantial security considerations) so this leaves the
reader to research the matter on her own.

Moreover, the technology covered spans more than 20 years (15 years,
counting only Relay Agent Information), and security best practices have
changed. Old security recommendations may not be today's best practices,
and some previously recommended mechanisms may have never materialized
in real-world deployment.

This document is basically a survey of best practices in deploying DHCP
in complex networks. As such, I would expect the Security Considerations
section to include:

- Recommendations about which configuration practices are to be
preferred from a security point of view.
- Up to date security recommendations in summary form, at least for the
main use cases covered.
- An architectural view, at the same level as the rest of the document,
of how these configurations interact with common security practices like
firewall-based network separation or NAC.

I realize that the document is 3 years old and everyone just wants to
see it published, but in my opinion it is incomplete in its current form.

Thanks,
        Yaron