This is a discussion on An argument from a contrarian point of view (was: Pimping DNSSEC) - DNS ; On Tue, Dec 05, 2006 at 10:59:18PM +0000, Alex Bligh wrote: > based on certificates etc., and teach apps that in general DNS alone > cannot be trusted". wc -l /etc/services suggests this is an inefficient > route to take ...
On Tue, Dec 05, 2006 at 10:59:18PM +0000, Alex Bligh wrote:
> based on certificates etc., and teach apps that in general DNS alone
> cannot be trusted". wc -l /etc/services suggests this is an inefficient
> route to take (yes, a gross simplification I know, but you get my point).
I get your point, but I'm not really convinced by it. (I'm not
actually convinced of anything in this thread yet, though.)
Suppose I am a DNSSEC contrarian. My argument will go like this
(sorry; it's a little long):
* * *
DNSSEC, including the newer proposals like NSEC3 and SO, places the
security at the wrong point in the network. Application designers
have the responsibility to build the security they need into their
applications. That sometimes means that they can choose not to care
(because loss of data or insecure transmission is acceptable). That
sometimes means that they can choose to provide fairly minimal
security (because, for example, the cost of better security is more
than the value of the data). It sometimes means that users will have
to endure inconvenient out-of-band negotiations of security prior to
connection. And it will sometimes mean that multiple authentication
mechanisms at the ends will be needed (probably with some dependency
on the previous item).
Some will argue that there is inefficiency in that approach, because
several of the security problems could be solved by making the DNS
smarter. But this violates the principle that one should put as much
of the decision making at the edges; DNS is too central to provide
those security services. This is the cost of a dumb network/smart
edge model (which is outweighed by the other benefits).
Some will argue that the application designers will make the wrong
decision (and point to /etc/services as one piece of evidence). But
the failings of previous applications do not entail that some other
part of the Internet should be improved; that is merely an argument
for fixing such applications. And fixing such applications is again
more consistent with pushing as much of the intelligence as possible
out to the edge of the network.
Some will argue that, because there are applications that really need
the security, but whose users simply aren't willing to bear the
inconvenience of multiple-method authentication and out-of-band
mechanisms. I, Contrary Guy, answer that if users aren't willing to
bear such inconvenience, then they have in fact decided that they
don't really want the security after all.
Some will argue that the users of the Internet are not technically
sophisticated enough to do the work of out of band negotiation,
pre-loading of others' certificates, and the like. I, Contrary Guy,
answer that, if such is true, the application designers are shirking
their duty to their users: usability problems are not going to be
solved by remaking the underlying technological support, because the
usability issues will still be there.
Some will argue that the users of the Internet are gullible, and
DNSSEC is needed to protect them. I, Contrary Guy, answer that the
history of tech fixes to solve the problem of human gullibility is
littered with failure, but has no claim to even one success.
Finally, there remains the problem in DNSSEC that the costs of it are
not borne, or are borne at best indirectly, by those who want the
additional security it provides. In order to add this additional
security for some applications, the entire Internet community (or at
least, a significant portion of it) has to bear the burden of
additional load on the DNS and considerably larger DNS packets.
Moreover, several of those who have that burden to bear are either
contractually unable to extract compensation, or are simply too far
from the end to get such compensation from the users. In both cases,
the effect will be that the cost will be temporarily externalized,
and then will be internalized in some other way that distorts the
relationship between service and cost. This distortion is a result
of not following the end to end principle rigourously enough, and
therefore should not be tolerated.
* * *
I want to emphasise that I'm not sure I buy any of the above, but
each of these is one I've heard. Together, they seem to be to be a
pretty strong argument that anything complicated to deliver DNSSEC is
unlikely to prevail (so far, I am unable to come up with much of an
argument to completely counter all of the above). If that's right,
then something less ambitious but simpler, such as the SO approach,
might be a better answer to the extent we think this is a problem
that needs solving.
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
jabber: email@example.com +1 416 646 3304 x4110
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.