tl;dr: Ship it.
On adoption: I agree that we should adopt this document.
On WGLC: I have reviewed this document, and I think it's generally in fine
shape to send to the IESG. I have included a few comments below, but
they're mostly editorial. The only issue of any substance is that I would
prefer some of the SHOULDs be MUSTs, for extra clarity.
Thanks to the WG for the good discussion, and to the chairs for acting with
lightning speed in IETF terms.
--Richard
"""
This information is not meaningful to the Tor
protocol, but can be used in application protocols like HTTP
[RFC7230].
"""
It took me a second to process what this meant. Would the following
phrasing be correct?
"""
Labels beyond the first label under ".onion" are not used by
the Tor routing, so for example, "foo.example.onion" will route
to (and authenticate) the same Tor service as "example.onion".
However, additional labels might be used by application services
to distinguish different sub-services accessible via the same Tor
service. In the case of HTTP, for example, the full name, with
all labels, will be included in the Host header, and can be used
to identify HTTP virual hosts on a common server.
"""
Might not be necessary to clarify this much, but like I said, it wasn't
obvious to me what the sub-label handling would be.
----------
"Note that this draft was preceded by
[I-D.grothoff-iesg-special-use-p2p-names] ..."
This paragraph can probably be deleted in the final version.
----------
"The ".onion" Special-Use TLD" -> "The ".onion" Special-Use Domain Name"
(For consistency with RFC 6761)
----------
"""
... or using a proxy (e.g., SOCKS [RFC1928])
to do so. Applications that do not implement the Tor protocol
SHOULD generate an error upon the use of .onion, and SHOULD NOT
perform a DNS lookup.
"""
It might be worth noting that in the scope of the last sentence,
"Applications" includes proxies. That is, your proxy should n't generate a
DNS request if it gets a .onion request either. I would just add
"(including proxies)" between "protocol" and "SHOULD".
----------
"""
3. Name Resolution APIs and Libraries: Resolvers that implement the
Tor protocol MUST either respond to requests for .onion names by
resolving them (see [tor-rendezvous]) or by responding with
NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN.
"""
This seems a little backward. It seems like the general requirement is
that resolvers MUST either resolve over Tor or return NXDOMAIN. If you
don't support Tor, you just fall in the latter bucket. Don't be afraid to
MUST DNS servers, here or in the subsequent points.
----------
On Wed, May 20, 2015 at 1:12 PM, Tim Wicinski <[email protected]> wrote:
>
> Greetings,
>
> From the outcome of the Interim meeting, and discussion on the list, this
> draft appears to both have strong support and address the problem space of
> RFC 6761. The authors have requested a Call for Adoption. The chairs want
> to move forward with this draft if it has consensus support.
>
> It also seems that the document is relatively mature in terms of what
> people need to know in order to decide whether to support advancing it. As
> we have done with other drafts where a lengthy revision process didn’t seem
> necessary to reach a draft we could advance further, and in consideration
> of the timeliness constraint raised by the authors, the chairs are going to
> combine the adopting of the document with the Working Group Last Call.
>
> 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. In particular, we’ve
> heard reservations expressed about the precedent that might be set by
> advancing this document, and about the level of specification of the TOR
> protocols that we might like to see included in the descriptions of the
> expected “special” treatment of .onion names in the field. So if people
> feel strongly about possible changes, we need to know.
>
> Because of the compression of adoption and WGLC, we're making this a three
> week window. The working group last call will end on Wednesday June 10th,
> 2015.
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
