Subject: [DNSOP] I-D Action: draft-ietf-dnsop-onion-tld-00.txt

From: [email-masked]
Date: Sat, 20 Jun 2015 11:12:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : The .onion Special-Use Domain Name
        Authors         : Jacob Appelbaum
                          Alec Muffett
	Filename        : draft-ietf-dnsop-onion-tld-00.txt
	Pages           : 6
	Date            : 2015-06-20

Abstract:
   This document registers the ".onion" Special-Use Domain Name.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-onion-tld-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: hellekin <[email-masked]>
Date: Sun, 21 Jun 2015 09:22:01 -0300

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/
*** 2.3 has a repeat "either".

2.6 reads correctly, but the more important reason IMO is the risk of
privacy leak for the user.  Similarly, the Security Considerations
mention "leak the identity of the service that the user is attempting to
access", which is grammatically correct but does not pinpoint that the
user's privacy is the center of interest.  Specifically, in 2.6,
"leaking" the requested .onion to an authoritative DNS server that would
implement NXDOMAIN usurpation could as well leak this information to
third-parties (e.g., through beacons injected in the response).

I'm still uncertain about 2.1: it's a remark that's already contained in
the Security Considerations, and the technical requirement for humans is
actually mentioned in the introduction: "Such addresses can be used as
other domain names would be (e.g., in URLs [RFC3986])"

In the Security Considerations, another point can be added to the
"compromise list": "The .onion service address the user requests is sent
to the DNS (which is what this document addresses)."  It is different
from "The access protocol is implemented or deployed incorrectly": e.g.,
Web browsers using DNS-pre-fetching for non-DNS strings.

Otherwise this draft addresses my previous concerns, except for the fact
it reserves .onion and not .onion AND .exit, which is still debatable.

It's a very nice, consistent update from the previous draft.  I'd
appreciate an explicit mention of the user's privacy somewhere.

Thank you for your attention,

==
hk

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 22 Jun 2015 15:21:10 -0400

On 6/21/15 8:22 AM, hellekin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

That's a good catch. I'll get the authors to fix up.

> third-parties (e.g., through beacons injected in the response).

While I understand why you feel 2.6 should contain information about 
user's privacy, it currently seems to meet the requirements for [RFC6761].

> Web browsers using DNS-pre-fetching for non-DNS strings.

I'll let the authors answer that.

> it reserves .onion and not .onion AND .exit, which is still debatable.

Thanks.  The consensus that came from the interim meeting is that each 
name should have their own draft, so they can be debated on their 
merits. This was what I sensed, and I may be incorrect.

> Thank you for your attention,

tim

---

From: hellekin <[email-masked]>
Date: Mon, 22 Jun 2015 21:42:29 -0300

> user's privacy, it currently seems to meet the requirements for
*** I consider important that readers keep the primary motivation why
such reservations are made in the first place.  Even if it's technically
sufficient to match the requirements of RFC6761, readers years from now
might not remember how important privacy still was in our time if we
don't make it explicit.

==
hk