[Discuss] free SSL certs from the EFF

[bogstad at pobox.com (Bill Bogstad)]

On Tue, Dec 2, 2014 at 12:22 AM, Richard Pieri <richard.pieri at gmail.com> wrote:
> On 12/1/2014 1:42 PM, Derek Atkins wrote:
>>
>> I think it depends very much on your definition of "Secure".  You are
>> correct that DNSsec does not provide any confidentiality services.
>> However it does indeed protect the data integrity from interloping
>> intermediaries and provide authenticated DNS Data.
>
>
> No, it doesn't. It only prevents cache poisoning when DNSSEC is enforced on
> your resolvers. If you do not enforce DNSSEC on your resolvers then your
> resolvers will accept any unsigned RRs including those that have had the
> RRSIG records stripped by malicious intermediaries.

Isn't that the equivalent of putting a lock on your front door, not
locking it, and then complaining about how easy it is for someone to
break into your house?

As far as I can tell, the problem with DNSSEC isn't with the
underlying protocols/processes; it is the chicken and egg deployment
problem.   As Ed Harvey discusses in a different message, not all
zones are signed.   This causes lots of problems.  The developers of
user apps haven't bothered to revamp their name lookups to pay any
attention to DNSSEC at all.   Requiring DNSSEC validation in the local
system library resolvers isn't a good solution as users will find they
suddenly can't communicate with many systems.  Even if developers add
DNSSEC awareness to user apps, what should their UI do for that case
where a zone isn't signed?  Do we really want users deciding whether
to accept an unsigned DNS entry?  Would app developers even be willing
to do this?   Given the push back that happened when browsers complain
about self-signed SSL certs, I tend to doubt it.   Particularly since
an unsigned DNS entry actually means very little at the moment.

So my thoughts turn towards the "hacks" of old (or new).   (old) SSH
known host files.   (new) SSL cert pinning.   If the local system
library DNS resolver kept track of whether a zone had previously been
signed, I would find a change to an unsigned zone to be of concern.
With an API change, you could inform the app that such a change had
happened and let the app/user decide.  In at least this case, we may
have some hint that there might be a problem.  With the old API, I
would make it configurable whether to fail or not (local policy).  I
might even want to do whitelists/backlists for particular zones and if
possible applications.

Then we have the issue of how do we maintain those lists on client
machines.   It's hard enough to do it for spam blacklists and mail
servers are managed by "professionals".
I'm not sure where this runs either.  If on the local machine, with a
fully recursive nameserver; I don't see how it works with
organizations that have different internal vs. external DNS zones and
there might be problems with proxy servers.  If on my DHCP provided
DNS server, do I REALLY want to trust it's answers (or policies).  If
the machine is mobile, I might want it to do different things
depending on whether I am connecting to my home, employer's, or coffee
shop's LAN.

You know what, I hate security.  Never mind...

Bill Bogstad