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

Lutz Donnerhacke lutz at thur.de
Sat Aug 30 17:22:03 EDT 2008


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.





More information about the EURO-Discuss mailing list