against dnssec

[Neal Becker]

Paul Wouters wrote:

> On Sat, 17 Jan 2015, Björn Persson wrote:
> 
>> Both CAs and DNSSEC can be attacked by governments in different ways.
>> The author thinks that DNSSEC is more vulnerable. I happen to disagree,
>> but more importantly, those who feel that they need to can secure their
>> keys both through DANE and with a certificate from a CA. Using two
>> independent methods of verification in parallel is never less secure
>> than using only one of them.
> 
> And then on top of that, there is certificate transparency and dnssec
> transparency:
> 
> http://www.certificate-transparency.org/
> 
> that allows using multiple parties for trust.
> 
>> "DNSSEC is Cryptographically Weak"
>>
>> He claims that many keys currently in use aren't strong enough, and
>> makes it sound like that's a design flaw in the protocol itself. He
>> neglects to mention that DNSSEC by design allows both variable key
>> lengths, frequent key changes and specification of new ciphers.
> 
> Yeah, he argues the 90 day 1024bit RSA root key is too weak and compares
> it to 1024bit RSA keys used by CAs valid for 10-30 years. Although I
> do agree with him that the root ZSK key could be bumped to 2048 bit.
> I'd avoid ECDSA keys and other ECC because too many resolvers do not
> support those algorithms. ECDSA is still not always available because those
> systems are running older software before rhel/fedora allowed some (NIST) ECC
> code. Other ECC algorithms are still patent minefields (eg djb curves,
> brainpool, etc)
> 
>> He complains that DNSSEC doesn't secure the link between the recursive
>> resolver and its client. That's exactly what people are working to fix
>> by running a local validating resolver.
> 
> And there are APIs worked on for that, such as get-dns or
> draft-ietf-dnsop-edns-chain-query
> 
>> "DNSSEC is Unsafe"
>>
>> "Authenticated denial. Offline signers. Secret hostnames. Pick two."
>> OK, then I'll pick authenticated denial and offline signers. Hostnames
>> have never been secret. DNS lookups are unencrypted, so every time you
>> look up a name you tell any snoopers that that name exists. Why would
>> you need secret hostnames anyway?
> 
> It also completely ignores the issue that online signing for
> authenticated denial is an easy DDoS vector (similar to dnscurve
> which also needs to do crypto operations per query. The DNSSEC design
> of not requiring crypto on nameservers (esp not requiring private keys
> on publicy facing servers) was an excellent choice. Yes, an attacker
> with enough resources can find out "secret" hostnames, but so can
> pervasive monitors like the NSA by just vaccuming plaintext data. These
> "secrets" should never be relied upon.
> 
> Paul

The articles author has responded here:
http://sockpuppet.org/stuff/dnssec-qa.html

This quote caught my attention:

DNSSEC deployment guides go so far as to recommend against deployment of DNSSEC 
validation on end-systems. So significant is the inclination against extending 
DNSSEC all the way to desktops that an additional protocol extension (TSIG) was 
designed in part to provide that capability.

-- 
-- Those who don't understand recursion are doomed to repeat it