Activity Summary
- 5605 days inactive
- 5605 days old
- pacnog@pacnog.org
- 3 participants
- 2 comments
j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
http://stupid.domain.name/node/679
Today ICANN releases a paper with the title DNSSEC @ ICANN -- Signing the root zone: A way forward toward operational readiness. The paper explains in more detail than earlier documents what ICANN view on signing of the root zone is. I think the key points mentioned in this paper are true, and in general, I think this document is a good read. It is not long, and summarizes what I would call the current view is.
There have been some recent discoveries of threats to DNS. All described for example in CERT VU#800113. More information about these issues has now leaked and we have already some exploit code. For example CAU-EX-2008-0003. We also have data from Austria that show that a too low percentage of resolvers are upgraded. And further that the upgrade of software is not going as fast as one would hope. (Thanks Otmar et al for good work!)
No single detail in the attack is really new, but the combination of things is new, and the situation scares me. The fixes suggested (like upgrading Bind to a version that is secure according to column 29 in the BIND Vulnerability Matrix) is bringing us back to a situation where we thought we where. But the real solution is to digitally sign the data in DNS, and secure the full path between querying client and authoritative server. DNSSEC is today a solution to a large piece of that, but it also have to be deployed.
And the ICANN document just released is because of that good stuff.
-- Franck Martin ICT Specialist franck@sopac.org SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard
Franck Martin wrote:
But the real solution is to digitally sign the data in DNS, and secure the full path between querying client and authoritative server. DNSSEC is today a solution to a large piece of that, but it also have to be deployed.
Admittedly, I'm no DNS expert, but my understanding is that there are still problems with the current DNSSEC implementation.
I worry in particular about the human factors in DNSSEC: determining identity remotely leaves a number of 'social engineering' options open to attackers; user ignorance concerning certificates and signing authorities reduces their value; increased cost of entry for small-scale operators, especially in developing countries with no access to credit cards or other online payment methods.
Can someone with more detailed knowledge than I have comment on these issues, please?
Dan,
On Jul 24, 2008, at 3:06 PM, Dan McGarry wrote:
Admittedly, I'm no DNS expert, but my understanding is that there are still problems with the current DNSSEC implementation.
To clarify a bit, DNSSEC as a protocol has (mostly) stabilized and there are implementations of that protocol that work today.
I worry in particular about the human factors in DNSSEC:
Yes, human factors are an issue, but...
determining identity remotely leaves a number of 'social engineering' options open to attackers; user ignorance concerning certificates and signing authorities reduces their value;
Both of these aren't really relevant. If the root is signed, there will be one trust anchor that would need to be configured in caching servers. If the root isn't signed, IANA will be maintaining a repository of TLD trust anchors that will have to be configured. Those trust anchors will be provided to IANA with the same verification IANA implements for TLD changes, so the assurance level should be the same.
Just to be clear, DNSSEC trust anchors are a bit different than X.509 (SSL) certificates and there aren't CAs in the traditional sense. Zone managers can use openly available tools (e.g., dnssec-signzone, see http://www.isc.org/sw/bind/arm94/man.dnssec-signzone.html) . You don't have to buy the certs.
increased cost of entry for small-scale operators
Yes. More explicitly, there will be additional operational requirements -- you, as a caching server operator, will have to keep up with trust anchor key rollovers. If you are a zone administrator, you'll have to sign your zones and resign them when they expire. If you don't update the trust anchor when they are rolled over (which will probably be happening every 6 months or so), responses from the TLD will fail to validate (and the end users using that caching server will get an answer that looks exactly like a DNS timeout). If you don't resign your zones and they expire, no one (who has turned DNSSEC on in their caching server) will be able to resolve any names in your zone.
especially in developing countries with no access to credit cards or other online payment methods.
I don't believe this is the case (see above). I mean, you can buy tools to help you sign your zones, but there are open source tools (e.g., http://www.dnssec-tools.org/). IANA will be releasing their tools as open source Real Soon Now too.
Can someone with more detailed knowledge than I have comment on these issues, please?
Hope this helps...
Regards, -drc