On Sat, Aug 30, 2008 at 03:25:16PM +0200, Patrick Vande Walle wrote:
I am not sure I understand your point. PKI require a "trusted third party". This is necessary when both parties do not know each other, which is the case in DNS name resolution. PK architectures are hierarchical by design.
PKIs are not necessary hierarchical: - OpenPGP uses a network of trust. - The classical X.509 PKIs consists of a forest of very flat trees. DNS is one of the remaining true hierarchical structures in the Internet. True hierarchical PKIs provide the possibility to use the obtained certificate to issue further certificates for the own administred environment. Typical X.509 certificates are cutted on this subject soley for monetary reasons. DNSSEC transposes the extensibility of the hierarchical structure from the DNS to a PKI. That implies the opportunity to generate as much certificates for the own admin sphere as necessary for free. Example: I'm responsible for fitug.de. Asuming a working DNSSEC infrastructure I have a certificate for my "DNSKEY/thur.de." entry from the DE-zone. They have a certificate for their "DNSKEY/de." entry from the signed root. The root key (or multiple keys) is the public known root key. If I set up a secure webserver, I can include a "CERT/www.fitug.de." entry into my(!) zone and automatically obtain a certificate chain up the the well known root. This CERT record can be obtained from the DNS in a validated way by a web browser in order to set up a SSL connection for my https site. How can such a scheme be attacked? Where does classical X.509 certificates win? A phishing attack might lead the visitor to a completely unrelated site, which can provide a valid certificate for the different name. Bad luck. X.509 and DNSSEC both fail to detect this. A pharming attack might provide a different IP for the same DNS-name. The attacker can't finish the SSL-handshake, because he does not have the private key for the certified public one. Both X.509 and DNSSEC prevent this type of attack. DNSSEC in addition prevents the inital poisoning step. A pharming attack might provide a different IP for the name servers of the zone. Because the CERT entry is in the zone, the attacker can provide it's own key pair and change ther CERT record, too. X.509 is not vulnerable to this kind of attack, because the certificate chain is maintained offline. DNSSEC prevents this kind of attack, too, because the necessary key rollover requires an administrative interaction with the parent zone, which is maintained offline. So even the attacker can change the signing keys, the chain will break. The server including the keys was stolen or overtaken by attackers. Bad luck. X.509 and DNSSEC both fail to detect this. X.509 provides CRLs and OCSP to revoke issued certificates, DNSSEC provides a DS change in the parent zone. Main difference: The DS chain checking is immanent part of each validation process and therefore effective within a few days. OTOH CRL/OCSP-checking is part of an optional application based process and not really deployed. Even if this check is used, it can be fooled by redirecting the CRL/OCSP DNS hosts using poisoning. So in this case the DNSSEC "wins". If the attacker obtains the authoritation creditals for the zone management, he can redirect the zone and modify the parent DS entries. X.509 detects this, DNSSEC can't detect it. This case is important, because unauthorized holder changes are a common problem in the current DNS system. Mechanisms like RfC 5011 detects this kind of attack, but are not deployed now. So in this case X.509 clearly "wins". If the attack obtains the authoritation creditals for the certificate management, he can reissue a certificate for the same name with a different key pair. This case the opposite version of the last one. Several registrars offer X.509 and domain handling in a common portal. So both cases can be merged, and both systems fail to detect this kind of attack. If a customer of a shop/website feel be fooled and want to sue the company, he need an person to sue. X.509 certificate authorities are responsible to provide this data, and therefore allow contracts between unknown parties over the Internet: They make eCommerce legal. DNSSEC provides similar information via the registrars. Currently the registrars are not responsible by regional law(!) for handing out the correct data, therefor X.509 clearly wins the "most interesting point". If you switch to other protocols, like SSH, DNSSEC wins, because it already contains the necessary resource records and provide the certificates for free. Please allow me to keep denial of service issues out of this discussion for the sake of shortness. If you retink your needs for HTTPS/SSL/SSH/... you will notice, that the common user base is not interested in makeing large scale eCommerce, but secure their communication. DNSSEC does the job and is extensible to email, SSH, VPN, ... Let me make a cut here to prevent other issues mixing in. ----- cut line ----- cut line ----- cut line ----- cut line -----
The Domain Name System was designed to translate text strings to IP addresses. DNSSEC guarantees that the IP address returned by the query is indeed being served by the real DNS server for that domain. It is indeed tempting to use the DNS infrastructure for other purposes, but it was not designed for this.
DNS was invented to "distribute host files". Since the ancient days DNS servers more than IP adress lookup. It contains e-mail related records as well as other services. DNS is a distributed hierarchical database. Like it or not. DNSSEC converts this database into a trustworthy one.
You are right that there is a lot of FUD to be fought. One is that DNSSEC brings encryption. Actually, DNSSEC only demonstrates there was no man-in-the-middle attack on that particular DNS query. It should be noted that the DNS request and answer themselves are actually sent unencrypted over the wire. Current secure communications channels like SSL/TLS provide encryption right from the start of the transaction. Hence, relying on unencrypted DNS to store secure information would actually lessen the security.
I made clear, that DNSSEC can help to build SSL encryption for other applications. Please do not take an wrong argument too serious.
Certification authorities like VRSN do not fear DNSSEC, just like they do not fear community-based CAs like CACert. They perform a totally different task. If you ever purchased a high grade SSL certificate from a top vendor, you are aware of the paperwork this involves.
This paperwork is necessry to provide the "make eCommerce legal" part. Most private people does not need it for their communication. I'm applying for ALAC, not the ISP position at GNSO, nor the SSAC chair. Therefore my focus here has to be on the AtLarge community, not the big companies.
And even with DLV in DNSSEC, we are basically using an alternative root.
I do not talk about alternative roots. I do not support alternative roots. Of course I run an alternative root, but that's soley for a missing production grade DNSSEC infrastructure at IANA. My alternative root will vanish as soon as IANA signes the root.
So yes, I believe some lookaside mechanisms like DLV may help until such time that the root is signed. But to deploy a transparent DNSSEC end-to-end infrastructure for a general audience, we need a signed root.
I do not agree with you in this point. DLVs will be necessary even if a signed root and DNSSEC deployment through the registries is rolled out. There will be always islands of trusts (as seen from the se-zone experiance). But this is a completely different issue.