4 ms·

Certficate transparency helps to mitigate that by creating a public audit log of certificate issuance.

xorcist 9y ago
That depends entirely on best practice among CAs, something we've seen multiple CAs bend the rules on. Any one is enough to make the attack undetected. An attack against the global public DNSSEC would be much harder to mount undetected, as it is logged and cached by nature of its design.
- tptacek 9y ago
  People say this constantly, as if attacks against DNSSEC would require intelligence services to alter the DNS across the entire Internet. But of course, that's not how states attack Internet connections and never has been: they subvert ISPs (which are often stated-owned, and almost invariably state-controlled) and pinpoint individual connections to manipulate. There's a hundred million dollar business of tools to facilitate this. It's not one of my best arguments against DNSSEC, but it is a valid one: the fact that the people designing and advocating for it don't appear to understand the Internet threat model.
  - xorcist 9y ago
    No one has made that statement. I pointed out that DNS by nature is cached and distributed. Not that it's impossible to manipulate, but that it in every circumstance is not worse than a TLS intercept, and in some cases less bad. DNSSEC did make one important design decision: Signing is offline. That alone makes the threat model different than with TLS, and makes for some interesting use cases.
    - tptacek 9y ago
      Signing was offline, until everyone realized that offline-signing was unworkable. Now it's a bastardized version of both online and offline signing, with an insane NSEC3-whitelies system of distributed password hashes and fake zone entries that is de facto BCP for real-world deployment. I don't know how pure offline signing would have made anything better for DNSSEC (I think it makes a lot of things about it worse), but let's at least be clear that the offline signing design failed. You didn't really address what I said. My argument, which I think is pretty straightforward, is that it is not in fact harder to carry out pinpoint attacks on DNSSEC than it is to do so on TLS. In fact: it's easier; in many ways, modern browsers act as hundreds of millions of sensors in a distributed CA surveillance system, one that has gotten multiple CAs killed. No DNS software works that way.
      - xorcist 9y ago
        Your experience is different from mine then. I have seen a few real world deployments and they are all either completely offline signed or with the signer completely hidden. Are we talking about the public CA system or TLS in general? The former should be fairly obvious that it is useless in the hards of end users, as Google even had to hard code policy for their own services in their client. The latter argument would depend on what type of attack we're discussing. A wide public attack where you have "hundreds of millions" of clients affected would be impractical to keep undetected in any system. Manipulating a single connection with stolen keys is likely to stay undetected in any case, but where having the information cached at least is a possibility.
        tptacek 9y ago
        You've lost me. Somehow, you claimed, DNSSEC's offline signing design had something to do with how hard it was to conduct pinpoint attacks against DNSSEC. No, that's not true. But also: DNSSEC isn't an offline-signing system anymore: the BCP mode of deployment requires online signing; otherwise, dumping all the hosts in a zone is about as hard as cracking a 1990s password file. You've seen zones where not even that level of protection is employed. Ok? What does that have to do with whether it's easy to launch pinpoint attacks against DNSSEC? Oh, but pinpoint attacks are possible against TLS. Yes? And? The premise of this subthread is your (false) claim that it's not straightforward to do that against DNSSEC too. Again: not only is it straightforward to do that, but it's actually easier, because, once again, no end-user DNS resolver also functions as security telemetry surveilling the DNS PKI, unlike the Web PKI where that is in fact the case.
        xorcist 9y ago
        You stated as fact that DNSSEC was badly designed, specifically because its designers do not understand the Internet threat model. I pointed out that the design for offline signing makes for interesting use cases. You now claim that every real world deployment is online signed, which is not my experience. At least you acknowledge real world deployments. That has nothing to do with the complexity of pinpointing a connection to break, and nowhere did I make the claim that any attacks are straightforward. I did make the point that it is not easier and that it may very well be more complex. Pinpointing a TLS stream and inserting a false certificate is trivial if you posess a valid CA key, pinpointing the DNS query corresponding to a specific TLS stream is an added complexity (especially where multiple resolvers can be involved, where you also run the risk of being stuck in a cache). I'm not sure what kind of TLS stack ever delivered telemetry on valid signatures post facto, unless you refer to web browsers on the public Internet which is a different question entirely.
- jacobparker 9y ago
  That's not true. 1) Anyone can submit a certificate to the CT logs 2) It will become mandatory that certificates are logged for Chrome to trust them in a matter of weeks (other browsers will follow): https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...

That depends entirely on best practice among CAs, something we've seen multiple CAs bend the rules on. Any one is enough to make the attack undetected. An attack against the global public DNSSEC would be much harder to mount undetected, as it is logged and cached by nature of its design.

tptacek 9y ago
People say this constantly, as if attacks against DNSSEC would require intelligence services to alter the DNS across the entire Internet. But of course, that's not how states attack Internet connections and never has been: they subvert ISPs (which are often stated-owned, and almost invariably state-controlled) and pinpoint individual connections to manipulate. There's a hundred million dollar business of tools to facilitate this. It's not one of my best arguments against DNSSEC, but it is a valid one: the fact that the people designing and advocating for it don't appear to understand the Internet threat model.
- xorcist 9y ago
  No one has made that statement. I pointed out that DNS by nature is cached and distributed. Not that it's impossible to manipulate, but that it in every circumstance is not worse than a TLS intercept, and in some cases less bad. DNSSEC did make one important design decision: Signing is offline. That alone makes the threat model different than with TLS, and makes for some interesting use cases.
  - tptacek 9y ago
    Signing was offline, until everyone realized that offline-signing was unworkable. Now it's a bastardized version of both online and offline signing, with an insane NSEC3-whitelies system of distributed password hashes and fake zone entries that is de facto BCP for real-world deployment. I don't know how pure offline signing would have made anything better for DNSSEC (I think it makes a lot of things about it worse), but let's at least be clear that the offline signing design failed. You didn't really address what I said. My argument, which I think is pretty straightforward, is that it is not in fact harder to carry out pinpoint attacks on DNSSEC than it is to do so on TLS. In fact: it's easier; in many ways, modern browsers act as hundreds of millions of sensors in a distributed CA surveillance system, one that has gotten multiple CAs killed. No DNS software works that way.
    - xorcist 9y ago
      Your experience is different from mine then. I have seen a few real world deployments and they are all either completely offline signed or with the signer completely hidden. Are we talking about the public CA system or TLS in general? The former should be fairly obvious that it is useless in the hards of end users, as Google even had to hard code policy for their own services in their client. The latter argument would depend on what type of attack we're discussing. A wide public attack where you have "hundreds of millions" of clients affected would be impractical to keep undetected in any system. Manipulating a single connection with stolen keys is likely to stay undetected in any case, but where having the information cached at least is a possibility.
      - tptacek 9y ago
        You've lost me. Somehow, you claimed, DNSSEC's offline signing design had something to do with how hard it was to conduct pinpoint attacks against DNSSEC. No, that's not true. But also: DNSSEC isn't an offline-signing system anymore: the BCP mode of deployment requires online signing; otherwise, dumping all the hosts in a zone is about as hard as cracking a 1990s password file. You've seen zones where not even that level of protection is employed. Ok? What does that have to do with whether it's easy to launch pinpoint attacks against DNSSEC? Oh, but pinpoint attacks are possible against TLS. Yes? And? The premise of this subthread is your (false) claim that it's not straightforward to do that against DNSSEC too. Again: not only is it straightforward to do that, but it's actually easier, because, once again, no end-user DNS resolver also functions as security telemetry surveilling the DNS PKI, unlike the Web PKI where that is in fact the case.
        xorcist 9y ago
        You stated as fact that DNSSEC was badly designed, specifically because its designers do not understand the Internet threat model. I pointed out that the design for offline signing makes for interesting use cases. You now claim that every real world deployment is online signed, which is not my experience. At least you acknowledge real world deployments. That has nothing to do with the complexity of pinpointing a connection to break, and nowhere did I make the claim that any attacks are straightforward. I did make the point that it is not easier and that it may very well be more complex. Pinpointing a TLS stream and inserting a false certificate is trivial if you posess a valid CA key, pinpointing the DNS query corresponding to a specific TLS stream is an added complexity (especially where multiple resolvers can be involved, where you also run the risk of being stuck in a cache). I'm not sure what kind of TLS stack ever delivered telemetry on valid signatures post facto, unless you refer to web browsers on the public Internet which is a different question entirely.
jacobparker 9y ago
That's not true. 1) Anyone can submit a certificate to the CT logs 2) It will become mandatory that certificates are logged for Chrome to trust them in a matter of weeks (other browsers will follow): https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...