On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
I would like to see us create an assumption that a given machine will only use recursive resolution services from a specific trusted source.
Trust no one. More and more devices will do their own DNSSE validation, and just use caches to get the data. That's the beauty of DNSSEC and one of the two main bottlenecks of DNSCurve (the other is requiring cpu for crypto on every packet)
This in turn requires us to add some features to the protocol as we need to add mechanisms for access control.
There is already access control possible, eg TSIG/SIG(0). Just no one seems to use it on the stub resolvers.
We also need to make some changes to get around widespread DNS hacks used to support roaming WiFi provision.
Most of those have moved away from DNS already and just hijack the IP port 80 stream instead.
[Oh we are so not close to being done with deployment here. If turning on DNSSEC means the typical Web surfer cannot get their WiFi access at Panera without reconfiguring their machine then DNSSEC is stone cold dead.]
The fix for this will come from the browsers, who have to deal with this situation anyway to avoid your 20 open tabs from reloading into a portal page.
Rather than using the approach in DNScurve, I would want to see something like the following: * When a new machine is brought up the configurer is asked which network they want it to be a part of, identified by a DNS name. This will be the place that the system will use to look for the trusted DNS resolution service. Since I use 8.8.8.8 I would enter 'google.com'. The default could be taken from DHCP * New RR to allow a machine to locate a trusted resolution service for the network and authentication protocols supported. The initial bootstrap could be taken from the DHCP service. * Key agreement mechanism that allows the client to establish a persistent binding represented by a kerberos style ticket * Packet encapsulation mechanism that enables a kerberos style ticket to be entered into client request packets.
Seems much easier to me to store 1 DNSSEC root key and do it yourself. Paul _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf