teor: > >> On 12 Oct 2016, at 09:29, Jesse V <kernelcorn@xxxxxxxxxxxxxx> wrote: >> >> On 10/11/2016 12:53 AM, Jeremy Rand wrote: >>> It's also worth noting that it's been hard enough to get IETF to accept >>> .bit (that effort stalled) -- adding a bunch of other TLD's would >>> probably annoy IETF significantly (and destroy whatever good will exists >>> at IETF right now), and I fully understand why this would annoy them. >>> >>> I'm not really sure what the right mechanism is for a user to specify "I >>> want this request to either use TLS or be resolved to a .onion record" >>> (which seems to be the primary use case here). Does anyone have >>> suggestions? >> >> As I understand it, the spirit of the naming system API is to resolve >> $meaningfulName to $randomAddress.onion. It seems pretty clear its >> focused on A records, but the naming system can support subdomains and >> CNAME records if it likes. My approach with OnioNS is to simply use a >> none-ICANN TLD, which is currently ".tor". There's a Trac ticket on >> which TLD I should use, but it seems most intuitive to use something >> obvious. Someone suggested that we continue to use .onion, but anything >> that isn't 16 chars of base32 should be resolving using the naming >> system. That seems like it would be more confusing. A new TLD seems more >> intuitive. > > Yes, and re-using .onion would make (some) 32-character names invalid, > and post prop-224, (some) 53?-character names invalid as well. > > This is an undesirable property. > > I can also imagine attacks taking advantage of this confusion. If, hypothetically, we wanted to avoid the confusion of "does xyz.bit point to a .onion service or an A record?" but did not want to introduce any additional TLD's, maybe do something like: "xyz.bit.onion" --> the .onion service pointed to by Namecoin d/xyz, or an error if no such service exists "xyz.bit" --> anything pointed to by Namecoin d/xyz, which could be an A record, or a CNAME record, or a .onion record. I suspect that most end users will understand that "bit.onion" is not an onion service, since it's far too short to be one. Thoughts? -Jeremy
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev