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?)
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.
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.
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)
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.
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).
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.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
