[secdir] Secdir last call review of draft-dhcwg-dhc-rfc3315bis-10
Kyle Rose <krose@krose.org> Wed, 17 January 2018 21:37 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 0B7BD12D7F7 for <secdir@ietfa.amsl.com>; Wed, 17 Jan 2018 13:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 mDDdKXQIDJc5 for <secdir@ietfa.amsl.com>; Wed, 17 Jan 2018 13:37:13 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 CF43F129C6F for <secdir@ietf.org>; Wed, 17 Jan 2018 13:37:12 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id x27so17281501qtm.12 for <secdir@ietf.org>; Wed, 17 Jan 2018 13:37:12 -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=C6U6x1UB0iHNdsfwb3tOegJqMXt1pMQPbNVBAakOnfI=; b=nO0TaFpLXjtxzuQ0XO3dvq0v0+A8CaRTfX0KWGeicIABtOayAKXEwZj7Gr/SsXnOkY mHycrYCHKrsGYHwHBU8lPnPkBnP0MvrcNf+lE2BAtSCQqmUgdGhw0/LOkDYkpmRUB+ls 53RqldED+wtvyCnmIZqbxTiEQFlwR+LJXqiyA=
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=C6U6x1UB0iHNdsfwb3tOegJqMXt1pMQPbNVBAakOnfI=; b=Ht074GDcH77DUBYdPmV3bJ5TfqhDSQAQEXQwQukgetTp0+HOzThqqraOT4c/P37mtx Y3r0WykRgWiZ5xtm1fSlfyLY4K5jYTEvdI32T8WB4h0ePLvdWVIWroitkdg09Vl1oy0g Bkg1N4j10WCmCw94ViRhtcgLUUbQbh5slXPfjy9Bg5lcZ7c1FRIZDBtCYHogXhNKPGMN cfhqnDU1Y7gZBoxfcBjZaqKkhcl2IZSc8FMy62RIXXTzYxjrwnTLD8Pm5PMGLvIs2dZY X71xQwtTJBry8Pn2sOg99GLFq0NtHO3ForWf4KEBsLap0cELoueuS+PYBs8MJgINOivd LcGw==
X-Gm-Message-State: AKwxytfi3yxQ86fLm/ONL9rNKnfcBYvFcvk5RJbgRXbhp5ydSrwypCIe v+9HDm5bhVVHuNkPwWojnh56cblSNzEfqnH5sRwsNg==
X-Google-Smtp-Source: ACJfBotsf6/JVQYMVSHeFbZQJDwvKmY80uaK7E6wcUKk6Vakr4wndJSO5FuSwYqPUFYc2kR1UAUXZ9FoB7U2X7J0420=
X-Received: by 10.237.35.14 with SMTP id h14mr38831828qtc.300.1516225031687; Wed, 17 Jan 2018 13:37:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.160.129 with HTTP; Wed, 17 Jan 2018 13:37:11 -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:37:11 -0500
Message-ID: <CAJU8_nWauC9qTmXm0LSfNqSrtXHEtQAfY0YWKn4Te3o1xje-9g@mail.gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-dhcwg-dhc-rfc3315bis.all@ietf.org
Content-Type: multipart/alternative; boundary="001a1147374669e4890562ffa6af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/A3Lkt-ceWLuZb_DhjlXIMXZocag>
Subject: [secdir] Secdir last call review of draft-dhcwg-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:37:15 -0000
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.