[EURO-Discuss] Short bio for the election of the Euralo representatives to the ALAC

Patrick Vande Walle patrick at vande-walle.eu
Sat Aug 30 09:25:16 EDT 2008


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 at atlarge-lists.icann.org
> http://atlarge-lists.icann.org/mailman/listinfo/euro-discuss_atlarge-lists.icann.org
> 
> Homepage for the region: http://www.euralo.org
> 




More information about the EURO-Discuss mailing list