Hi Warren, Just finished reading the draft (for ALT), but still think this is not going to help.
The statement: They SHOULD choose a label that they expect to be unique and, ideally, descriptive. Is something that in reality won’t happen, and we will be back to square one. “foo.ALT” is going to be very popular and without a registry to control the namespace you’ll end up in a situation where more than one application will attempt to connect to the wrong server (names collision problem). Nowadays there are a lot of options for registering a domain name, in my opinion the best practice should be to register a domain name and build on top of it. The concept of an application that does not need to be connected to the Internet is going to be hard to maintain, specially in a world where we have IPv6 and other P2P technologies. Applications MUST NOT rely on DNS names to authenticate themselves, that is, must never send credentials to a server without validating its identity. I think that’s where the effort should go, DNSSEC, DANE, etc. not on trying to prevent people from doing stupid things, it’s not going to work and it’s going to move us away from the real goal, creating an illusion that we’ve solved a problem. Regards, > On May 20, 2015, at 4:27 PM, Warren Kumari <war...@kumari.net> wrote: > > On Wed, May 20, 2015 at 1:55 PM, Joe Abley <jab...@hopcount.ca > <mailto:jab...@hopcount.ca>> wrote: >> On 20 May 2015, at 13:12, Tim Wicinski wrote: >> >>> The draft can be found here: >>> >>> https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/ >>> >>> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 >>> >>> Please review the draft and offer relevant comments. >> >> >> I have read this document. I support it's adoption by the working group. I >> am willing to review future revisions of the draft, and to contribute text >> if that seems useful. >> >> The document uses the phrase "top-level domain" all over the place to >> describe .onion. That phrase to me seems indelibly linked to its meaning in >> the context of the DNS; in the case of Tor, however, we're not talking about >> the DNS at all, but rather the use of a completely separate namespace that >> just happens to be syntactically equivalent to DNS names. >> >> The purpose of the document should not be to create a top-level domain in >> the usual/DNS sense; rather it's to prevent such a top-level domain (i.e. a >> delegation from the root zone for the owner name "onion") from ever >> existing, since that would make things confusing for applications. >> >> I support the idea that the running code evident in the tor network should >> properly trump any process or policy that would otherwise make it difficult >> to make the DNS-specific recommendations on resolvers and the root zone >> encapsulated here. I just think the different contexts should be more >> clearly delineated. >> >> I would also support (as I have heard others say before, and as I think I >> have also said) a separate document that provides advice to anybody else >> planning to deploy code that uses a DNS-like namespace that is not the DNS. > > [ Warning! Sales pitch below :-) ] > > See https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 > <https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06> - > Section 4 - Advice to developers. > >> Such people should either make their names unambiguously different from >> those used in the DNS, or should anchor them somewhere else in the namespace >> where defensive registrations in the DNS are less contentious. For example, >> if the Tor project had used "onion.eff.org <http://onion.eff.org/>" instead >> of "onion", we would not >> be having this conversation. > > This is also in > https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 > <https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06> - Section 4 > - Advice to developers. > >> Making such guidance available would make it >> far easier to deal with the future possibility that a decision with "onion" >> would set an unfortunate precedent. > > Yup, .onion could be seen as a precedent -- but, if we have .alt we > can say "Now there is a known place to do these sorts of things (there > wasn't when .onion started), you should have used that..." :-) > >> >> Note that I am definitively not criticising the Tor project for their >> choices back at a time when there was no such guidance available. > > Me neither -- I think .onion is a no brainer. It meets all the > requirements, and is widely used.... but, providing guidance and a > safe place to experiment in the future seems very valuable. > >> I think >> they are all to be congratulated for causing us this headache, since at its >> core that headache is a symptom of their success of enhancing the privacy >> and freedom of everybody who uses their software. > > Yah. I'm not sure I'd congratulate them for causing a headache, but > definitely congratulations and thanks for a valuable product... > >> >> >> Joe >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >> https://www.ietf.org/mailman/listinfo/dnsop >> <https://www.ietf.org/mailman/listinfo/dnsop> > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > <https://www.ietf.org/mailman/listinfo/dnsop> Francisco Obispo CTO - Registry Operations ____________________________ <http://www.uniregistry.com/> 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x4202 fobi...@uniregistry.link
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
