ietf
[Top] [All Lists]

Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

2015-07-15 16:56:43


On 7/15/15, 13:16, "DNSOP on behalf of Ted Lemon" 
<dnsop-bounces(_at_)ietf(_dot_)org
on behalf of ted(_dot_)lemon(_at_)nominum(_dot_)com> 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
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>