[Discuss] free SSL certs from the EFF

[Derek Atkins]

"Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:

>> From: Derek Atkins [mailto:warlord at MIT.EDU]
>> 
>> And you've already violated rule #1: You must trust your resolver.
>
> That's the point we've been talking about.  I forget who said in this
> thread, that DNSSEC only provides security up to the last hop, not
> including the endpoint.

And I say that's not (necessarily) true!

> It is unavoidable that people will travel; they will connect to the
> internet in coffee shops and hotels.  It is not reasonable or
> realistic to expect them to trust their DNS resolver implicitly.  You
> cannot trust the resolver, unless you are your own resolver, or the
> resolver relays security information to you which you're able to
> validate for yourself.  It is unscalable for everybody to be their own

Okay, I think I see the problem here.  You are conflating multiple
different DNS services:

 * resolver
 * recursive resolver
 * nameserver
 * caching nameserver

These are, technically, *different* DNS services.  Yes, historically
they are often combined into a single process (e.g. BIND's named), or
split into a small stub (e.g. libc's libresolv) and a (possibly caching)
nameserver.  But there is nothing that requires them to be co-located or
even co-implemented.  Indeed, there is nothing that says that the
resolver must trust the nameserver (caching or otherwise).

There is absolutely nothing preventing libresolv from performing DNSsec
without running named or some other local caching nameserver.  I.e.,
there is absolutely nothing preventing an end system from performing
DNSsec without trusting the (caching) nameserver it uses.  This includes
not trusting the DNS nameserver provided by DHCP.  All you need is a
local resolver that implements DNSsec checks and uses the provided DNS
nameserver(s) for lookup and caching of RRsets.

> resolver - breaking the distributed nature of DNS.  So really, the
> only scalable solution is to provide security information to the
> endpoints.  Unfortunately, it's also unrealistic to expect all the
> dumb linksys routers and comcast internet connections of the world to
> be upgraded in any timely manner to support relaying security
> information to endpoints.  Yes it's possible for smart endpoints to
> query DNS providers as dictated by DHCP, and become their own secure
> resolvers if and only if the dumb DNS server failed to relay security
> information - but this starts out at the point of being currently
> unscalable.

Actually, most dumb routers like that *WILL* forward DNSsec RRs just
fine; it's really the obnoxious middleboxes (e.g. in hotels) that break
it.

> We'll probably get there someday, just obviously not right now.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available