> Each CA would have to effectively mirror all of the logs out there, and the logs impose rate limits on queries. It would be interesting also to see what happens when a log gets DDoS'ed (we know OCSP servers aren't useful because of that problem).
Hrrrm. The data in a log is public; the act of logging needs to be done by the log server, but all output (STHes, audit proofs, etc.) is signed, and thus can be mirrored. A log could just push copies of its data elsewhere instead of self-hosting
For this specific use case, I'd imagine that at least some of the logs would be willing to push data to CAs. If we're really worried about this, demanding that logs push data to CAs doesn't seem like an onerous requirement to add to CT. (This starts to resemble MS's Certificate Translucency^WReputation.)
I have no personal investment in CT as the spec exists (I'm just an end-user); if there are realistic changes that would make it more robust I think we should push for them. (Another easy change that would rule out some of the attacks you're worried about is a mandatory 2×MMD delay on certificate issuance, at least for domains that have opted into such a delay, but this seems obvious enough that I assume people have already thought about its pros and cons.)
Naively, distributing log data seems like the same sort of problem as making a blockchain highly available (whether we're talking about Namecoin's, or Bitcoin's, or anyone else's). I'm not well-versed in how blockchains work at the protocol level; does DDoS cause problems there too?
> Are you referring to the connection between clients and DNSChain or a blockchain and its network?
I'm assuming that, in a scenario like the one at hand here (a corporation wanting to MITM all its traffic), the victims are using the attacker's DNS server and are blocked from using any others. That's pretty common, even in places that don't try to MITM your SSL connections; the sort of appliance at issue here can also do things like block known phishing/malware sites, but not try to modify or log your traffic. In a DNSChain world, perhaps that DNS server will speak the DNSChain protocol, but lie about things to the extent that it can (it sounds like it can make arbitrary changes!???). Or if each client runs a DNSChain resolver itself, the attacker will intercept all blockchain traffic and lie about that to the extent it can.
I think I buy that you can notice that the block difficulty is suddenly remaining constant and there's something unusual with that. I'd be worried that a network-wide formal specification would have to account for, say, a good part of the network getting bored and the hash rate actually dropping, causing a worldwide DoS. But intuitively, it seems good enough.
I don't think the UX concerns are particularly different between DNSChain and something more traditional and CT-like, are they? For DNSChain resolvers on a firewalled network, someone needs to relay blockchain activity or the resolver will shut itself down; if you can do that, you can also relay CT log activity (which must be re-signed every MMD), browser updates, CRLset pushes, etc. and maintain liveness.
So, I'm realizing that this whole conversation is somewhat silly because blockchains already provide CT and they do a better job of CT than Google's CT.
If you'd be interested in reading a draft of a blog post on this topic, please shoot me an email (see my profile).
Hrrrm. The data in a log is public; the act of logging needs to be done by the log server, but all output (STHes, audit proofs, etc.) is signed, and thus can be mirrored. A log could just push copies of its data elsewhere instead of self-hosting
For this specific use case, I'd imagine that at least some of the logs would be willing to push data to CAs. If we're really worried about this, demanding that logs push data to CAs doesn't seem like an onerous requirement to add to CT. (This starts to resemble MS's Certificate Translucency^WReputation.)
I have no personal investment in CT as the spec exists (I'm just an end-user); if there are realistic changes that would make it more robust I think we should push for them. (Another easy change that would rule out some of the attacks you're worried about is a mandatory 2×MMD delay on certificate issuance, at least for domains that have opted into such a delay, but this seems obvious enough that I assume people have already thought about its pros and cons.)
Naively, distributing log data seems like the same sort of problem as making a blockchain highly available (whether we're talking about Namecoin's, or Bitcoin's, or anyone else's). I'm not well-versed in how blockchains work at the protocol level; does DDoS cause problems there too?
> Are you referring to the connection between clients and DNSChain or a blockchain and its network?
I'm assuming that, in a scenario like the one at hand here (a corporation wanting to MITM all its traffic), the victims are using the attacker's DNS server and are blocked from using any others. That's pretty common, even in places that don't try to MITM your SSL connections; the sort of appliance at issue here can also do things like block known phishing/malware sites, but not try to modify or log your traffic. In a DNSChain world, perhaps that DNS server will speak the DNSChain protocol, but lie about things to the extent that it can (it sounds like it can make arbitrary changes!???). Or if each client runs a DNSChain resolver itself, the attacker will intercept all blockchain traffic and lie about that to the extent it can.
I think I buy that you can notice that the block difficulty is suddenly remaining constant and there's something unusual with that. I'd be worried that a network-wide formal specification would have to account for, say, a good part of the network getting bored and the hash rate actually dropping, causing a worldwide DoS. But intuitively, it seems good enough.
I don't think the UX concerns are particularly different between DNSChain and something more traditional and CT-like, are they? For DNSChain resolvers on a firewalled network, someone needs to relay blockchain activity or the resolver will shut itself down; if you can do that, you can also relay CT log activity (which must be re-signed every MMD), browser updates, CRLset pushes, etc. and maintain liveness.