4 ms·

It would be nice if we could store SSL certificates on DNS records, like how email signing (domankeys/DKIM) works. Looks like there's already some effort for t

It would be nice if we could store SSL certificates on DNS records, like how email signing (domankeys/DKIM) works. Looks like there's already some effort for this: http://tools.ietf.org/html/rfc4398 http://tools.ietf.org/html/rfc4398 https://bugzilla.mozilla.org/show_bug.cgi?id=672239 https://bugzilla.mozilla.org/show_bug.cgi?id=672239

peterwwillis 12y ago
RFC6394 and RFC6698 are the useful bits here. The problem is they don't really offer much except a minimization of the attack footprint; instead of attacking one of 650 CAs you're attacking the dns root servers, which aren't impenetrable. The protocol itself has numerous flaws and basically nobody is implementing DNSSEC. If you combined it with a CA system it would potentially increase security for a given domain and DNSSEC users, and add onto that a Convergence-style decentralized system and you get another layer. Of course, that is a hell of a lot of extra complication just to prevent a state actor from easily circumventing your HTTPS connection, so I doubt anyone will go for it.
- xorcist 12y ago
  That is not fair criticism. The DNS root servers do not hold the keys to the root zone and have no ability to sign records. Neither do their operators. Please also do look up the list of successful attacks on the root zone infrastructure. It is a very, very short list. Not imprenetrable of course; nothing is. But it does not need to be. The fact that authoritative servers can not sign records is central to the design.
rakoo 12y ago
That already exists and is called DANE [0]. The issue with DANE is that you must make sure the records you receive are the good ones; unfortunately bare DNS as we know it doesn't provide any integrity or security, so we need a way to make sure there is no spoofing... and this is exactly what DNSSEC [1] aims to provide. The problem here is that while DANE is straightforward, DNSSEC is a massive pain to implement and, most crucially, maintain, especially for domain owners. Oh and the whole security relies on a hierarchy of key signatures that takes its root in the ICANN. So, instead of having a "decentralized" world of CAs, we go back to a hyper-centralized domain where everyone depends on the good actions of the ICANN. That sucks. [0] http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/rfc6698 [1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...
- xorcist 12y ago
  I don't think people should be so hung up on the risk of ICANN misbehaving. While the risk is obviously there, they have actually been very Internet-friendly in their lifespan and so far managed to steer clear of both government and private sector interference. (The big exception being all the new top domains created, which is a disturbing trend but not really damaging to existing ones.) When a certain naval themed torrent site hangs on to their domain name you know things are really not that bad. The good side about a central needle's eye for decisions is that all eyes are on them. Any bad move will be caught immediately by the community and routed around. One fuck up from their side and no one would trust them with the root certificate for DNSSEC any more. Until that happens, can't we at least agree that an authenticated DNS for certificate storage is a whole lot better than the current CA system. That does not mean development on alternatives should pause for even a second, but please get those TLSA records of yours signed and published today! Only then will we at least have something to compare other proposals against. The fact that we have a central DNS root will be with us for the forseeable future. And as long as we use domain names for identity that centralization will be a thorn in the side. But that is what we use, for better or for worse.
  - rakoo 12y ago
    > Any bad move will be caught immediately by the community and routed around And go where ? We don't even have an alternative when we have the time to build it, do you think we will be able to build one when everything goes down ? I agree with you that there are no viable alternative for the moment, and we should at least put those TLSA records. You will notice that I was complaining specifically about DNSSEC, not about DANE; as long as we have a secure way to transmit those TLSA records, everything is fine. A slightly better thing than what we have today would be: - Deploy those TLSA records, both in DNS servers and applications - Have everyone use its own resolver, or at the very least a resolver they really trust (if we want to benefit from the cacheability of DNS) - Transmit DNS records through a secure channel such as DNSCurve The advantage being that these are all available today with little modifications.
    - xorcist 12y ago

peterwwillis 12y ago

RFC6394 and RFC6698 are the useful bits here. The problem is they don't really offer much except a minimization of the attack footprint; instead of attacking one of 650 CAs you're attacking the dns root servers, which aren't impenetrable. The protocol itself has numerous flaws and basically nobody is implementing DNSSEC. If you combined it with a CA system it would potentially increase security for a given domain and DNSSEC users, and add onto that a Convergence-style decentralized system and you get another layer. Of course, that is a hell of a lot of extra complication just to prevent a state actor from easily circumventing your HTTPS connection, so I doubt anyone will go for it.

xorcist 12y ago
That is not fair criticism. The DNS root servers do not hold the keys to the root zone and have no ability to sign records. Neither do their operators. Please also do look up the list of successful attacks on the root zone infrastructure. It is a very, very short list. Not imprenetrable of course; nothing is. But it does not need to be. The fact that authoritative servers can not sign records is central to the design.

rakoo 12y ago

That already exists and is called DANE [0]. The issue with DANE is that you must make sure the records you receive are the good ones; unfortunately bare DNS as we know it doesn't provide any integrity or security, so we need a way to make sure there is no spoofing... and this is exactly what DNSSEC [1] aims to provide. The problem here is that while DANE is straightforward, DNSSEC is a massive pain to implement and, most crucially, maintain, especially for domain owners. Oh and the whole security relies on a hierarchy of key signatures that takes its root in the ICANN. So, instead of having a "decentralized" world of CAs, we go back to a hyper-centralized domain where everyone depends on the good actions of the ICANN. That sucks. [0] http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/rfc6698 [1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...

xorcist 12y ago
I don't think people should be so hung up on the risk of ICANN misbehaving. While the risk is obviously there, they have actually been very Internet-friendly in their lifespan and so far managed to steer clear of both government and private sector interference. (The big exception being all the new top domains created, which is a disturbing trend but not really damaging to existing ones.) When a certain naval themed torrent site hangs on to their domain name you know things are really not that bad. The good side about a central needle's eye for decisions is that all eyes are on them. Any bad move will be caught immediately by the community and routed around. One fuck up from their side and no one would trust them with the root certificate for DNSSEC any more. Until that happens, can't we at least agree that an authenticated DNS for certificate storage is a whole lot better than the current CA system. That does not mean development on alternatives should pause for even a second, but please get those TLSA records of yours signed and published today! Only then will we at least have something to compare other proposals against. The fact that we have a central DNS root will be with us for the forseeable future. And as long as we use domain names for identity that centralization will be a thorn in the side. But that is what we use, for better or for worse.
- rakoo 12y ago
  > Any bad move will be caught immediately by the community and routed around And go where ? We don't even have an alternative when we have the time to build it, do you think we will be able to build one when everything goes down ? I agree with you that there are no viable alternative for the moment, and we should at least put those TLSA records. You will notice that I was complaining specifically about DNSSEC, not about DANE; as long as we have a secure way to transmit those TLSA records, everything is fine. A slightly better thing than what we have today would be: - Deploy those TLSA records, both in DNS servers and applications - Have everyone use its own resolver, or at the very least a resolver they really trust (if we want to benefit from the cacheability of DNS) - Transmit DNS records through a secure channel such as DNSCurve The advantage being that these are all available today with little modifications.
  - xorcist 12y ago