[secdir] Secdir last call review of draft-ietf-dhc-rfc3315bis-10
Kyle Rose <krose@krose.org> Wed, 17 January 2018 21:39 UTC
Return-Path: <krose@krose.org>
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 D3C3E12EA58 for <secdir@ietfa.amsl.com>; Wed, 17 Jan 2018 13:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 hvMzNLaIaClD for <secdir@ietfa.amsl.com>; Wed, 17 Jan 2018 13:39:40 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA48C12D811 for <secdir@ietf.org>; Wed, 17 Jan 2018 13:39:39 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id d54so13275839qtd.4 for <secdir@ietf.org>; Wed, 17 Jan 2018 13:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=PkFudlXbtPEljOY2A2//uIRcEZJ31zDtvq3q8S9yLk0=; b=ZH1ztcMvicUYqKpyDKCOsG0SQGDhzhildbqzWNuUVmWDX1uixA8cFA8eFJvM4Kv1oq N/GKmnReIfKfXjag/mESOgDBRHk+ZpCxDByF4vwbWY0U9T6nbkbx6zdDROWKspLMeLiI WNF9kUiPfcGqurSM7YdGp7TGmvXkby48FfBJM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PkFudlXbtPEljOY2A2//uIRcEZJ31zDtvq3q8S9yLk0=; b=moPK6F3mMCic5zQvs8N+CyUF4ntBIkNpgQvTgGdX46xbzGFj7aTY5YhO2Js4wB1y3y MUKAsz6+6hoZ6s+INVPgTtOYt+e2gVSJrdH3kIRozFe1YhAdBXnevbKPucMpsLx2NkfS 3Gs8dwJ0f+Ne/PgLq135Zu5dyuZ+hM4PzlhRtyTQzlsMvamyMxtUEldByOdAlIRSrAvb YChju4i6VA+cOQJ1mfGMCTBDB7TaNYfuBsPI5BiwO1Jc8Y4YeAFM4Dt3S0wl3ZP0kJzy qOWPyzG2TmuOGj6acQ1suCWAfc9hfNSdFes9E6mKCt+DiHVa1+ahbCIo7pv+lkKTvOMM gmCg==
X-Gm-Message-State: AKwxytdRYMVbAgTPChyVpcfpMNkOlkGrz7/wd0JpZIQ7ub8oyuXK4BOi 4JJIur52JOTKG3y+37SOdPLN/oDa6wcciWkfKq/XJw==
X-Google-Smtp-Source: ACJfBottt5z2/OwcM1I99n+SRATYoJCy1oLJUtus7j3gvLAe6h+0IarkFjfUyNQ/CKaObkm/YjrGqxZzH48WnS0W9Ak=
X-Received: by 10.200.25.91 with SMTP id g27mr29966854qtk.71.1516225178834; Wed, 17 Jan 2018 13:39:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.160.129 with HTTP; Wed, 17 Jan 2018 13:39:38 -0800 (PST)
X-Originating-IP: [2001:4878:a000:3000:90dd:a551:c1d:b21]
From: Kyle Rose <krose@krose.org>
Date: Wed, 17 Jan 2018 16:39:38 -0500
Message-ID: <CAJU8_nX_f0ry1y3Fg7niqAHf_50TVz+YqdsAYTP_e5xkuK2JCw@mail.gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-dhc-rfc3315bis.all@ietf.org
Content-Type: multipart/alternative; boundary="001a11482cbe2f2cf80562ffaf14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ncRV6C2qOKTUIEFD0DeGurKIYR8>
Subject: [secdir] Secdir last call review of draft-ietf-dhc-rfc3315bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 17 Jan 2018 21:39:42 -0000
Let me try sending this to the right .all address. Reviewer: Kyle Rose Review result: Ready with issues 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. 13.1: "By default, DHCP server implementations SHOULD NOT generate predictable addresses." The justification for this is not addressed in the security considerations section, while the privacy considerations section might be punting this to RFC 7824, though the only mention I can find in a quick search regards iterative allocation in section 4.3. 20.4.1: RKAP uses HMAC-MD5 for symmetric authentication. As an informational matter for an existing protocol, this is certainly justified, but I don't know how the IETF handles obsolete crypto in standards revisions. 20.4.3: "...the client computes an HMAC-MD5 over the DHCP Reconfigure message [ADD: with zeroes substituted for the HMAC-MD5 field], using the Reconfigure Key received from the server" 22. DHCP's security threat model is not clearly stated. For instance, RKAP provides protection against man-on-the-side reconfiguration attacks, but DHCP has no ability by itself to protect against a race between legitimate and rogue DHCP servers: such protection relies on management of multicast groups at layer 2. This is implied by the paragraph on snooping DHCP multicast traffic, but nowhere is it specified normatively that restrictive group management is necessary to eliminate this part of the attack surface. Similarly, it's not clear to me whether a rogue or misconfigured server temporarily in the All_DHCP_Servers or All_DHCP_Relay_Agents_and_Servers multicast group can then hide a client from the official DHCP servers forever by sending it the unicast option, thus maintaining exclusive access to certain messages, notabley Request and Renew. The threat model should be stated clearly in this document, even if the recommended countermeasures are in some other RFC (such as RFC 7610) because they rely on information not in this document. 23. Does it make sense to clarify the threat model for privacy? For instance, this protocol doesn't try to defend clients against tracking within a LAN that can observe the DHCP traffic. I can guess what the threat model is, but ISTM that it should be specified explicitly.
- [secdir] Secdir last call review of draft-ietf-dh… Kyle Rose
- Re: [secdir] Secdir last call review of draft-iet… Bernie Volz (volz)
- Re: [secdir] Secdir last call review of draft-iet… Kyle Rose