2 ms·

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 compl

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.

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.