Subject: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Jan 2015 12:44:48 -0500

Dear colleagues,

I have read draft-grothoff-iesg-special-use-p2p-names-03.  I have some
comments.

In section 3, the definition of NXDOMAIN isn't actually necessary;
this was defined in RFC 2308.

I think it's great that the authors of this document have broken out
the specialness of each kind of name, according to the criteria of RFC
6761.  This is very helpful, because it allows each name to be
considered independently.  I do think it would be rather better if
they were broken apart into separate documents -- or at least broken
into groups of interdependent names -- because some of these names
seem to me to be more problematic than others.

Each of the names' special-processing sections includes a requirement
(in item 6) that DNS server operators not provide resolution for names
beneath the pseudo-TLD in question.  I hope the authors do not imagine
that this will prevent any server operator from answering queries for
such names; there is effectively no way to make this guarantee, which
is part of the risk of using DNS-like names that are not actually in
the DNS.  It seems that ought to be pointed out in the security
considerations. 

For each of these names, it would be nice to see an argument as to why
the names need to be TLDs as opposed to being located elsewhere in the
tree.  Given the fairly wide deployment of Tor, it's probably too late
to fix onion and exit; but the other cases seem to be pretty lightly
deployed, and I think one probably needs a strong argument for why we
ought to be encroaching on the global namespace this way.  In the
draft, at least the motivations for onion and exit are made clear.
It's a little harder to find the motivation for i2p, gnu, and zkey;
but if you follow the references, you can figure it out.

The same cannot be said for bit.  The specification for it that is
referred to in the draft is, to put it charitably, rather sketchy.  It
appears, however, that bit is an attack on the existing IANA-managed
name registration system.  There appears to be a namecoin business
model and fees, and there are claims on
https://wiki.namecoin.info/index.php?title=Register_and_Configure_.bit_Domains
about "owning" the domain.  I think it is completely illegitimate to
use the IANA special-use names registry to try to circumvent the
administrative arrangements undertaken by the IANA operator of the
global namespace (regardless of how one might feel about that
operator's stewardship of the global namespace or the policies,
financial or otherwise, governing the root zone).  There seems to be
no technical advantage that bit is enabling (cf. "special handling of
a name is required in order to implement some desired new
functionality", from RFC 6761) apart from the trick of removing name
registration activities from the DNS and putting them in the hands of
someone else, with policies and protocols that are not well specified.
I therefore do not believe that this I-D should proceed until either
bit is removed from it, or a justification for the registration of bit
is added to the document.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: hellekin <[email-masked]>
Date: Mon, 05 Jan 2015 15:01:41 -0300

> I have read draft-grothoff-iesg-special-use-p2p-names-03.  I have some
*** Thank you Andrew for taking the time to review this draft.  We shall
take your suggestions into account in the next draft.  I'm commenting a
couple of things here in order to clarify our position.

> tree.
*** A common denominator of all 6 pTLDs is that they do not use the DNS
tree hierarchy.  It's not that they don't want to, but that their
technical approach, both in terms of objectives and solutions, make them
incompatible with a centralized, hierarchic name assignation and resolution.

> 
> It appears, however, that bit is an attack on the existing IANA-managed
> name registration system.
>
*** I'm very sorry to read that.  It reminds me the claims that the
automobile industry is an attack on the horse-carriage, or that the
optical drive is an attack on the cassette recorder: it has zero
technical value and seems not to have its place on an IETF mailing list.

The naming system of .bit uses a public ledger based on the technology
introduced with Bitcoin.  This is a technical approach that has the same
justification of the DNS tree or a fridge (sorry for the latter example,
I'm in Buenos Aires, and the temperature is certainly affecting my
brain): it works and does what it is supposed to do.

.bit, as the other P2P names proposed in our draft, in common, for they
share commonalities, should be considered for their technical merits and
not the political agenda of third parties.

Regards,

==
hk

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Jan 2015 10:25:50 -0800

Hellekin,

> A common denominator of all 6 pTLDs is that they do not use the DNS

I think you missed Andrew's point.

All 6 technologies use a string that looks like a domain name but isn't intended for use in the DNS.  Why does it matter if there is a '.' in the middle of that string?  That is, given the technology is presumably going to intercept the domain name before it gets sent to a resolver, why would it not be possible to use (say) BIT.ALT instead of .BIT?

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Jan 2015 14:04:03 -0500

> incompatible with a centralized, hierarchic name assignation and resolution.

But that isn't _quite_ true.  If I go and read the documentation for
bit, it tells me how to configure my DNS servers.  In that respect, it
seems quite different from the other names.

> technical value and seems not to have its place on an IETF mailing list.

I am not sure how else to understand the documentation that is
available around bit.  Part of this could be solved, I suppose, if the
documentation for bit were somewhat more detailed (and stable).  

> introduced with Bitcoin.

All that tells me is the policy by which names in bit are registered.
In that sense it's not different from zone policies like, "I permit
U-labels that include Han characters but not Arabic characters."

> not the political agenda of third parties.

My point was not a political one, but a technical one: I don't see
what bit offers that is any different from the DNS, and it's
requesting that the IETF take back from ICANN a part of the root
namespace that is otherwise available to ICANN to delegate.  The only
justification that I can find in the bit documentation is simply a
political one: the proponents don't seem to like the name-registration
process that exists now, and they want a different one, but they want
it all to work with the DNS.  That seems to me to be engineering
around a political problem, and I am not convinced that the IETF ought
to taking back part of the root name space in order to facilitate that.  

That doesn't mean that the namecoin system shouldn't be supported.
But it seems to me that there's a difference between registering a
special name for this, and registering it such that we alter the size
of the root namespace.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Grothoff <[email-masked]>
Date: Mon, 05 Jan 2015 20:16:26 +0100

On 01/05/2015 07:25 PM, David Conrad wrote:
> Hellekin,
> 
>>> For each of these names, it would be nice to see an argument as
>>> to why the names need to be TLDs as opposed to being located
>>> elsewhere in the tree.
>> A common denominator of all 6 pTLDs is that they do not use the
>> DNS tree hierarchy.  It's not that they don't want to, but that
>> their technical approach, both in terms of objectives and
>> solutions, make them incompatible with a centralized, hierarchic
>> name assignation and resolution.
> 
> All 6 technologies use a string that looks like a domain name but
> isn't intended for use in the DNS.  Why does it matter if there is a
> '.' in the middle of that string?  That is, given the technology is
> presumably going to intercept the domain name before it gets sent to
> a resolver, why would it not be possible to use (say) BIT.ALT instead
> of .BIT?

Usability.  Especially on small screens (mobiles, etc.), every character
matters.

Also, we're not "alt" (German for "old"), we're new! DNS is "alt".

I personally also refuse to accept that ICANN somehow "owns" the entire
global name space.  We must not let anybody own our language. Allowing
ownership for certain individual words -- just as in trademarks -- can
be acceptable, but never everything.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Jan 2015 11:51:48 -0800

On Jan 5, 2015, at 11:16 AM, Christian Grothoff <[email-masked]> wrote:
> . . .
> global name space.

Given the weakness of the first statement, and the lack of understanding of the DNS in the second, I support Andrew Sullivan's statement earlier:

> is added to the document.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Jan 2015 15:15:34 -0500

> Usability.  Especially on small screens (mobiles, etc.), every character

Who even types domain names any more?  On small screens, you don't
type domain names.  You use apps.  The domain names are embedded in
places.  When I use the onion browser on my mobile, I follow links.  

In fact, I can see a stronger argument for, "More octets in the name
takes away from the space of the 255 octets we have to work with,"
except of course since these names _aren't_ DNS, they don't have that
limit.  Except of course maybe they do, because people seem to want
these alternative names to work just fine in every domain name slot.
Fundamentally, this is where the problem lies: every one of these
systems wants to do "DNS-ng" without fixing some of the big
limitations.  I have a great deal of sympathy for that desire, because
I agree that "reformat the Internet" isn't really an option.  But the
fit is rather awkward.

> Also, we're not "alt" (German for "old"), we're new! DNS is "alt".

If the primary objection to _that_ draft is the string, the problem is
easily resolved.

> I personally also refuse to accept that ICANN somehow "owns" the entire

ICANN does not own it; indeed, the very existence of top level names
in the special-names registry is evidence to that effect.  But the
IETF has in fact delegated the responsibility of managing the root
zone to IANA, and the IANA operator is ICANN.  Having made that
delegation, it seems rather arbitrary of us to come along and yank
back chunks of it for political reasons.  Hence my concern.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Grothoff <[email-masked]>
Date: Tue, 06 Jan 2015 00:32:03 +0100

> places.  When I use the onion browser on my mobile, I follow links.  

And I call people by typing (yes, console)
/call nickname.gnu
and I prefer to keep doing just that to avoid repetitive strain injury.

> limitations.

Right, GNS could be much nicer without IDNA insanity, 63-character label
limitations and 255 character limits.  But if we do stick to them, then
telnet, ssh, and Firefox can use GNS without changes to the application.
 So this is the catch 22: _some_ compatibility will have to be
maintained for some time, because we won't see direct application
support until we have many users, and we won't get many users unless
there are applications that can use the system.  So GNS offers a
DNS-compatible API (and even a dns2gns proxy) where it doesn't hurt too
much (i.e. the limitations are not that painful for the user).

> I have a great deal of sympathy for that desire, because

".alt" is IMO worse.

> If the primary objection to _that_ draft is the string, the problem is

I'll add markup to my sarcasm next time.

> back chunks of it for political reasons.  Hence my concern.

Not political reasons, these are technical reasons. Usability is a
technical concern.  Using privacy-preserving, end-to-end secure name
resolution is a technical matter.  We can't do those with DNS, so we
need a (name)space to enable/explore those matters.

With GNS specifically, we tell users that the labels match exactly the
entities they rely on for resolution (no out of bailiwick, no glue or
other funny business).  If you append some semi-random DNS name, you
destroy this key aspect of usable security where the user's intuition
about what is going on matches what is happening.

---

From: hellekin <[email-masked]>
Date: Mon, 05 Jan 2015 21:32:11 -0300

> I think you missed Andrew's point.
*** Thank you David for shedding some light.

> All 6 technologies use a string that looks like a domain name 
> but isn't intended for use in the DNS.  Why does it matter if there is
> a '.' in the middle of that string?  That is, given the technology is
> presumably going to intercept the domain name before it gets sent to a
> resolver, why would it not be possible to use (say) BIT.ALT instead
> of .BIT?
>
*** Our next draft will certainly address this point.

I would say, like Christian: usability.  But for a completely different
reason.

If it makes sense to delegate a subtree and tell the implementors:

"now, for all domains under the .alt DNS subtree, you MUST check what is
the correct assignment and resolution strategy for each domain, and you
MUST handle the domains accordingly.", then I guess it makes sense to
use .bit.alt, and then .cjdns.alt, and .fubar.alt, etc. as long as each
SUBDOMAIN will use a different strategy for handling names.

On the other hand, if we want to keep a sane base, we'd rather identify,
circumscribe and announce the various existing strategies, and hope that
future strategies that may or may not appear will have a solid
foundation for incorporating their innovative strategy into the global
name space.  Our group chose the latter.

Regards,

==
hk

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Jan 2015 18:03:10 -0800

Hellekin,

> *** Our next draft will certainly address this point.

Thanks.

> SUBDOMAIN will use a different strategy for handling names.

That is the basis behind https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-03.

> name space.  Our group chose the latter.

There is a token at the end of a domain name that indicates it shall be handled differently than domain names without that token.  Aside from the length, I'm afraid I don't see how having a "." in the string negatively impacts the solidly of a foundation, innovative or not.

Some additional comments on http://tools.ietf.org/pdf/draft-grothoff-iesg-special-use-p2p-names-03.pdf:

- 1. Overall:

As with previous versions of this draft, I believe it should be broken up into separate drafts for each of the proposed 6761 special names registry entries.  Tying all 6 names into a single draft is pointlessly complicating the discussions and it is likely some special use names may be more easily justified than others (e.g., .ONION) due to existing installed base, completeness of documentation, etc., and it would be a shame to delay that approval because of requests for other, unrelated, special use names.

This document confuses the concepts of the domain name namespace with the DNS implementation of that namespace, making numerous assertions that they must have a particular string within the namespace because their particular application does not (necessarily) require the use of the DNS.  This is a false dichotomy: the DNS implementation of the singular hierarchical domain name namespace does not preclude the use of any portion of that namespace outside of the DNS (for example, see nsswitch).

I'm not sure if this is the right place to raise this, but I'm a bit confused: if DNS servers (caching/authoritative) are expected to respond with NXDOMAIN since "not doing so can put users’ privacy at risk", doesn't this set users of pTLDs up for privacy violations by bad guys running a DNS server?

- Introduction:

"However, the hierarchical nature of DNS makes it unsuitable for various P2P Name Systems."

As mentioned above, the fact that a P2P name does not require the DNS hierarchy does not mean it is unsuitable to be placed within that hierarchical namespace that the DNS implements.  In fact, one can argue (as dnsop-alt-tld does) that placing the special use name within a sub-tree of the namespace facilitates interoperability of DNS and non-DNS domain names utilizing a single rooted namespace.

- 2. Applicability

"pTLDs cannot be allocated administratively"

Perhaps you mean "Names within pTLDs cannot be allocated administratively"?

"pTLDs do not depend on the DNS tree hierarchy for their resolution"

As above.

"However the default hierarchical DNS response to any request to any pTLD MUST be NXDOMAIN."

If your applications depend on getting back an NXDOMAIN, you're going to have a bit of trouble with DNS redirection.  More to the point, if your applications require an NXDOMAIN, it suggests you _ARE_ using the DNS which implies RFC 6761 does not apply. It also suggests your applications will be flooding the root with queries for non-resolvable names which, while all the rage these days, is a bit anti-social.

'The word "peer" is used in the meaning of a individual system on the network. Thus, "local peer" means the localhost.'

I would've thought "local peer" would mean a system within the same network topological level, not on the same machine (implied by localhost). But maybe that's just me.

"A pTLD is mentioned in capitals, and within double quotes to mark the difference with a regular DNS gTLD."

Presumably you mean "TLD" not "gTLD" as "gTLD" is a specific type of top-level domain (generic as opposed to country code (ccTLD)).

Hope this helps.

Regards,
-drc

---

From: Christian Grothoff <[email-masked]>
Date: Tue, 06 Jan 2015 09:47:22 +0100

On 01/06/2015 03:03 AM, David Conrad wrote:
> This document confuses the concepts of the domain name namespace 
> with
the DNS implementation of that namespace, making numerous assertions
that they must have a particular string within the namespace because
their particular application does not (necessarily) require the use of
the DNS. This is a false dichotomy: the DNS implementation of the
singular hierarchical domain name namespace does not preclude the use of
any portion of that namespace outside of the DNS (for example, see
nsswitch).

Well, I believe that while you are technically right, an nnswitch plugin
hijacking ".com" today to do something very different from DNS
resolution is typically not merely bad design, but most likely malware.
This is what we mean by usability: we need to satisfy user's
expectations, and just grabbing some TLD that ICANN has already
allocated is likely to cause usability problems by confusing users.

> I'm not sure if this is the right place to raise this, but I'm a bit
confused: if DNS servers (caching/authoritative) are expected to respond
with NXDOMAIN since "not doing so can put users’ privacy at risk",
doesn't this set users of pTLDs up for privacy violations by bad guys
running a DNS server?

Yes, it does.  Correctly configured installations of the P2P name
systems must never contact DNS servers about these pTLDs.  However, if
an *honest* DNS server were to say redirect a user of a '.onion' to an
advertisement server, the information leak might be extended to the
advertisement server.  So this is about limiting the privacy breach, not
about avoiding it. Only correct configurations can avoid it.  And it is
also a bit about possibly reducing the load on the DNS root by
officially condoning not asking the root for these TLDs.

> Perhaps you mean "Names within pTLDs cannot be allocated

Yes, except thinking about it 'cannot ... administratively' also has not
exactly the right ring to it.  I'll change it to:

"Names within pTLDs are not allocated by some designated administration"
would be more precise.

> "pTLDs do not depend on the DNS tree hierarchy for their resolution"

I see your point about the confusion between DNS-style names and
DNS-style resolution.

> If your applications depend on getting back an NXDOMAIN, you're going
> to have a bit of trouble with DNS redirection.  More to the point, if
> your applications require an NXDOMAIN, it suggests you _ARE_ using
> the DNS which implies RFC 6761 does not apply. It also suggests your
> applications will be flooding the root with queries for
> non-resolvable names which, while all the rage these days, is a bit
> anti-social.

Not exactly. Legacy GUIs often use DNS (or Socks4a) to interact with the
P2P name system. So for the legacy GUI the system looks like DNS.  But
then at the dns2gns proxy, the NSS or the Socks-proxy, the
DNS-formatted, DNS-style requests are processed differently based on the
TLD.

However, if say the socks proxy is "off", or the NSS is missconfigured,
then the requests may unintentionally be leaked to DNS.

> 'The word "peer" is used in the meaning of a individual system on the
> network. Thus, "local peer" means the localhost.'
> 
> I would've thought "local peer" would mean a system within the same
> network topological level, not on the same machine (implied by
> localhost). But maybe that's just me.

I agree, while uncommon it doesn't have to be localhost. I'll remove the
sentence starting with "Thus".

> Presumably you mean "TLD" not "gTLD" as "gTLD" is a specific type of
> top-level domain (generic as opposed to country code (ccTLD)).

Well, we don't have ccTLDs in the text, and in my view "TLD" includes
"gTLD", "ccTLD" and "pTLD".

> Hope this helps.

Yes, thanks for your constructive feedback.

-Christian

---

From: David Conrad <[email-masked]>
Date: Tue, 6 Jan 2015 14:31:38 -0800

Christian,

> On Jan 6, 2015, at 12:47 AM, Christian Grothoff <[email-masked]> wrote:
>> The DNS implementation of the

I meant to provide nsswitch as one (generic) example of a way to implement a portion of the domain name namespace outside of the DNS. It obviously is not the only means -- /etc/hosts would be another (less generic) example.

> allocated is likely to cause usability problems by confusing users.

I understand and that is, I believe, what RFC 6761 was trying to facilitate. The question isn't whether grabbing some TLD is a good idea (it isn't) but rather, is a TLD actually necessary.  So far, as far as I've seen, the only concrete justification you've provided appears to be that a TLD (as opposed to a second-level name in a sub-tree dedicated to non-DNS domain names) means fewer characters to type. I'd note that in the case of TOR, something like T.ALT or O.ALT would be the same number of characters as .ONION.

> Correctly configured installations of the P2P name
> systems must never contact DNS servers about these pTLDs.

It might be worthwhile stating this explicitly as in:

"Installations of the P2P name systems MUST NOT contact DNS servers about these pTLDs."

perhaps adding that exposure to the DNS of these P2P names would constitute a potential privacy/security risk.

However, as I understand it, this wouldn't appear to apply to GNS and Namecoin ("GNS and Namecoin domains MAY use [the DNS tree hierarchy], as they return DNS-compatible results; ..."), so I presume I'm misunderstanding something -- apologies for not having time to delve into the details of how those systems actually work (that's on my list of things to do).

> "Names within pTLDs are not allocated by some designated administration"

That's clearer, at least to me.

> then the requests may unintentionally be leaked to DNS.

OK. My concern was that I had somehow inferred that a potential algorithm for transition to a P2P system was:

get domain name
query DNS for domain name
if response is NXDOMAIN then
	query P2P system for domain name
	P2P domain name handling
else
	DNS domain name handling
endif

(which would obviously be bad)

Perhaps in section 2, around (or replacing) the third bullet on starting page 3, you could say something along the lines of:

"o When a pTLD protocol has been implemented, existing software libraries and APIs MUST intercept queries intended for the DNS and MUST NOT extend regular DNS operation to ensure P2P names cannot leak into the DNS."

> "gTLD", "ccTLD" and "pTLD".

Right, the nit I was picking was there was no need to specify the type of DNS TLD.

Regards,
-drc

---

From: Christian Grothoff <[email-masked]>
Date: Wed, 07 Jan 2015 00:03:55 +0100

On 01/06/2015 11:31 PM, David Conrad wrote:
>>> The DNS implementation of the singular hierarchical domain name
>>> namespace does not preclude the use of any portion of that
>>> namespace outside of the DNS (for example, see nsswitch).
>> 
>> Well, I believe that while you are technically right, an nnswitch
>> plugin hijacking ".com" today to do something very different from
>> DNS resolution is typically not merely bad design, but most likely
>> malware.
> 
> I meant to provide nsswitch as one (generic) example of a way to
> implement a portion of the domain name namespace outside of the DNS.
> It obviously is not the only means -- /etc/hosts would be another
> (less generic) example.

Sure.

> I understand and that is, I believe, what RFC 6761 was trying to
> facilitate. The question isn't whether grabbing some TLD is a good
> idea (it isn't) but rather, is a TLD actually necessary.  So far, as
> far as I've seen, the only concrete justification you've provided
> appears to be that a TLD (as opposed to a second-level name in a
> sub-tree dedicated to non-DNS domain names) means fewer characters to
> type. I'd note that in the case of TOR, something like T.ALT or O.ALT
> would be the same number of characters as .ONION.

You're forgetting other issues, such as who manages .alt-allocations.
I just can't repeat every argument each time, and if I don't have
everybody go and say that clearly I only have one because I didn't put
them all forward in each e-mail. Sorry, I'm not a parrot, and I had this
specific discussion with you already over a year ago:
 http://www.ietf.org/mail-archive/web/dnsop/current/msg10876.html

>> Correctly configured installations of the P2P name systems must
>> never contact DNS servers about these pTLDs.
> 

Sure. But that depends a bit on your definition of "DNS server" -- if I
run a dns2gns proxy that speaks DNS, is that a "DNS server"? If a
Namecoin user configures his DNS server to support ".bit", is it still a
"DNS server"?  If we write "ordinary DNS servers", that might work.

> perhaps adding that exposure to the DNS of these P2P names would
> constitute a potential privacy/security risk.

Sure.

> However, as I understand it, this wouldn't appear to apply to GNS and
> Namecoin ("GNS and Namecoin domains MAY use [the DNS tree hierarchy],
> as they return DNS-compatible results; ..."), so I presume I'm
> misunderstanding something -- apologies for not having time to delve
> into the details of how those systems actually work (that's on my
> list of things to do).

GNS and (AFAIK) Namecoin can (or at least theoretically could)
internally delegate names back to DNS. I.e. I could make BAR.example.gnu
resolve to BAR.example.com (possibly bypassing the root zone by
providing both NS and DNAME information in a combined record, or using
full DNS resolution via CNAME).  So these new name systems can integrate
with legacy resolution, bypassing legacy issues such as the status of
.IR depending on a US court decision...

>> Yes, except thinking about it 'cannot ... administratively' also
>> has not exactly the right ring to it.  I'll change it to:
>> 
>> "Names within pTLDs are not allocated by some designated
>> administration" would be more precise.
> 

:-)

>> However, if say the socks proxy is "off", or the NSS is
>> missconfigured, then the requests may unintentionally be leaked to
>> DNS.
> 
> OK. My concern was that I had somehow inferred that a potential
> algorithm for transition to a P2P system was:
> 
> get domain name query DNS for domain name if response is NXDOMAIN
> then query P2P system for domain name P2P domain name handling else 
> DNS domain name handling endif
> 

Yes, very bad indeed ;-).

> Perhaps in section 2, around (or replacing) the third bullet on
> starting page 3, you could say something along the lines of:
> 
> "o When a pTLD protocol has been implemented, existing software
> libraries and APIs MUST intercept queries intended for the DNS and
> MUST NOT extend regular DNS operation to ensure P2P names cannot leak
> into the DNS."

Well, it may not be a software library in charge (see Tor socks proxy),
and the pTLD resolutions are obviously not "intended" for the DNS.

So I'd write:

        When a pTLD protocol has been implemented, the implementation
        MUST intercept queries for the pTLD to ensure P2P names cannot
        leak into the DNS.

Acceptable?

Best regards,

Christian

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Jan 2015 19:35:33 -0500

I’ve read this draft and began to reply a few times, but keep changing my mind on how to respond.

> name space.  Our group chose the latter.

Here’s where I think a problem lies.

“the global name space.”  Specifically the word “the."

What I read in the draft is that there are four different name spaces which are using identifiers that resemble the printed version of a DNS identifier.  (The four being GNS, Tor, and the two for the latter two applications.)  By “the printed version” of a DNS identifier I am differentiating from the on-the-wire form of a domain name (which has no dots in it).  “Resemble” refers to the desire for general purpose applications to be able to treat, as commonly as possible, the names regardless of the appropriate mechanism for resolution in the correct name space.

This kind of parallels the situation surrounding the DBOUND (not-yet-but-maybe-soon-WG) activity.  That activity involves a set of applications using identifiers that happen to be based on domain names (a little stronger than resembling them).  The significant difference between this draft and DBOUND is that this draft is about “resolving” the idenfitier to a service point, DBOUND is about “knowing what administrative/security properties” to apply to an identifier.

From what I’ve read in the draft, the rules for special use, and in the thread, is that there’s a desire that identifiers in these four other (other than DNS) name spaces to never touch the DNS.  Not simply avoid collisions but to outright and completely avoid the DNS packet stream, so that the queries aren’t even witnessed by those who can see DNS packet traffic.  And if for some reason the queries do leak to the DNS, the DNS should act as if the domain name corresponding to the identifier does not exist.  Which the DNS does today, meaning, the draft wants status quo for the DNS, in the protocol and in allocation.

I.e., the identifiers are not special to the DNS, the desire is that they are never added to any root zone - the global public Internet or any other.  Most of the leaked traffic would go to the global public Internet, which is largely managed via the ICANN processes (I’ll skip the extensive caveats to apply here) so one can think to focus there.  Anyone can stand up a DNS server and load their own root zone into it with the strings mentioned in the draft - and since there’s always “old code” around, nothning can stop the DNS protocol from serving up colliions with these names.  Sorry for this path, but, I keep coming back to - there’s no reasonable change to the DNS protocol that can prevent (and I mean prevent) any mishaps - keeping in mind that the whole DNS angle here only comes in when the applications “leak” the identifiers.

What is needed is a change to all applications that handle identifiers that resemble printed domain names so that they know how to resolve the names.  They need to know when an identifier is a GNS identifier or a Tor identifier. (Would leaking a GNS identifier to Tor be as bad as leaking it to DNS?)  That’s a problem to be solved, even if this draft is not the place to do it.  WIthout this, it’s likely that identifiers will leak all over.

What I’m commenting does not directly answer whether the draft fulfills the requirements for an application to the special needs registry.  At some higher level I wonder that even if these names were listed there whether the problem of managing the identifiers will be solved.  The desire to have name spaces besides the DNS name space is definitely legitimate, the technical barrier is how to know what space an identifier belongs to if the same syntax is shared.

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 6 Jan 2015 22:42:42 -0200

> What I’m commenting does not directly answer whether the draft fulfills the requirements for an application to the special needs registry.  At some higher level I wonder that even if these names we…

Which perhaps suggests an W3C approach instead of an IETF one ? 
httpoo://(ToR identifier) (oo for "over onion", although it makes a curious acronym)
httpob://(name coin address) 

Rubens

---

From: Christian Grothoff <[email-masked]>
Date: Wed, 07 Jan 2015 02:01:42 +0100

Dear Edward,

I think what you wrote is overall a pretty accurate analysis. What I
would want to point out that

> What is needed is a change to all applications that handle
> identifiers that resemble printed domain names so that they know how
> to resolve the names.  They need to know when an identifier is a GNS
> identifier or a Tor identifier. (Would leaking a GNS identifier to
> Tor be as bad as leaking it to DNS?)  That’s a problem to be solved,
> even if this draft is not the place to do it.  WIthout this, it’s
> likely that identifiers will leak all over.

is not exactly correct, as for example GNS intercepts DNS queries in NSS
or using iptables, allowing applications to remain ignorant of the use
of GNS. So sometimes applications do not need to be changed and might
never need to know.

However, that said, generally GNS becomes MUCH more powerful if
applications support it explicitly, as features such as resolving TLSA
records or GnuPG public keys are obviously not possible via mechanisms
like NSS.  I believe DNSSEC suffers similarly from the burden of legacy
APIs.

You are of course right that legacy applications that do not explicitly
support the pTLDs significantly increase the risk of pTLD queries
escaping to DNS, as there is then a risk of the overall system not being
correctly configured.

Best,

Christian

---

From: Christian Grothoff <[email-masked]>
Date: Wed, 07 Jan 2015 02:14:24 +0100

I did actually recently suggest to some Tor devs that they should use

onion://domain/
or tor://domain/

instead of http://, as they are indeed not using HTTP and this would be
a nice way to indicate anonymous/non-anonymous use.  But, again, legacy
and usability (users these days don't even see the http://) likely mean
that this won't happen, even if technically it would be cleaner.
Furthermore, while you can use tor:// to indicate the change in
protocol, the combinatorial issue means this won't really solve the
issue of the draft, especially as names for GNS and NameCoin are really
meant to be usable in any URL with any protocol (telnet://, http://,
gnunet://, mailto:, etc.) in the place where there is a domain name in
the URL. So it makes sense to write:

tor://example.bit/ or
http://example.bit/ or
tor://example.gnu/ or
http://example.gnu/

In fact, even

tor://example.gnu/ and
onion://example.gnu/

might both make sense, with the 1st using Tor to exit to the A/AAAA IP
address specified in GNS, and the 2nd using Tor to go to the hidden
service specified in GNS (that's one of those Tor-GNS-integration issues
I predict and tried to address with my suggestion to the Tor devs).

Summary: W3c approach is good to identify protocol, which may be
imperfectly solved in Tor's current design/deployment; but we're
discussing name resolution process, not transport protocol.
So I'd say you're confusing layers.

Best,

Christian

On 01/07/2015 01:42 AM, Rubens Kuhl wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: hellekin <[email-masked]>
Date: Tue, 06 Jan 2015 22:14:40 -0300

> httpob://(name coin address) 
*** Our draft is about matching names with IP addresses, not about
limiting what protocols can be used over P2P (hint: any protocol can run
over GNUnet, you can wrap any protocol in onionspace, and do bittorrent
over I2P, etc.)

==
hk

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Jan 2015 22:38:09 -0500

Hi,

On Wed, Jan 07, 2015 at 02:14:24AM +0100, Christian Grothoff wrote:
> a nice way to indicate anonymous/non-anonymous use.  

[…]

> the URL. So it makes sense to write

Thanks very much for this.  You've just expressed, in a _much_ clearer
way than I ever did, the reason that I think the various proposals
need to be pulled apart into separate drafts.

Some of these proposals are in fact using names in domain name slots
as ways of indicating that the protocol itself ought to be
different. The hint a name below onion is giving is, "Not really the
protocol you think it is."  It's a protocol-redirection trick.

In the other case, it's an indication that the _namespace_ is
different: that if you resolve that name on the Internet without
special enabled software, you aren't getting the service you desired,
regardless of the protocol you happen to be using.  In theory, these
kinds of applications actually ought to want a new DNS class; but
since classes are broken (because of CNAMEs/DNAMEs and also because of
the facts of deployed infrastructure), in-band signalling in the
domain name is the preferred alternative.

I'm not the sort of DNS purist who thinks these strategies are evil
(they do of course make my inner database geek itchy, but I'm
perfectly prepared to be pragmatic).  But they're different kinds of
problems, and so ought to be evaluated differently.

It's really shameful that both the DNS community and the URI scheme
community have been so hidebound that these differences are not
totally obvious.  I don't want to (ok, "to insist that we") fix those
issues in proceeding with these proposals; I just want the different
kinds of proposals to be pulled apart so that the Internet community
can distinguish the kinds of problems we're talking about.

Just to be clear, I hope it doesn't seem like I'm trying to say, "No,"
to everything.  I really want to support all the various approaches to
fixing the myriad problems before us.  But I want also to separate
different kinds of problems from one another.  Moreover, I wonder
whether using the special-names registry at the top level is justified
in every case, given that in principle we've already assumed that
top-level name space is managed by someone else.  When that top-level
name space was entirely stable, hiving out new chunks did not present
inter-community risks, but now that the space is not so stable the
technical and administrative risks are greater.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: hellekin <[email-masked]>
Date: Wed, 07 Jan 2015 03:36:11 -0300

> protocol you think it is."  It's a protocol-redirection trick.
*** Not exactly.  As I understand it, Tor says: until you reach the exit
node, the actual protocol is hidden from the intermediate participants
and observers.  At the exit node, HTTP is used if that is what you
intended to use.

The case for using tor:// or onion:// (let's say it's tor:// to
simplify), is to be able to indicate that the transport to destination
should be the Tor network.  In such case, you could use
tor://example.com/ in your Web browser, and your Web browser would know
that you intend to use HTTP(S?) to reach example.com via the Tor
network, or you'd type: `ssh tor://example.net` to use SSH over Tor
instead of `torsocks ssh example.net`, etc.

Similarly, tor://facebookcorewwwi.onion/ would be redundant on a system
running Tor only with https://facebookcorewwwi.onion/ but useful on a
system running GNS and not Tor as the GNS resolver may know how to pass
it on over the Tor network in the future.

> regardless of the protocol you happen to be using.
>
*** This is true for all 6 pTLDs: special software is required to reach
the desired service.  Otherwise, NXDOMAIN is returned after hitting the
DNS root.  The problem resides in the fact that IANA may assign one of
the 6 pTLDs to some registrar, and then conflicts start happening.  Once
IANA has assigned the pTLDs to P2P Systems, such conflict is known to be
an error, or a malicious attempt, as the DNS cannot resolve such names
without specific changes to implementations.

> In theory, these kinds of applications actually ought to want
> a new DNS class
>
*** A new DNS class would neither solve the privacy issue nor the
censorship issue P2P systems want to address.

> But they're different kinds of
*** At least we shared that feeling, if not the scope of "kinds of
problems" :)

> Moreover, I wonder
> top-level name space is managed by someone else.
>
*** The main issue I foresee with packing widely different name
assignment and resolution strategies at levels below the top-level,
e.g., under an .alt TLD, is one of complication.  Who is managing name
assignment and conflicts under .alt?  Is that IETF via RFC 6761?  Is
that weird wild west?

Now we're talking about 6 pTLDs, each one using its own strategy.  They
have in common to use innovative name assignment and resolution
strategies independent from a centralized assignation authority.  Why
would such strategies appear lower than top-level, especially
considering that they're even different strategies from each other?

There might be others appearing but it's quite unlikely that they would
flourish.  On the other hand, opening .alt would give an incentive to
rush for foo.alt and each new case would have to be treated separately
by each application--without any way to know whether it fails because
the target host name does not exist or because the domain name is not
assigned.

Imagine that we have .bit.alt.  Applications start supporting .bit.alt,
and it works, and everybody is happy.  I can request a web page from
example.bit.alt, and I retrieve it.  I can request a web page from
non-existent.bit.alt and receive an NXDOMAIN.  Perfect.  Now I mistype,
or the person creating the QR code I used to connect mistyped:
wrong.example.b1t.alt. Bee One Tee.  Hardly visible.  Still returns
NXDOMAIN.  Is that because the wrong.example.bit.alt does not exist, or
because the b1t.alt does not exist, or is it not supported by my system?
 Things become complicated and confusing.  20 naming strategies later,
implementors ask: was it .bit.alt or .but.alt that used the digital Arab
telephone strategy?  Or was it .bot.alt?  Are you sure .bot.alt exists?
 Where can I verify what sub-domains of .alt exist?  Who controls the
list?  Should Apple re-deploy .local under .local.alt?  Why .invalid.?

Six pTLDs in one RFC fosters clarity: these names are not assigned using
regular DNS delegation to registrars; each has its own peer-to-peer way
of assigning and/or resolving domains, outside the DNS tree ; they
enable protection against arbitrary censorship.  The message is both
clear and simple.  It becomes complicated when trying to eliminate the
assignment/resolution specificity of P2P name systems.  It becomes
complicated if you have to look them up in various RFCs to figure out
which P2P domains do not follow the regular DNS delegated registration
rules.

Regards,

==
hk

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Jan 2015 13:59:42 +0000

> domain name is the preferred alternative.

Classes are the wrong thing for this purpose, because I don't think these
are separate namespaces - they are different resolution mechanisms for
particular parts of the same hostname namespace. There already examples of
similar splits, e.g. mDNS using .local and (to some extent) /etc/hosts
(though that covers the whole namespace rather than a particular part).

You can't use classses for this purpose because applications that resolve
hostnames do not have a way to specify a name's class. But it is perfectly
feasible to install a new system resolver module which changes the way
part of the namespace works without requiring changes to any of the apps.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: South 5 or 6, veering southwest 6 to gale 8,
becoming cyclonic 4 or 5 later. Moderate or rough, occasionally very rough in
Portland and Plymouth. Rain. Good, occasionally poor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jan 2015 10:19:54 -0500

> part of the namespace works without requiring changes to any of the apps.

For these purposes, a separate resolver is needed anyway.  So a
different class is just as feasible.  I'm not sure I buy the argument
that this is the same name space, because the resolver itself is
different.  I'd argue that mDNS is in the same boat.  This technique,
really, is using the namespace as a clue that the protocol has shifted.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2015 11:05:35 -0500

On Jan 7, 2015, at 10:19 AM, Andrew Sullivan <[email-masked]> wrote:
> different class is just as feasible.

You seem to be missing Tony's point.

The point is that there is already a UI for typing, for example, "foo.onion".   There is no UI for typing "foo" and saying "and that should be resolved using the 'onion' domain class."   So a resolver that supports using a different protocol to resolve .onion can work with an application that isn't aware that this is happening under the covers.

Whether that's a good or bad thing can of course be discussed, but that's the key point that your response doesn't address.   Except for this part, which is correct:

> I'd argue that mDNS is in the same boat.  This technique,

Of course, that boat has already sailed... :)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jan 2015 11:12:21 -0500

On Wed, Jan 07, 2015 at 11:05:35AM -0500, Ted Lemon wrote:
> The point is that there is already a UI for typing, for example, "foo.onion".   

No, I get that, and I understand why we're using the name _instead_ as
an indicator.  This is really the same reason people used underscores
with TXT RRs as a selector instead of a different RRTYPE in lots of
cases: you use the interface you have.  My only real point is that the
Tor case and, say, the GNS case are really basically different,
because one of them would actually be susceptible to a different URI
scheme whereas others don't work that way.  I'm sorry I mentioned
classes; it's a distraction.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2015 11:25:25 -0500

> classes; it's a distraction.

Okay, that makes more sense.   I think there are really two questions here:

1. Do we need to do something to accommodate existing practice?
2. Ought we (or really they, since we don't have change control over ToR) to change that practice going forward?

I think these are actually separate issues that ought to be addressed separately, although they are of course related.   You seem to be speaking to the second point, not the first.   On the second point, the tradeoffs to consider include cleanliness of architecture, but also usability.

I think the best argument in favor of using a different URI schema is actually simply that we want things that don't actually understand how to do onion routing to fail rather than try, since trying using native DNS and HTTP exposes the user to attack on hosts that don't have resolver support for .onion.

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Jan 2015 16:45:46 +0000

Andrew Sullivan <[email-masked]> wrote:
>
> My only real point is that the Tor case and, say, the GNS case are
> really basically different, because one of them would actually be
> susceptible to a different URI scheme whereas others don't work that
> way.

I don't think that is true. You can use ssh or http or smtp or imap or any
TCP application over Tor, and you can use the GNS to resolve A and AAAA
records to use for any purpose too.

Tony.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jan 2015 14:20:56 -0500

> records to use for any purpose too.

Christian Grothoff was arguing up-thread that that isn't quite true.
I understood him to mean that what you're really doing with those
other protocols is tunneling them inside Tor.  I guess I can see an
argument that we don't use such scheme identifiers for other tunnels,
so we wouldn't in this case either.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Grothoff <[email-masked]>
Date: Wed, 07 Jan 2015 20:32:50 +0100

> Christian Grothoff was arguing up-thread that that isn't quite true.

I am not sure which sentence you are referring to, but if it was
understood like that I'm sorr and I should have been more precise. Of
course one can run various TCP-based protocols over Tor.  For example,
Pond uses URLs like

pondserver://[email-masked]

My point was more that Tor's ".onion" only refers to some TCP endpoint,
while .bit and GNS are more generic as you can store 'arbitrary' records
in the name system. Also, using Tor only makes sense if the application
you are tunneling is written to protect your privacy/anonymity, while
.bit and GNS do not imply such restrictions.

> so we wouldn't in this case either.

Right, that argument is certainly fair.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 7 Jan 2015 14:39:34 -0500

> On Jan 7, 2015, at 8:59 AM, Tony Finch <[email-masked]> wrote:
> 

Tony
I disagree, in my mind different resolution mechanism implies a different namespace. 
I think this mechanism of identifying the lookup mechanism by the last byte in the
name is BAD. 
I wrote this up a long time ago, and still think we should be encouraging 
new namespaces to address their lookups via BETTER functions rather than 
patching DNS resolution libraries. 

> part of the namespace works without requiring changes to any of the apps.

Strictly speaking new classes do not have a resolution mechanism defined, thus
Andrew is right, when one defines the use of a new class new lookup mechanism can be
part of that definition. 

Olafur