David Fifield:
So here, the browser thinks it is connecting to debian.zkey (the URL bar says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion in the background. What name does the browser put in its Host header? It can't be the onion name, because there's no feedback from the naming module back to the user application layer. It must be "debian.zkey" then. If that is a petname, then it just got leaked to the server. I can imagine this might also cause a problem with some virtual hosting setups (though I suppose those are not very common for onion services). If the user uses HTTPS, e.g. https://facebook.zkey/, then they'll get a TLS name mismatch error, even if https://facebookcorewwwi.onion/ exists and has a valid certificate--so using the naming system is not a transparent replacement for memorizing the onion address. Maybe non-HTTP protocols will also have problems.
In Namecoin's case, that's working as intended: if Facebook sets up a Namecoin domain name, then they should create a TLS certificate with their .bit domain on the SAN list, that TLS certificate should be listed in their Namecoin name as a TLSA record, and it should be served when the SNI header asks for the .bit domain. It's unclear to me whether that is problematic for other naming systems. It's also unclear to me whether this will be problematic if Facebook wants to get an EV CA-issued cert to cover their .bit domain name, due to the political issues around the P2P names proposal at IETF.
I'm aware that Alec Muffett isn't at Facebook anymore, but perhaps he would be able to offer feedback on what issues might be likely to come up here?
Cheers, -Jeremy