Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

From: Ralph Droms <[email-masked]>
Date: Sat, 17 May 2014 15:21:41 -0700

After reading the document, I don't fully understand where this
mechanism would be useful and where it wouldn't.  The meta-question
here is "what security problem does this mechanism solve?".

draft-ietf-dhc-sedhcpv6-02 defines a PKI/cert mechanism and talks a
little about leap-of-faith mechanisms/TOFU.  But the document doesn't
talk about various attack scenarios and which of those scenarios are
mitigated by the mechanism described in the draft.

TOFU prevents subsequent attacks by other servers once the client has
decided to TOFU some server, right?  How does that mechanism work:

1. in a home network?
2. in a Starbucks?
3. in a university/school?
4. in an enterprise?
5. when attaching to an ISP?

Put simply, do I have it right that the "leap of faith" prevents
future attacks spoofed as coming from that server?  The client has no
knowledge about whether the server might mount an attack itself.

Trusting a cert requires some way to evaluate that cert's
trustworthiness. Seems applicable in some scenarios (maybe #4 above)
but not in others ... unless we implement some huge infrastructure for
handing out "approved DHCP certs".

Specific questions:

Can a server send a secure DHCPv6 message in response to an insecure
message from a client?

What is the definition of "secure model" in section 4.3?  I assume you
mean the client should "start by sending secure DHCPv6 messages".

In section 4.3, suppose a DHCPv6 legacy DHCPv6 server decides to
discard a secure DHCPv6 message (which may not be compliant with RFC
3315).  I suggest the document recommend that a client fall back to
non-secure DHCPv6 messages if it receives no response to secure DHCPv6
messages.

Section 6.2 mentions the requirement for a "local trust public key
list".  In my opinion, this requirement is a very important
characteristic of the security mechanism described in this document,
and should be explained much earlier in the document.