On 3/3/14, 9:25 AM, Norbert Bollow wrote: > Warren makes a strong argument in favor of .alt I think.
yeah... anything that has the potential to result in additional leakage seems like a recipe for additional pain. > Another related aspect is that if something like onion.notreallydns.org > is used, with notreallydns.org registered for the specific purpose of > providing a home for one or more non-resolving dns-like names, it > is very non-trivial to guarantee that whoever has registered the > notreallydns.org name will continue paying the yearly fees forever. If > the registration lapses, an attacker could become the new holder of the > notreallydns.org domain and use it to snoop and/or serve malware... > > Greetings, > Norbert > > > Am Sun, 2 Mar 2014 22:20:48 +0000 > schrieb Warren Kumari <war...@kumari.net>: > >> On Wed, Feb 26, 2014 at 2:34 PM, Joe Abley <jab...@hopcount.ca> wrote: >>> >>> On 26 Feb 2014, at 5:03, Mark Andrews <ma...@isc.org> wrote: >>> >>>> In message <d0ac0015-63c3-4c03-a8d0-888c435d2...@virtualized.org>, >>>> David Conrad writes: >>>> >>>>> On Feb 25, 2014, at 9:51 AM, Stuart Cheshire <chesh...@apple.com> >>>>> wrote: >>>>>> If we have *some* pseudo-TLDs reserved for local-use names, >>>>> >>>>> I would think = >>>>> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_element= >>>>> s would be appropriate for this purpose. >>>>> >>>>> Regards, >>>>> -drc >>>> >>>> Whatever is used needs to be insecurely delegated so that in app >>>> validation will work. >>> >>> I still don't see why we need a TLD, or a delegation/reservation >>> under ARPA. >>> >>> There are many, many TLDs under which an application/protocol >>> implementer can reserve some namespace for their exclusive use at >>> low cost ($10/year, say). Why is this approach not preferred for a >>> new application/protocol? It seems far simpler. >> >> Yes, and it is -- but it means that leakages hit more folk. >> >>> >>> Perhaps all that is missing is some guidance that says "you >>> shouldn't hijack namespaces that you don't control, even for >>> non-DNS applications; register a domain instead". >> >> Because for some things, people specifically do *not* want it to hit / >> go through the DNS -- this is why they have done this, and *not* just >> registered e.g onion.com... >> >> For example, I'm a *huge* Justin Beiber fan. I, and a bunch of my >> fellow closet Bieberites hang out on the-bieb-is-cool.onion. (you >> don't really think we want everyone to know that we obsess over every >> little antic, do you?) >> >> Last week I emailed my friend a link to >> http://www.the-bieb-is-cool.onion/Justins_New_Shoes.html. >> Unfortunately, he was just *so* excited to see that the Bieb has new >> sneakers that he clicked on the link from his phone (which doesn't >> have the ToR interceptor software installed). This, of course, means >> that the "DNS like" name, which should not really be used in a DNS >> context suddenly hit the DNS. Only his recursive and the root saw >> this, and that's embarrassing enough, thank you. >> >> This is bad enough, but if people built stuff like this under >> .onion.eff.org (or foo.onion.arpa), there would now be many more >> people in the list who knew our shameful little secret. >> >> Obviously this is a somewhat contrived example (after all, who >> wouldn't want to make it widely known that they *love* Justin >> Bieber!), but lets instead pretend I'm using an overlay network as a >> political dissident, or to discuss my sexual orientation, or... >> >> This is some of the justification behind the .ALT TLD proposal >> (http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00) -- create >> a special label to be used to denote that this is not actually a name >> in the DNS context. By reserving it as a special use name: >> A: It creates a "safe" namespace, secure from collision for people to >> root namespaces that have no meaning in a DNS context. >> B: when one of these names *does* leak (as they will), iterative >> resolvers will be authoritative, with an empty zone, so >> the-bieb-is-cool.onion.alt only gets seen by the iterative and goes no >> further. >> C: When one does go further (as they will), the root can delegate to >> AS112, while can squash it. >> D: 4 years from now, when someone comes along and says "I created a >> shiny new directory system. I used something that looks like DNS >> names, and I placed it under .pony. Please reserve that for me" the >> IESG can at least say "But we told you not to do that..." They can >> also a: reserve it, b: not, or c: we can have another thread about >> this all again, but now at least we can nod knowingly and feel all >> superior... >> >> W >> P.S: Note: I did *not* say what should happen with the current >> pseudo-TLDs / colliding names. They can move under .ALT or they can >> not. The IESG can reserve them, or not, or bury them in peat, or paint >> them purple and dress them in wellies. I have views on what I think >> makes sense, but that's a separate mail..... >> >> >> >> >> >> >> >>> >>> Joe >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dn >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
