Lutz, 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. And even with DLV in DNSSEC, we are basically using an alternative root. In such an environment, I fail to understand how this may provide decentralization of certification services. 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. 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. 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 just cannot be done for free. The counterpart is that you get a certificate with all your company's details and an insurance scheme against counterfeiting, misuse, etc. Even community based CAs like CACert require you to show some proof of identity to upgrade your certificate. 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. All mechanisms I have seen that work around that hierarchical architecture are essentially non-transparent and unworkable for the average user. In this context, the one who will sign the root is important, because it will be the "trusted" third party. The whole point is that this party should inspire trust to all the parties (ie cc and gTLDS) below, and further to domain name registrants. Best -- Patrick Vande Walle Check my blog: http://patrick.vande-walle.eu Lutz Donnerhacke wrote:
On Thu, Aug 28, 2008 at 05:22:17PM +0200, JFC Morfin wrote:
I think we would be really interested to know your opinion on @large oriented whys, cons and pros of DNSSEC vs. other possibilities.
DNSSEC introduces a public key infrastructure. There is a lot of FUD around, but a working DNSSEC provides decentral certification services for free. DNS is capable to hold SSL certificates as well as S/MIME and openPGP keys. That's the main reason for opposing DNSSEC from some industry heavily involved into certification business: They fear to lose their business.
This way DNSSEC offers freedom of obtaining certificates in their self managed (sub)domains.
Of course, classical certificates are able to check more than holding the domain. They are necessary to build legal reationships for business contracts. Thats why they check that the owner of the certificate is the right one regardless of the current DNS state (which might be under attack). But for most cases, the difference will not relevant for the private user.
where could we find an @large readable documentation on DNSSEC, its governance needs, etc. Should it be operated under ICANN or as an IGF enhanced cooperation (I understand that ICANN planned to catalyse a DNSSEC dedicated structure gathering the TLD Managers?).
Should ALAC not be a partner into it?
Of course, that's why I voluteer for a DNSSEC track on the AtLarge summit in Cairo. Preparing this track requires to collect and write such materials.
_______________________________________________ EURO-Discuss mailing list EURO-Discuss@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/euro-discuss_atlarge-lists.i...
Homepage for the region: http://www.euralo.org