Re: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

[Christian Huitema <[e-mail]>]

On Wednesday, July 29, 2015 12:48 PM, Randy Bush wrote:
> ...
> but back to picking on dhcp, :)
> 
> within an enterprise, one is tempted to suggest enterprise-controlled credential
> distribution; i get a cert (or whatever) oob to let my laptop authenticate the
> dhcp service and vice versa.  but enterprises are seeing a lot of byod, and i am
> not sure how they are dealing with that.
> do they really want to authenticate all mobiles?
> 
> in the coffee shop, one would like the mobile device to be given the dhcp
> server's credentials out of band; i suggested a QR code on the wall as one (i.e.
> there could be others) example.  and, unlike the enterprise, i think the mobile
> device should reveal as little as possible about itself.
> 
> bottom line: i do not think there are easy solutions in the introduction space.
> but it is our responsibility.  and i am trying to think about it and others should
> too.

I sent private comments to the draft authors already, mostly about applicability issues, and mostly in line with Randy's comments.

IMHO this draft has a narrow applicability, which depends mostly on whether the client trusts the network. In the cases where the client does not trust the network, I believe attempting DHCP encryption does more harm than good.  The point is, DHCP encryption hides some of the DHCP parameters from parties on the link, but it also reveals the client identity as part of the key negotiation -- or in any case it reveals "parts" of that identity. At the same time, in the absence of pre-established trust, encryption does not really protect against on-link attackers, since they can spoof the server. In the "random coffee shop" scenario, the actual privacy harm is a bad bargain for the dubious security gain. In such scenario, I would recommend data minimization, e.g., a combination of randomized MAC Addresses and the DHCP anonymity profile.

Even in the "trusted network" scenario, the gain is only apparent in the absence of link-layer protection. For example, enterprise Wi-Fi networks typically use 802.1x and EAP to negotiate a link-layer encryption key specific to the client. This goes a long way towards protecting all the link traffic, including DHCP. Clearly there is a residual risk of on-line attackers, such as a local computer owned by a virus. That risk is generally mitigated by filters in the switches, restricting the sending of DHCP and RA packets. DHCP encryption would be useful if it was easier to deploy than those filters, and more secure.

So we are left with the application domain of "trusted networks" that do not implement link-layer protection. In those networks, DHCP encryption provide some privacy benefits, by hiding the value of identifiers and configuration parameters.

-- Christian Huitema