[dns-wg] What about the last mile, was: getting DNSSEC deployed

* Robert Story:

> On Sat, 24 Feb 2007 16:18:43 +0100 Florian wrote:
> FW> Unfortunately, the real showstopper I see is that you cannot tell an
> FW> attack from an infrastructure change that happened to break DNSSEC.
> FW> But we need to provide some kind of fallback in case DNSSEC breaks
> FW> because we absolutely must ensure that we match plain DNS in terms of
> FW> availability.  (And I don't think yet another security indicator
> FW> visible to the end user is the answer.)
>
> Well, you've got yourself painted into a corner here.

Probably true.

> I don't think you can have a fallback, or you haven't added any
> security.

I'm concerned that I'm *reducing* security (regarding availability as
a part of security).  I also don't want to create a situation where
organizations fear to DLV-enable their zones because a part of the
client population is no longer able to access them.  To some extent,
this has already happened to AAAA records.

Of course, this is motivated more by the categorical imperative, and
not by actual market share.  But you never know. 8-)

> FW> Running name resolution over 443/TCP to some central resolver
> FW> infrastructure suddenly seems much more attractive, doesn't it?
>
> Not particularly. Either way, you've got to get the ISPs to buy into a
> new way of thinking about DNS.

I think the idea (at least my version of it) is that you use a 443/TCP
TLS connection to a resolver to bypass the ISP.  The on-the-wire
protocol would still be DNS with DNSSEC.  The assumption is that the
ISP can't do transparent rewriting of TLS connections and will leave
the application traffic alone (which is no longer a safe assumption
for 53/UDP or 53/TCP -- or 25/TCP for that matter).