Re: [EURO-Discuss] Short bio for the election of the Euralo representatives to the ALAC
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.
Dear Lutz and Wolf, would it not help if we investigated an ALAC-WG on Security as seen from a user point of view (documentation, solutions, open tools) ? I am in the process of rebuilding the france@large site to improve our wiki and documentation (not mailing list :-)) archives. We have to introduce the lists for a center of expertise on security and an other on identification. This could be within ALAC a first test what advocate : a multilingual techniocal user support cooperation? At 18:44 29/08/2008, Lutz Donnerhacke wrote:
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.
And possibly test it? jfc
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
At 15:25 30/08/2008, Patrick Vande Walle wrote:
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.
Patrick, you know this is politically and technically not possible. This is why Lutz tries the DLVs. The problem we have as users is to get a solution that works for us - DLV or others for the reasons you give - but which other?. This is up to us. This is why the WSIS acknowledged our legitimacy as Civil Society and, de facto, as part of the ill defined and technology moving Internet Community. This is why it has foressen to extend the IGF mandate to emergent new items. The question we face is therefore: is the DNSSEC adapted to the world as it really is? This reality is that there is no more a single root file. However , everyone, but ICANN, agrees to protect a single virtual root file. What is the solution that we (users) must retain in 2008, and possibly devise, while ICANN and IETF are enjoying themselves in a 1983 context. Is it our interest to try to wake them up, or do we forget about them for now, in the hope they join back later on? The real threat on the DNS is the incertitude on the intents of Paul Twomey and Chris Disspain after the NTIA publication and the current delirium about DN auctionning possibility. This only lead to State Protected DNS Public Services like in China. jfc
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.
Lutz Donnerhacke wrote:
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.
I have been using PGP ever since the Fidonet days. Over those 25 years, it never really spread outside the geek/hobbyist/hacker world, because it relies on both parties knowing each other before being able to accept the signatures. This may work in small communities, but it does not scale, for lack of a trusted third party. Agree that X.509 PKIs are mostly flat *BUT* they are run by well identifiable and reputable companies. I think this is my main point. 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.
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, ...
My needs as a normal user is that the banking web site I am accessing is clearly identified and guaranteed to be genuine by a reputable third party. My needs as a service provider is to be clearly identified and not to generate warnings in the customer's browser because of an unrecognized CA. If it happens, I will lose a customer. I agree there could be some situations where encryption is desireable but does not need to rely on expensive, unambiguously identifiable and detailed certificates. Those needs are already pretty well covered with PGP, community based PKIs, self-signed certificates, etc. Those who need them know how to use these services and tools. 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. Best regards, -- Patrick Vande Walle Check my blog: http://patrick.vande-walle.eu
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
participants (3)
-
JFC Morfin -
Lutz Donnerhacke -
Patrick Vande Walle