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.

At 17:15 31/08/2008, Patrick Vande Walle wrote:

Security is not only a bunch of smart shell scripts around openssl or dnssec-signzone. It is first and foremost how clearly identifiable you are in the real world and what credit you get from others. Users both large and small are less concerned with the company's technical ability than by its toll-free number for complaints and the office address where they can send their lawyer letters.

This is a first point. Second point should be that security should be simpler, cheaper and more robust. As often with the Internet one add an option to patch a missing part. Here, like in IDNs the presentation layer is missing. Question: is there a way to simply (hence architecturally) build a secure Internet? I think there is one as a ONES (open network extension system, i.e. in using an OPES underlaying system). But this needs to be really investigated and the WG-OPES was closed when we could have started discussing it. Not yet in the IETF thinking paradigm. But that could probably be implemented as an Internet Plus recipe? Third and more important mid-term point. Secured relations are of the essence in the Inter Semantic network usage. More and more facilitation technologies will evolve towards networking as a replacement of writing or showing human utterances (certainly within less than 10 years). Semantic addressing is the simple way we say to day "dnssec as I think it is" which will translated to "dnssec.jefsey.com" that your computers can compare with dnssec.vande-walle.eu and dnssec.thur.de to try to propose us a consensual synthesis. Is that a dream? I am working on an IETF Draft on Semantic Addressing, so I am interested (similar but interactive and much more common than URI). The semiotical maieutics for our fellow servers to datamine/interview our brains is something separate that advance well in parallel. We use it for years for simple issues (like psychological tests, school quiz, etc.). This means that a security oriented architectural shift of the Internet is necessary and therefore financially acceptable once properly documented (it does not always means a technology shift, but a vision shift). Example. Before trusting any Private Key Institutions, we need to trust the concept and the network. Are Base64 keys secure enough? Is the Internet credible the way it is organised? As you say, we, people, tend to love what is clearly identifiable. When we ask for a toll-free number, we want to know where the toll-free number operator is located in order qualify the answers we get. We trust car plates and telephone numbers more than domain names because we know they are publicly displayed, related to something everyone knows (geography), in a way many will therefore perceive the possible conflicts (hence frauds or mistakes). There is a kind of built-in simple FEC (Forward Error Correction) in telephone numbers. If you want to call someone in the USA you know that "44" is not the correct header. You know your area code and you know if a number is local. This simple things the Internet misses have helped protecting us so far.

However, I still stand by my original position that domain name system is designed to translate strings of characters into IP addresses. This was the spirit of RFC882. It was designed to be a system where updates were not frequent. Caching and secondary name servers can provide an answer that may not be in sync with the primary. I do not really see how the DNS could handle the reponsiveness needed for revokation of keys.

I agree with you about the "DNS". But DNS is just a DDDS application. DDDS (RFC 3401 > 3405) are "Dynamic Delegation Discovery Systems". They are "used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached.". DDDS may have many applications (ontologies, multi-consensus building, documentation, classifications, e-mails, etc.) and should be worked on (also in ISO 11179 context of metadata registries). DDDS and DNS I think we should reconsider the DNS as a DDDS application, after having seriously worked on DDDS. The interest is that the DNS being a DDDS, backward compatibility should be protected. Let imagine an ISO 11179 conformant secure DDDS supporting a CVS. The problem with the DNS (IMHO) is that its a kind of "proprietary" development (filled with specific short-cuts and lacking hooks and proven extensions) and not a standard application of a known architecture supported by a competitive market. DNS has shown that the concept can be used in many areas. The concept. I fully agree: not the current implementation. However, if you consider DDDS, you see that the way IETF has defined them so far is a good start. Yet, they cannot depend on external parameters (like for example weather, load, warning level, costs, etc.) and must be closed "black boxes". That is too bad, because if you consider DDDS carefully you will be surprised how it can be close from most of the complex/intelligent thinking, utterance, and biology schemata. Have a good WE. jfc