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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
