▲ | tptacek 3 days ago | ||||||||||||||||||||||||||||||||||||||||||||||
Get one to issue a Google.com certificate and see what happens. | |||||||||||||||||||||||||||||||||||||||||||||||
▲ | xorcist 2 days ago | parent | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||
This is a bad faith argument. Whatever measures Google takes to prevent this (certificate logs and key pinning) could just as well be utilized if registrars delegated cryptographic trust as they delegate domains. It is also true that these contemporary prevention methods only help the largest companies which can afford to do things like distributing key material with end user software. It does not help you and me (unless you have outsourced your security to Google already, in which case there is the obvious second hand benefit). Registrars could absolutely help a much wider use of these preventions. There is no technical reason we don't have this, but this is one area where the interest of largest companies with huge influence over standards and security companies with important agencies as customers all align, so the status quo is very slow to change. If you squint you can see traces of this discussion all the way from IPng to TLS extensions, but right now there is no momentum for change. | |||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||
▲ | throwaway2037 3 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||
This is a great point. For all of the "technically correct" arguments going on here, this one is the most practical counterpoint. Yes, in theory, Verisign (now Symantec) could issue some insane wildcard Google.com cert and send the public-private key pair to you personally. In practice, this would never happen, because it is a corporation with rules and security policies that forbid it. Thinking deeper about it: Verisign (now Symantec) must have some insanely good security, because every black hat nation state actor would love to break into on their cert issuance servers and export a bunch of legit signed certs to run man-in-the-middle attacks against major email providers. (I'm pretty sure this already happened in Netherlands.) | |||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||
▲ | ysleepy 2 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||
That only works for high profile domains, a CA can just issue a cert, log it to CT and if asked claim they got some DNS response from the authoritative server. Then it's a he said she said problem. Or is DNSSEC required for DV issuance? If it is, then we already rely on a trustworthy TLD. I'm not saying there isn't some benefit in the implicit key mgmt oversight of CAs, but as an alternative to DV certs, just putting a pubkey in dnssec seems like a low effort win. It's been a long time since I've done much of this though, so take my gut feeling with a grain of salt. | |||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||
▲ | Ajedi32 2 days ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||||||||||||||
Right. 'You can't "distrust" .com.' is probably not true in that situation. (If it were actually true, then "what happens" would be absolutely nothing.) I think you're undermining your own point. |