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

["Lishan Li" <[e-mail]>]

Dear Christian,


Thanks for your comments. Please see inline.
At 2015-07-30 08:17:30, "Christian Huitema" <[e-mail]> wrote:
>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.

>
[Lishan]:  For the client identity reveal problem, Ralph and Jinmei examined the same problem in the original design. In the 01 version, we have solved the problem. And according to Ralph's suggestion, we currently adopt a scheme in which the server offers its certificate first, and then the client encrypt all of its traffic with the selected server's key, so that the message can only be decoded by the specific server. 
For the spoofing attack problem, our mechanism mainly focus on the client privacy protection. 
And I am sorry not to understand the "dubious security gain", could you please explain it more detail? Thanks!


>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.

>
[Lishan]: The link-layer encryption 802.1x and EAP you mentioned is only designed for the Wi-Fi network. For the general scenario, such as wired environment, the DHCP encryption is needed. 


>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.
>
[Lishan]: I cannot agree with you. Whatever in the "trusted networks" or "untrusted networks", DHCPv6 encryption can both achieve the server authentication and encryption to protect the client's privacy.
Best Regards,
Lishan
>
>
>_______________________________________________
>saag mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/saag