BGP trusting is only a non-issue if you didn't really need to access that resource anyway. Out of the infosec CIA triad, this is still an Availability fail. Your one and only available recourse is... "keep refreshing", hoping that the Gods of Routing will put your request on the right path, which in the case of intentional sabotage would probably be never[1]. Let's emphasize at this point that you don't need MiTM for this, just a rogue ASN somewhere advertising a super-quick route to $ta.rg.e.t. In most cases, that would sinkhole at least the continent. So, IMHO, still broken, even if we will be able to know when it is broken (at some point in the future). Which brings me to DNSSEC/DANE.
TLS can indeed offset its CA burdens onto DANE, when DANE becomes a thing[2] and DNSSEC becomes ubiquitous[3]. We are so far away from that, that even google hasn't bothered with DNSSEC[4]. Considering the enormous infrastructure changes that this requires, we'll hardly be getting our money's worth - still a strict top-down system: IANA/Verisign have the root-root zone/keys. Verisign "owns" .coms (root zone), as well as most (all?) other gTLDs.
TACK is a proposed TLS extension for certificate pinning for the masses. It doesn't solve DNSSEC problems (not its scope), but requires far fewer infrastructure updates to be implemented. It is also not perfect[5] but still a much closer/realistic goal than DANE. We need something yesterday - the green lock icon means fuck-all right now.
And finally:
> I don't think BGP needs to be fixed at all, the underlying problem is inherent to the Internet, changing the protocol will only close one of the several different ways for stealing data.
Strongly disagree. If it does close off one of the ways of stealing data, it definitely needs fixing.
/summon moxie
[1] never -> until Humans intervene to manually block the BS route
[2] DANE Browser support matrix: [ [] ] (2d array, versions on the X axis)
[3] For this to really work for the end client, you need nearly ubiquitous support. The client must be its own recursive nameserver (don't trust your ISP), and all recursive nameservers until the authoritative one need to speak DNSSEC as well (I think). Of course, the g/cc TLD also needs to support DNSSEC (not all do), the owners of the site must have set it up properly, etc. After all that is ubiquitous enough to you enforce DANE for proper TLS ("green icon"), you just need to update all clients everywhere with the new rules. We're currently at step 0.1 of this process - the root zones for most g/cc TLDs are there, and that's about it.
[5] It can only protect your second (and subsequent) visits to the site. If your first time hits a malicious impersonator, you're shit out of luck. Furthermore, the impersonator could "tack" its own malicious certificate for some lols when you actually get to talk to the actual target.com.
TLS can indeed offset its CA burdens onto DANE, when DANE becomes a thing[2] and DNSSEC becomes ubiquitous[3]. We are so far away from that, that even google hasn't bothered with DNSSEC[4]. Considering the enormous infrastructure changes that this requires, we'll hardly be getting our money's worth - still a strict top-down system: IANA/Verisign have the root-root zone/keys. Verisign "owns" .coms (root zone), as well as most (all?) other gTLDs.
TACK is a proposed TLS extension for certificate pinning for the masses. It doesn't solve DNSSEC problems (not its scope), but requires far fewer infrastructure updates to be implemented. It is also not perfect[5] but still a much closer/realistic goal than DANE. We need something yesterday - the green lock icon means fuck-all right now.
And finally:
> I don't think BGP needs to be fixed at all, the underlying problem is inherent to the Internet, changing the protocol will only close one of the several different ways for stealing data.
Strongly disagree. If it does close off one of the ways of stealing data, it definitely needs fixing.
[1] never -> until Humans intervene to manually block the BS route[2] DANE Browser support matrix: [ [] ] (2d array, versions on the X axis)
[3] For this to really work for the end client, you need nearly ubiquitous support. The client must be its own recursive nameserver (don't trust your ISP), and all recursive nameservers until the authoritative one need to speak DNSSEC as well (I think). Of course, the g/cc TLD also needs to support DNSSEC (not all do), the owners of the site must have set it up properly, etc. After all that is ubiquitous enough to you enforce DANE for proper TLS ("green icon"), you just need to update all clients everywhere with the new rules. We're currently at step 0.1 of this process - the root zones for most g/cc TLDs are there, and that's about it.
[4a] http://dnsviz.net/d/google.com/dnssec/
[4b] http://dnsviz.net/d/whitehouse.gov/dnssec/ (for comparison)
[4c] http://www.dnssec-name-and-shame.com/ (NOISY site - be warned) Test out a few top alexa sites. You'll be surprised.
[5] It can only protect your second (and subsequent) visits to the site. If your first time hits a malicious impersonator, you're shit out of luck. Furthermore, the impersonator could "tack" its own malicious certificate for some lols when you actually get to talk to the actual target.com.