3 ms·

> I'm sorry, I'm a little lost at "the solution to governments having captured individual CAs is to add a set of new CAs that they control directly and that can

by zeveb 10y ago

> I'm sorry, I'm a little lost at "the solution to governments having captured individual CAs is to add a set of new CAs that they control directly and that can't be revoked because they're tied to the DNS". That's because it's not a solution. There isn't a non-political solution. By making it explicit rather than implicit one is forced to confront the truth, and be honest about it. .com is owned by the United States; .ru is owned by Russia; .ly is owned by Libya; .io is owned by the United Kingdom. If we got rid of non-DNS CAs (for host-verification purposes, anyway), it would, however, mean that only the U.S. may legally suborn .com, .org &c.; that only Russia may suborn *.ru, and so forth. That's a pretty big win over the present situation, in which every government who can lay its hands on a CA employee can get a certificate for any site in the world.

tptacek 10y ago
People keep saying this in response to ".COM is owned by the USG no matter what" and it's not true. The USG's ownership of .COM does not in fact enable them to intercept Google Mail requests. The reason it doesn't is that if you get a CA to issue a bogus Google Mail request for surveillance purposes, Google will put your CA out of business. Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action. It used to be they only did this for non-Google properties if you asked them nicely. But now there's a protocol that automates it, called HPKP. HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer. This helps everybody, not just the people running Chrome. IE doesn't support HPKP. But every single person running Chrome is participating in a certificate surveillance system that will light up if someone makes the mistake of feeding them a bogus cert. Google is also getting the ball rolling on Certificate Transparency, which directly monitors all certificate issuances from participating CAs. Browser vendors have shown a willingness to force CAs to participate if they make any mistakes at all. This is a problem that is in the process of being solved. DNSSEC is a MONUMENTAL STEP BACKWARDS. Thankfully, it isn't going to happen, but we can make that not-happening even clearer and faster by noticing when people talk positively about DNSSEC and then challenging them.
- garaetjjte 10y ago
  Deploying DANA doesn't mean that we can't use HPKP. It is independent solution. > Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action. And this situation won't change with DANA. > HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer. If they control DNS for domain, they can change MX records for verification and buy certificate in any legitimate CA.
  - tptacek 10y ago
    DANE does harm HPKP. Part of the point of HPKP is that when pins are broken, browsers can punish CAs. You can't punish the TLDs that way. HPKP assumes agility. DANE removes agility. Equally importantly: DANE doesn't actually solve any problem we have today. HPKP does. Why would you spend a penny, let alone tens of millions of dollars, to deploy something that is a step backwards for our security? What's the point? Regarding MX records: I think you need to re-read the post, its FAQ, or the comments on this thread, because it's been addressed ad nauseam.
    - garaetjjte 10y ago
      With DANE there will be no CAs, so yes, there will be no CAs to punish. But owners of root zone can already change DNS records to buy certificate in any CA, and you cannot punish them for that because they aren't required to do any validation above checking DNS records for non-EV certs. In worst case DANE is equally secure as current CA system (ok, except that weak RSA, but I hope it will be fixed soon). Why you want to keep CAs, when you have to waste resources on constantly monitoring and punishing them, while with DNSSEC you can ditch them? In both systems DNS root zones owners can buy/generate certificates for child zones. This was also addressed ad nauseam.
      - 10y ago

by zeveb 10y ago

tptacek 10y ago

People keep saying this in response to ".COM is owned by the USG no matter what" and it's not true. The USG's ownership of .COM does not in fact enable them to intercept Google Mail requests. The reason it doesn't is that if you get a CA to issue a bogus Google Mail request for surveillance purposes, Google will put your CA out of business. Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action. It used to be they only did this for non-Google properties if you asked them nicely. But now there's a protocol that automates it, called HPKP. HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer. This helps everybody, not just the people running Chrome. IE doesn't support HPKP. But every single person running Chrome is participating in a certificate surveillance system that will light up if someone makes the mistake of feeding them a bogus cert. Google is also getting the ball rolling on Certificate Transparency, which directly monitors all certificate issuances from participating CAs. Browser vendors have shown a willingness to force CAs to participate if they make any mistakes at all. This is a problem that is in the process of being solved. DNSSEC is a MONUMENTAL STEP BACKWARDS. Thankfully, it isn't going to happen, but we can make that not-happening even clearer and faster by noticing when people talk positively about DNSSEC and then challenging them.

garaetjjte 10y ago
Deploying DANA doesn't mean that we can't use HPKP. It is independent solution. > Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action. And this situation won't change with DANA. > HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer. If they control DNS for domain, they can change MX records for verification and buy certificate in any legitimate CA.
- tptacek 10y ago
  DANE does harm HPKP. Part of the point of HPKP is that when pins are broken, browsers can punish CAs. You can't punish the TLDs that way. HPKP assumes agility. DANE removes agility. Equally importantly: DANE doesn't actually solve any problem we have today. HPKP does. Why would you spend a penny, let alone tens of millions of dollars, to deploy something that is a step backwards for our security? What's the point? Regarding MX records: I think you need to re-read the post, its FAQ, or the comments on this thread, because it's been addressed ad nauseam.
  - garaetjjte 10y ago
    With DANE there will be no CAs, so yes, there will be no CAs to punish. But owners of root zone can already change DNS records to buy certificate in any CA, and you cannot punish them for that because they aren't required to do any validation above checking DNS records for non-EV certs. In worst case DANE is equally secure as current CA system (ok, except that weak RSA, but I hope it will be fixed soon). Why you want to keep CAs, when you have to waste resources on constantly monitoring and punishing them, while with DNSSEC you can ditch them? In both systems DNS root zones owners can buy/generate certificates for child zones. This was also addressed ad nauseam.
    - 10y ago