kensey
Joined 9 years ago
Joined 9 years ago
I would expect ICANN to use that power very sparingly, preferring to publicize rather than act as a first step, and if they did get heavy-handed, again they would incur a hit to their legitimacy.
The only reason it's considered unthinkable that could happen to .com is that everybody agrees it's unthinkable to do that to .com. But ICANN absolutely could make a credible threat to US control of .com or .us if they felt it warranted to do so. (You could say they're ICANN, not ICANN'T.) They could do the same to .gov, for that matter, but the US government already explicitly owns and controls that whole hierarchy, so there's no real "interference" issue there.
The whole Internet's viability is based to some extent on the collective delusion that everybody agreeing this is how it works, actually makes it how it works. But none of that is set in stone... which is generally a good thing.
There used to be a pinning scheme called HPKP, but the trouble with it is it's very easy to accidentally (or via malicious third-party action) end up in a situation where your web site becomes unreachable by people who've visited it previously because the key changed and the pin prevents their browser recognizing the new key as valid:
Which is exactly the kind of scenario a lot of people hyperventilated about back when ICANN was formed, for reasons of varying validity, but in this case it would indeed be the least-worst option all around.
Of course we wouldn't want ICANN to do that on a whim, or without having a new operator for the TLD ready to go, but there's already process defined for both planned and emergency transfers of operation of a TLD:
https://www.icann.org/en/contracted-parties/registry-operato...
More to the point I would trust IANA and ICANN, faults and all, to not screw up the DNS/DNSSEC root, much more than I trust every CA in the default browser trust stores to get X.509 right all day, every day.
There are a lot of reassuring statements from browser makers and others about how their mitigations for exactly this scenario kicked in and protected (some set of) Internet users, but IMHO there is not nearly enough discussion happening about fixing things so those mitigations are not needed to begin with.
The reason we don't have DANE support in browsers is of course because Google decided not to implement it in Chrome, because (ultimately) the key lengths securing the root DNS server zones weren't large enough to suit them (at the time, 1024 bits):
https://www.imperialviolet.org/2015/01/17/notdane.html
And if Google wasn't going to do it, it didn't make sense for any other browser to do it either.
However, I believe the root zone keys are now longer, so I could (potentially) see Google implementing DANE in Chrome now, maybe with a Chrome-specific restriction of "TLSA records that have keys under 2048 bits in their chain of trust are ignored" (since the root zone keys are not the only keys in the chain and they want to eliminate 1024-bit RSA from Chrome). And if Google does it in Chrome, then everybody else has to do it too, so the situation flips.
No they aren't. They're statistical token generators. They do not understand concepts such as "distance from a given location or coordinate point". If you're lucky you might ask it something likely to appear nearly verbatim in its training data, like "Chinese restaurants in Midtown Manhattan", and get back a reasonably accurate list, but it does not understand what a "Chinese restaurant" is, or what "Midtown Manhattan" is, or that one relates to the other in any way other than both appearing statistically associated with another set of tokens when they appear near each other.
But let's whiteboard for a bit: if you agree (as I assume you do) that the current situation is at least more insecure than it should be, and should ideally change fundamentally, and if you don't think DANE is the right fundamental change, what would you implement instead if you had the magic wand to make everyone agree to do it?