Telechat Review of draft-ietf-dhc-rfc3315bis-10
review-ietf-dhc-rfc3315bis-10-secdir-telechat-rose-2018-01-18-00

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.