3 ms·

The usual argument against certs in DNS is that nameserver owners can quietly issue valid certs. You have national domain? Your government can transparently cr

by hdhzy 10y ago

The usual argument against certs in DNS is that nameserver owners can quietly issue valid certs. You have national domain? Your government can transparently create valid cert for your domain. For more details see https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html

andrewstuart2 10y ago
I think that would be fairly easy to create rules for, though. Only check at the level where registrars are handing out domains (i.e. trust the most-specific SOA, not counting TLD). In fact, with LetsEncrypt or DV in general, I'm not sure what exists already to stop the scenario you're referring to. My TLD can decide they want certs for my domain and start advertising their nameservers to any IP addresses owned by LetsEncrypt. As it is there's plenty of manual checking that keeps CAs in check. I don't see why the same processes couldn't be applied to such a system.
- hdhzy 10y ago
  You can check that a new certificate was issued for your domain through Certificate Transparency. Maybe if DANE/TLSA certs would also have be submitted to CT logs and browsers required CT that'd provide stronger security that we have now... Another thing is DNSSEC's reliance on RSA 1024 (did that change?).
  - deleted 10y ago
    [deleted]
  - okket 10y ago
    You can absolutely use better keys than RSA 1024 for DNSSEC, see http://dnsviz.net/d/sys4.de/dnssec/ http://dnsviz.net/d/sys4.de/dnssec/ It will take a while until everyone has upgraded, but so far no fast attack on RSA 1024 has been reported... Even elliptic curve algorithm based keys are possible now (and recommended because of their small size, which is good for one packet UDP answers, which is not possible with RSA 2048) See ALG13 etc: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec...
    - pfg 10y ago
      Other problems with DNSSEC aside, the crazy thing here is the suggestion to replace the Web PKI with a system that has taken longer to migrate towards safe key sizes than the existing solution. 1024-bit keys for end-entity certificates were deprecated in 2013 and the last 1024-bit roots were pulled in 2014-2015 (ish?). I don't feel like the CA/B Forum is a particularly fast-moving body, so this is pretty telling.
okket 10y ago
You can detect meddling with your DNS easily with appropriate monitoring scripts. Also, what stops governments to fully replace your domain with their own, including valid certs? Your argument is at best one against DNS, not DANE. This is not how the internet works today. It works because we (thankfully) can choose from a lot of top level domains, with very different threat levels. If one goes rogue, choose another one.
- hdhzy 10y ago
  > Also, what stops governments to fully replace your domain with their own, including valid certs? The threat is doing this but only for a small number of people. That could go unnoticed if they could provision certs in the dns. If a CA issues bad cert you see it in CT logs and the CA gets punished.
  - okket 10y ago
    It can only go unnoticed if you do not check your DNS and your certs via monitoring. You should absolutely do this, even if it is just to be sure you didn't mess something up by accident. If a government acting malevolent on a top level domain is detected, alarm bells should ring. Avoid, avoid, avoid. There are enough other TLDs available, with other governments and different threat levels.
    - tptacek 10y ago
      If you truly believe this, then DANE on .COM domains is already a nonstarter, because the DOJ has been compromising the "integrity" of the .COM zone (stipulating that it has any "integrity" to begin with) for many years in the service of various public policy objectives. Which TLD should Google move to, where they'll be safe from this kind of interference? How should they transition? You can't simply redirect from .COM to the new domain.

by hdhzy 10y ago

andrewstuart2 10y ago

I think that would be fairly easy to create rules for, though. Only check at the level where registrars are handing out domains (i.e. trust the most-specific SOA, not counting TLD). In fact, with LetsEncrypt or DV in general, I'm not sure what exists already to stop the scenario you're referring to. My TLD can decide they want certs for my domain and start advertising their nameservers to any IP addresses owned by LetsEncrypt. As it is there's plenty of manual checking that keeps CAs in check. I don't see why the same processes couldn't be applied to such a system.

hdhzy 10y ago
You can check that a new certificate was issued for your domain through Certificate Transparency. Maybe if DANE/TLSA certs would also have be submitted to CT logs and browsers required CT that'd provide stronger security that we have now... Another thing is DNSSEC's reliance on RSA 1024 (did that change?).
- deleted 10y ago
  [deleted]
- okket 10y ago
  You can absolutely use better keys than RSA 1024 for DNSSEC, see http://dnsviz.net/d/sys4.de/dnssec/ http://dnsviz.net/d/sys4.de/dnssec/ It will take a while until everyone has upgraded, but so far no fast attack on RSA 1024 has been reported... Even elliptic curve algorithm based keys are possible now (and recommended because of their small size, which is good for one packet UDP answers, which is not possible with RSA 2048) See ALG13 etc: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec...
  - pfg 10y ago
    Other problems with DNSSEC aside, the crazy thing here is the suggestion to replace the Web PKI with a system that has taken longer to migrate towards safe key sizes than the existing solution. 1024-bit keys for end-entity certificates were deprecated in 2013 and the last 1024-bit roots were pulled in 2014-2015 (ish?). I don't feel like the CA/B Forum is a particularly fast-moving body, so this is pretty telling.

okket 10y ago

You can detect meddling with your DNS easily with appropriate monitoring scripts. Also, what stops governments to fully replace your domain with their own, including valid certs? Your argument is at best one against DNS, not DANE. This is not how the internet works today. It works because we (thankfully) can choose from a lot of top level domains, with very different threat levels. If one goes rogue, choose another one.

hdhzy 10y ago
> Also, what stops governments to fully replace your domain with their own, including valid certs? The threat is doing this but only for a small number of people. That could go unnoticed if they could provision certs in the dns. If a CA issues bad cert you see it in CT logs and the CA gets punished.
- okket 10y ago
  It can only go unnoticed if you do not check your DNS and your certs via monitoring. You should absolutely do this, even if it is just to be sure you didn't mess something up by accident. If a government acting malevolent on a top level domain is detected, alarm bells should ring. Avoid, avoid, avoid. There are enough other TLDs available, with other governments and different threat levels.
  - tptacek 10y ago
    If you truly believe this, then DANE on .COM domains is already a nonstarter, because the DOJ has been compromising the "integrity" of the .COM zone (stipulating that it has any "integrity" to begin with) for many years in the service of various public policy objectives. Which TLD should Google move to, where they'll be safe from this kind of interference? How should they transition? You can't simply redirect from .COM to the new domain.