Hi Paul, Thanks for your comments. I also share your opinions. I add my comment in the body part.
On Mon, Oct 21, 2013 at 8:16 PM, Paul Wouters <[email protected]> wrote: > On Mon, 21 Oct 2013, Daniel Migault wrote: > > Please find a draft that defines DHCP options to provision DNSSEC >> validators so DNSSEC >> validation can always be performed. >> >> Feel free to make any comments. I would be happy to have f2f discussion >> during IETF88 to solve >> this issue with a more complete document. >> > > I am a little worried to bring this into the DHCP layer. While the > document makes statements about only accepting trust anchors when > the DHCP server is "trusted", when thinking about CPE equipment, old > handhelds, etc, there is no such trust relationship. (I'm also not very > familiar with what a "trust relationship" is between a DHCP server and > client?) > By trusted relationship, I wanted to clarify that authenticating the DHCP Server is not sufficient. The Client MUST trust the DHCP Server. More specifically, when you are in a corporate network you assume you are in a trusted network, so you trust information from your DHCP Server. On the contrary, in a cyber café, even if you authenticate the DHCP Server as the one of the cybercafé, you do not necessarily trust it to the point to accept crucial information. Practically, this means that these Options must be 1) considered cautiously by the DHCP Client and 2) "only" when they are provided by trusted networks, that is mostly the corporate network, or the DSL line at home. One reason I posted the draft in the homenet WG instead of DNSOP is that the DHCP Options may not apply to devices connected to different untrusted networks. More specifically, a mobile WiFi device in your pocket that wakes up every months/years may not use these options unless they are at home. > I'm also a little nervous about using certificates to kickstart dnssec and > time, especially because it just moves the problem to certificate validity > times. When not under attack, it's much simpler to insecurely query for > the root key and use that key for an initial time setting as well. > > Thanks, this point has not been addressed in the draft. The reason to use certificate is that ISP will not deploy DNSSEC in DSL boxes, if they have no way to push securely the valid KSKs. I saw certificate as one way to provide authenticated information, and this information can be provided over untrusted/unsecured/unauthenticated channels. True that if the device is desynchronized, signature checks cannot be performed neither for DNSSEC nor for certificates. To use certificates the device needs a valid CA and a proper time. If the device is desynchronize, it should use the time value provided by the DHCP Time Option. This only works if provided by a trusted DHCP Server. As a result, for a desynchronized device it may not provide any advantages, and sending the KSK insecurely is much simpler. The question is then for desynchronized devices, does it worth protecting the KSKs with certificate, if one parameter (the time) is not authenticated. > For CPE devices, I think querying for the root key without dnssec to > use as time and possible TA is something it could possibly prompt the > user for. It would work without DHCP and not require new DHCP options. > CPE devices could also insecurely query for the proper ICANN website and > grab the trust anchor bundle (i.e. what unbound-anchor does) and use the > certificate of ICANN. > > That is definitely one way to get the root key. What we propose by providing the certificate with the KSK is very similar. The only difference is that the CA may not be only the one the ICANN but can also be the one of third parties like the ISP. In both cases, CA have to be provisioned in the devices, and the device is expected to perform signature checks, so we have the same issues as above. The big issues I see are: 1) It only applies to the Root Key. Which means the CPE cannot recover for example from TLD that had an emergency roll over. In addition the Root Key is probably the one that is mostly unlikely to have issues with emergency roll over. Most of these issues are expected to happen with other subzones. 2) If does not provide the ISP to mitigate a key roll over issue performed on the Internet. If a problem occurs, the end user will not call ICANN. > For enterprise devices, I would assume that an unfiltered internet > connection is not available (firewalled, etc) so it might need something > else. However, there is likely good reason to have trust in the LAN, > and a time estimate could be obtained from the NTP server through DHCP > (option 42 could provide an IP address for one entry, therefor removing > the need for DNS to obtain NTP) > > Good point, providing IP addresses makes DHCP Time Option unnecessary. Difference between ntp client vs DHCP Options is that using ntp client adds round trip, and requires the ntp client to be installed. If that does not cause any problems, then we should use option 42. > I do see a need to transfer DNSSEC TA's once we see split-view DNS where > at the very least the public view is signed and there is a "lie" for an > internal only zone that needs to be believed. I am not sure how those > should get authenticated though. I wouldn't want my device to accept a > rogue trust anchor and a DNS forwarder to use and take over all my DNS. > > So I do think we need OPTION_DNSSEC_KSK_RR_TRUST_**ANCHOR. I'm less sure > about OPTION_DNSSEC_CERT_TRUST_**ANCHOR. > > I see your point with split-views. I should add this to the draft. I agree that CERT may not be very useful in LAN or trusted environment. On the other hand it would really help that ISPs can provision the devices with KSKs and authenticate them. In addition I would like also a standard way to store KSK in certificate. The format adopted for the Root Zone seems very specific to the root zone. > > OPTION_TIME seems like a good addition but I'm also afraid of this being > used in combination with a (fixed) registrar/registry compromise to > replay old DNSSEC signed records. It should only be honoured by devices > that are known to be in a timless tate (eg if its 1970). > > I am not sure we should consider these devices, maybe sensors or IoT have different ideas on supporting ntp client. I feel using NTP is much better. > A discussion would be very helpful to talk about the various security > implications, and to ensure that we can keep the differences between > DHCP and IKEv2 options for VPN as small as possible. Definitely. I have not mentioned VPN use cases, but we should consider this case with more attention. Wen you say "as small as possible" do you mean that we should also define new CP attributes? I am sure I must misunderstood something, but I expect the VPN client to get the DHCP Server address from the security gateway(INTERNAL_*_DHCP) and from that the client sends the ORO to the DHCP Sever. > > > Paul > Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
