On 7/15/15, 13:16, "DNSOP on behalf of Ted Lemon" <dnsop-bounces@xxxxxxxx on behalf of ted.lemon@xxxxxxxxxxx> wrote: >On 07/15/2015 05:42 AM, Edward Lewis wrote: > >No, it's not independent, because .onion sites won't be able to get PKI >certs if we don't do the allocation. That's what I meant by "(to some extent)". If not being able to get the certs kills Tor, then failing to get some special designation would be a show stopper. But that isn't in the document (and you'll see I keep coming back to the document's content). >We discussed this at length in the working group The discussion in the WG is not reflected in the document. >It is clearly understood that TOR is effectively an SDO >that has defined a standard using their own system of publication and >their own standardization methodology, which is different than the >IETF's methodology for very good reasons. Requiring another SDO to >follow IETF process in order to get an allocation of this type doesn't >make sense and isn't required by the governing standard. Until I read this, I wasn't aware that Tor (TOR?) was even an organized thing. I don't follow what you mean by requiring another "standards development organization" to follow the IETF process. I thought that for Tor to get certificates from CA/B forum members there was a need to have "onion" be a specially designated identifier and that the IETF's Special Use Domain Names registry seems like an apt approach. >Are you claiming that there is not widespread deployment of TOR? There >was no controversy in the working group on this question: nobody there >claimed that TOR wasn't sufficiently widely deployed to justify >allocation. To answer your question, no. I'm not making a claim about its deployment. OTOH, I have never seen any first hand evidence of it (I do live in a cave perhaps). None of my friends, family, etc., seem to know about and so on. But that doesn't matter - the document, as it stands, does not give any indication that there is a widespread deployment of it. I.e., I'm challenging the document preparers to include text that gives some estimation of the scale of deployment. Document it. >I think this is a reasonable position to take, with one exception. I >think it's fine for the document to make recommendations about what name >servers and the root should do, but it's not our place to make >requirements, nor do I think it's necessary. However, it would be very >beneficial for host implementations to special case .onion, as some >hosts do for .local now. When hosts fail to apply appropriate special >case handling for .local, it creates operational annoyances, to no >benefit. In the case of .onion, it creates a privacy problem. So I >don't mind this text as much as you do, but I do wonder if we'll >actually see widespread implementation of such requirements. I didn't see the exception you had in mind. From what little I apparently understand about Tor/onion, applications need to behave in a way that enhances privacy and it would be cool if DNS servers weren't configured to return conflicting data. The DNS protocol doesn't need to be changed, much like .local isn't special to a general purpose DNS server despite behaving in a certain fashion in a host. >>Ed: I'm agreeing with Ted in that this application is insufficient. > >Whoa there, cowboy! I didn't say it was insufficient. http://www.ietf.org/mail-archive/web/ietf/current/msg93849.html That "Ted". >And also, please don't call it an application. It is an internet >draft, which has passed working group last call, and is in IETF last >call. An application would be something that would be handled by the >IESG, through the instrumentality of the IANA. Ted called it a "request." (Just sayin'.) Keep in mind - I'm saying the document, the internet-draft, doesn't contain all that it could or should to be a convincing use case. Perhaps it ticked off all the check boxes of RFC 6761, but I think it lacks what it needs to be convincing as well as stand the test of time.
<<attachment: smime.p7s>>