str4d | 21 May 23:08 2015

Re: Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld


Bob Harold wrote:
> On Wed, May 20, 2015 at 1:55 PM, Joe Abley <jabley <at> hopcount.ca>
> wrote:
> 
>> ... I would also support (as I have heard others say before, and
>> as I think I have also said) a separate document that provides
>> advice to anybody else planning to deploy code that uses a
>> DNS-like namespace that is not the DNS. Such people should either
>> make their names unambiguously different from those used in the
>> DNS, or should anchor them somewhere else in the namespace where
>> defensive registrations in the DNS are less contentious. For
>> example, if the Tor project had used "onion.eff.org" instead of 
>> "onion", we would not be having this conversation. Making such
>> guidance available would make it far easier to deal with the
>> future possibility that a decision with "onion" would set an
>> unfortunate precedent.
>> 
> ... The "onion.eff.org" idea only solves half of the problems - it
> would prevent others from using the domain for something else, but
> it fails to provide the required privacy - part of the requirement
> is that the onion names NOT be sent to DNS servers at all, for
> privacy.

The other reason this fails (partly linked to the privacy issue above)
is because it puts the entire .onion domain in control of a single
zone file. Even if the organization controlling that zone file is
trustworthy, it only takes a single compromise (and who hasn't heard
of DNS zones being hijacked?) for someone to add "legitimate" records
for e.g. facebookcorewwwi.onion.eff.org pointing to malicious servers
(Continue reading)

Tim Wicinski | 21 May 04:13 2015
Picon

Call for Adoption: draft-wkumari-dnsop-alt-tld

 From the discussion on the mailing list, this draft appears to have 
support in the working group. The authors have requested a Call for 
Adoption.  The chairs want to move forward with this draft if it has 
consensus support.

This starts a Call for Adoption for draft-wkumari-dnsop-alt-tld

The draft is available here:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Wednesday June 3rd, 2015.

Thanks,
tim/suzanne

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Tim Wicinski | 20 May 19:12 2015
Picon

Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld


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 
(Continue reading)

Stéphane Bortzmeyer | 20 May 13:12 2015
Picon

Qname Minimization <at> DNS-OARC (avec image, tweets) · shuque · Storify

For those who were not at the DNS-OARC meeting in Amsterdam, a nice
Storify on Qname minimzation:

https://storify.com/shuque/qname-minimization-dns-oarc

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Suzanne Woolf | 20 May 00:18 2015
Picon

followup and proposed actions: RFC 6761 interim and next steps

Dear Colleagues,

First, thanks for extensive and thoughtful discussion on the list and in our interim meeting last week on the way forward for the internet-drafts requesting special use names registry entries under RFC 6761.

This message is fairly long, and contains some impressions of where we are, a couple of actions we expect to take in the next few days, and some questions we’d like to pursue going forward. Please read all of it if you’re interested in the overall topic; we have significant challenges of both process and substance to navigate.

It's clear that applying RFC 6761 is challenging, and one of the outcomes we'd like to see from the current discussion is serious consideration of whether we need to update it with a new document suggesting additional guidelines or considerations.

First, some initial impressions:


.ONION (draft-appelbaum-dnsop-onion-tld-01):

* There’s significant support for the .onion request, in terms of the draft itself and what the TOR project is trying to accomplish by supporting the protocol and making the request.

* There are some reservations about .onion. We heard concerns that we might be setting a precedent for arbitrary appropriation of namespace; that the protocol may not be thoroughly documented, and that we’re not clear on how high the bar should be for a special use name.


.ALT (draft-wkumari-dnsop-alt-tld-06):

* There’s significant support for .alt as a possible alternative namespace for implementers who want namespace they’re certain won’t resolve in the global DNS, but are willing to be flexible on what namespace they use.

* There are operational questions about .alt that would have to be resolved in further development of the draft, such as whether to assume “leaked” queries would be sunk to AS112.

* There was some concern that implementers who want single-label or “TLD” namespaces would not accept .alt as a possible alternative

* There was some question as to what would be gained by .alt that we don’t already have in .invalid, which is also already reserved


HOME/CORP/MAIL (draft-chapin-additional-reserved-tlds-02):

* This is the most controversial of the RFC 6761 drafts and the one most driven by policy concerns

* The draft assumes that these names are commonly being used in local DNS contexts and often “leak” into the public internet. Specific uses are not documented.

* The most commonly used justification for this reservation was the risk of name collision if ICANN delegates these names in the production root zone.

* Since ICANN has said that they’re not currently planning to delegate these names, the justification further seems to assume that ICANN’s assurance of this is not a sound basis for believing that risk is contained

* There were questions about how to quantify name collision risk, or otherwise set a threshold for what operational characteristics of the appearance of a given name in the public internet would justify a conclusion that it should be “protected” by the IETF from delegation in the production root zone


ADDITIONAL NOTES:

There was some discussion of other drafts as well. In particular, there was some willingness to review the requests currently contained in draft-grothoff-iesg-special-use-p2p-names-04 if presented in separate drafts, as that would make it easier for the WG to properly consider those requests.


MOVING FORWARD:

We expect to take the following steps:

1. A call for adoption on the WG list of draft-appelbaum-dnsop-onion-tld-01. Given that there's clear support for it and a timeliness concern, we'd like to see if we can get to a consensus to move forward with it.

2. A call for adoption on the WG list of draft-wkumari-dnsop-alt-tld-06, and further discussion on the list to the operational questions mentioned above. We're all aware this isn't a complete solution to the perceived demand for special use names; can it be used to make the situation notably better?

3. Further discussion on the WG list of draft-chapin-additional-reserved-tlds-02. Given that we don't currently see consensus to move forward with it, and the support for it seems widely fragmented among technical and policy-based reasoning, we'd particularly like to see any NEW input on:

* What is the specific operational impact being sought by adding these names to the special use names registry? Is the goal to have an impact on anyone besides ICANN?
* Some of our discussion so far has suggested that there's a difference between basing a decision about a special use names delegation on intended use in a new protocol, such as .onion, and basing such a decision on unknown and unspecified use, perhaps particularly within the DNS. In the interests of evaluating future such requests that might also not be based on a specific protocol use, is there a bar we can set besides the discussion in the current draft of inferred name collision risk?

4. It's been pointed out that the maintenance of the special use names registry is complicated by the fact that people used to be able to assume the root zone was relatively stable, and this assumption has become less defensible. (ICANN is not currently accepting new applications for TLDs, and has no announced schedule for opening an application window again, but has said they plan a future application round.) Is there something that the IETF should be doing to help DNS implementers and operators handle this change in the environment?


thanks,
Suzanne and Tim
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Tim Wicinski | 15 May 20:53 2015
Picon

Interim DNSOP WG Meeting - initial minutes

Here are the initial minutes of the Interim meeting on Tuesday.  I went 
back through to make sure I didn't drop some comments on the floor (I 
still may of).

https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/minutes/minutes-interim-2015-dnsop-1

If you have any updates or corrections, please drop us a note.

Big thanks to Suzanne for pulling this together.

tim

----
Interim Meeting  2015-05-12

Slides: 
https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/slides/slides-interim-2015-dnsop-1-0.pdf

Notes
-----
Suzanne Woolf (sw): Note Well, Agenda, etc. 

Basis of conversation in 2860 ICANN has policy over DNS Root, IETF has responsibility for "assignment of
domain names for technical uses." 6761 expands on this.  Responsibility where DNSOP is here - came about
from rechartering.  

Areas of Concern
----------------

- Operational Questions

    * 6761 has 7 criteria, "new functionality"
    * Other characteristics
    * Special Use Names are *not* TLDs

- Policy around Name space

    * is coordination needed? 
    * policy goals are not always technical ones.

onion draft:
    * CAB forum one thing; installed base. 

reducing leakage

unknown(uk): CAB Forum objective; reducing leakage is another 

Peter Koch(pk): adopt the document not necessary per 6761. 
pre-occupation conveyed reduced 

Dan York(dy): process question: 

sw: overview, then 45-60 minutes for discussion on drafts

Warren Kumari(wk): Follow up to Peter. If WG adopts and WGLC more likely IESG do their part, or not? 

sw: we don't know. Process should follow, not Lead

chapin draft: aka "home/corp/mail"

 - delegate due to risk of 'name collision'
 - ICANN 'deferring indefinitely'

alt draft: 
    discussed several times, well known
    will this work

other drafts:
    p2p: multiple names, WG seems to want to separate them
    lewis: use the extra 2-letter strings
    homenet: another proposal for .home

next steps:
    within the charter; AD is supportive
    timeliness constraint on the .onion

onion: 
    seems straightforward - adopt? 
alt:
    could help with scalability
chapin:
    appears policy based
longer term:
    how high should the bar be?
    update 6761?

Jonne Soininen(js): ICANN liaison.   alt allows for others to experiment and saving a potentially scare
resource. 

Ted Lemon(tl): not always a scare resource based on combinatorics. not a good use of ietf resources to argue
about TLDs, hence .alt is a good idea

Richard Barnes(rb): alt is a good solution for the future, but does not solve the .onion problem. 

sw: .alt is useful for experimental but not in the immediate

Hugo Connery(hc): .alt is a good idea as an idea. onion have a large deployment base. do not delegate names,
but also operators to not answer / nxdomain

pk: possibly mixing issues.  RFC6303 is a registry for local names already. instead of .alt, why not use
.invalid (2606)

dy: app developers aren't paying attention to the TLD space. go with .onion 

John Levine(jl): wide use of .onion, should reserve 

sw: clarifying question: 

jl: someone could "gin up" a plausible but fake community for .<something> to shake down an applicant, but
is hypothetical.

tl: agrees with previous speaker

Lars Liman(ll): really carefully with using installed base as basis. could introduce denial of service.

js: home/corp/mail - not necessarily use of 6761. what is the bar, .onion already passes the bar. reserve if
risk of collision. can easily get into policy questions if we look into wrong names and we should not be.

Andrew Sullivan(as): distinction made on the mailing list between protocol and policy. should make the
distinction, and if we do, then punt special uses that are attempts to carve out dns back to the root zone and
special names additions are just for new functionality. 

dy: asking us to adopt? 

sw: no adoption during this call. that will be on the list. gauge interest.

Tom Ritter(tr): using installed base as metric. can be gamed, doesn't mean we can't require a fairly high
bar. https://metrics.torproject.org/ 

uk: agree with past comment on installed base. trying to prevent leakage in public space. there is time
pressure and existing installed base.

tl: topic of user base for allocation special use names. .onion is a good use case. large installed base not a
good test. MoU and what can we do about it.

sw: some discussion with policy names in reserving names vs protocol shifts

wk: don't want to become an ICANN. 

pk: Andrew Sullivan going in the right direction. IETF should not make itself to "policy laundering".
ICANN should take responsibility. 

uk: to warren: do we need an RFC for an exception? circular argument. similar to IANA code point. 

wk: people are underestimating the amount of pent up demands in the ICANN space, even in preventing others
from having a TLD. 

Mark McFadden(mm): policy component. chapin-draft is more operational and engineering, and not policy.
policy and protocol component missing operational stability component. 

str4d: a developer of I2P. would not have an issue using .alt if starting now. 

dy:  key point is strings to reserve because of impact outside of DNS. .onion is perfect example.

Paul Hoffman(ph): speaking of engineering. wants to take off table the root server leakage. gaming has
happened. other operational and engineering criteria

rb: determine auto-generated traffic vs organic growth

ph: was not saying we could not tell, people who thought we could not tell would start flooding. 

uk: well-established and well-maintained technologies that want to be excluded from DNS. .alt proposal
creates opportunity. 

wk: disagree with Mark McFadden that the chapin draft was largely operational  

Lyman Chapin(lc): current operational case with the home/corp/mail names. use cases show operationally
problematic. thought it was useful that the IETF declare in an 'operating Internet' is stronger than the
policy interest in allocating names to people who pay money. 

wk: fully agrees. will resolve with Mark

sw: should be very precise on the operational impacts of adding names to the special use registry, but is not
sufficient.  need refinement of the operational impact of reserving or not reserving a set of names.

rb: supports moving .onion forward

Ray Bellis(rb2): let's get .onion and out there, get home/corp/mail out, move everything into .alt; and
close the registry.

dy: tell developers to use .alt, but developers will want to use their own TLDs because they can. 

rb2: which is why to close 6761 registry to prevent any more tld hijacking. 

str4d: dns has that central hierarchy, and if someone had the need they could get a TLD.  would contest that
I2P is 'experimental'

sw: seems like consensus on .onion. also strong feelings on how to untangle complicated questions. 
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
str4d | 15 May 17:48 2015

Re: Post-Interim considering the 4 proposals


Hugo Maxwell Connery wrote:
> Hi,
> 
> I include below the last of the 8 sections which are included in 
> the attached piece.  I offer this to the DNSOP list for 
> consideration in the existing 4 proposals for special names 
> registration.
> 
> I hope that people will read the full text, though you will be 
> bored by (and possibly complain about) the first section.

Thank you for this nice summary.

> 
> I welcome all comments/complaints.

My only complaint is regarding my previous comments at the meeting and
on the ML. I feel this text is starting to deviate in essence from
what I was trying to say (although I was probably not eloquent enough
at the time). For the record, I shall restate my positions clearly below
.

> 
> The entirety is 1172 / 200 / 3 (words / lines / pages).
> 
> Regards, -- Hugo Connery, Head of IT, DTU Environment, 
> http://www.env.dtu.dk
> 
> -- last section --
> 
> More Commentary and Even More Personal Opinion
> 
> I believe that the grothoff and appelbaum drafts are the first 
> cases of testing the mechanism for the use of the special names 
> registry.  I also assume that the registry was created to be used 
> for more than its initial propulation with things like .local and 
> .invalid.
> 
> Additionally, I agree with some members of the DNSOP community
> that names matter.  "my-product.invalid" is not a good way to start
> a venture.  Should .alt be available "my-product.alt" is far 
> preferrable as confirmed by a member of the I2P community both at 
> the Interim meeting and in later mailing list communication 
> (str4d).

You are right in saying that .TLD.alt is preferable to .TLD.invalid
from a user's perspective. But that does not automatically imply that
.TLD.alt is preferable to .TLD.

What I said was, if I were writing a new I2P-like application
requiring a non-DNS .TLD _after_ .alt had been accepted and publicized
as the accepted way of establishing non-DNS domain structures, then I
would use .TLD.alt instead of .TLD, because it would be far less
hassle (to get it reserved, as I expect having .alt would enable IETF
to more easily evaluate and accept reservations under it) for not much
additional work educating users. I would of course _prefer_ to use
.TLD on its own, but as an app developer I would take the path of
least resistance. Right now, that is to register .TLD under RFC 6761.
If .alt is accepted, it would be that.

> Indeed, that person claims that .alt would have been used if it
> was both available and understood.

I said that I2P would _probably_ have used it, had .alt existed at the
time as the accepted way of establishing non-DNS domain structures.
However, I want to ensure that these two points are abundantly clear:

* I am not one of the original developers of I2P. I was not involved
with I2P until years after .i2p had already been chosen and
established, so I cannot speak for what they would actually have done.

* Even if .alt does become available, I2P will not be transitioning to
it. (This has already been thoroughly discussed previously on this ML
around the P2PNames draft in general, and the .onion and .i2p TLDs in
particular.)

str4d

> 
> I have little concern for the corp request, but it gains weight by 
> having potential operational impacts in the DNS space.  As 
> mentioned I could not find a draft and thus have no knowledge of 
> its technical nature.
> 
> I think that the key decision is appelbaum.  It meets all criteria 
> which I list above.
> 
> If this request cannot be processed effectively, that lack of 
> efficacy throws into question the entire nature of RFC6761.
> 
> As stated, I assume that RFC6761 was well considered and that the 
> registry was intended to be ammended.
> 
> IMHO, the appelbaum (.onion) proposal meets all possible standards 
> for approval.
> 
> Finally, I wish to support the .alt proposal.  I believe that it
> is wise to create a "reading neutral" space for the 
> creation/testing/deployment of alternate name space communications 
> technologies, and in this regard I will quote Bruce Schneier from 
> his presentation at IETF 88:
> 
> "Second, target dispersal.
> 
> We were safer when our email was at 10,000 ISPs than when it's at 
> ten. Fundamentally, it makes it easier for the NSA and others to 
> collect. So anything to disperse targets makes sense."
> 
> 
> 
> _______________________________________________ DNSOP mailing list
>  DNSOP <at> ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
Lee Howard | 15 May 14:37 2015

FW: New Version Notification for draft-howard-isp-ip6rdns-08.txt

I¹ve revised based on the reviews and discussion on list.

Based on discussion, this informational draft includes discussion of
whether and how to populate PTRs. It includes some ways PTRs are used. The
recommendations are intentionally light, and I think reflect consensus.

There were a couple of comments I did not include:
The document still makes recommendations, but very carefully balanced
ones, reflecting consensus.
The discussion of privacy extensions is still terse; it isn¹t clear to me
what additional discussion is needed.
Someone suggested "do nothing" as an option; based on consensus, I have
kept "Negative Response."
I kept discussion of having the ISP secondary from the customer¹s primary,
since it¹s been suggested many times.

I thank everyone for their careful reviews and useful input.

I think this document is ready.

Lee

>On 5/14/15, 4:53 PM, "internet-drafts <at> ietf.org" <internet-drafts <at> ietf.org>
>wrote:
>
>>
>>A new version of I-D, draft-howard-isp-ip6rdns-08.txt
>>has been successfully submitted by Lee Howard and posted to the
>>IETF repository.
>>
>>Name:		draft-howard-isp-ip6rdns
>>Revision:	08
>>Title:		Reverse DNS in IPv6 for Internet Service Providers
>>Document date:	2015-05-14
>>Group:		Individual Submission
>>Pages:		13
>>URL:            
>>https://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-08.txt
>>Status:         
>>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/
>>Htmlized:       https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
>>Diff:           
>>https://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-08
>>
>>Abstract:
>>   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
>>   ADDR.ARPA information for their customers by prepopulating the zone
>>   with one PTR record for every available address.  This practice does
>>   not scale in IPv6.  This document analyzes different approaches and
>>   considerations for ISPs in managing the ip6.arpa zone for IPv6
>>   address space assigned to many customers.
>>
>>                 
>>        
>>
>>
>>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.
>>
>>The IETF Secretariat
>>

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Hugo Maxwell Connery | 15 May 13:28 2015
Picon
Picon

Post-Interim considering the 4 proposals

Hi,

I include below the last of the 8 sections which are included 
in the attached piece.  I offer this to the DNSOP list for 
consideration in the existing 4 proposals for special names registration.

I hope that people will read the full text, though you will be 
bored by (and possibly complain about) the first section.

I welcome all comments/complaints.

The entirety is 1172 / 200 / 3 (words / lines / pages).

Regards,
--
Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk

-- last section --

More Commentary and Even More Personal Opinion

I believe that the grothoff and appelbaum drafts are
the first cases of testing the mechanism for the use
of the special names registry.  I also assume that the
registry was created to be used for more than its initial
propulation with things like .local and .invalid.

Additionally, I agree with some members of the DNSOP
community that names matter.  "my-product.invalid" is not
a good way to start a venture.  Should .alt be available
"my-product.alt" is far preferrable as confirmed by a
member of the I2P community both at the Interim meeting
and in later mailing list communication (str4d).  Indeed,
that person claims that .alt would have been used if it
was both available and understood.

I have little concern for the corp request, but it gains
weight by having potential operational impacts in the DNS
space.  As mentioned I could not find a draft and thus
have no knowledge of its technical nature.

I think that the key decision is appelbaum.  It meets all
criteria which I list above.

If this request cannot be processed effectively, that lack
of efficacy throws into question the entire nature of RFC6761.

As stated, I assume that RFC6761 was well considered and
that the registry was intended to be ammended.

IMHO, the appelbaum (.onion) proposal meets all possible
standards for approval.

Finally, I wish to support the .alt proposal.  I believe
that it is wise to create a "reading neutral" space for
the creation/testing/deployment of alternate name space
communications technologies, and in this regard I will
quote Bruce Schneier from his presentation at IETF 88:

"Second, target dispersal.

We were safer when our email was at 10,000 ISPs than when
it's at ten. Fundamentally, it makes it easier for the
NSA and others to collect. So anything to disperse targets
makes sense."

An Insanely Brief History of DNS

In the beginning a set of non-country specific top level
domain (TLD) names are allocated (.net, .com, .org, ...) and
handed out to a collection of companies to provide 
registration.  Additionally, a set of county code TLDs
is handed out to country based organisations to allocate
names with the countries (.au, .ca, ... .za).

Name registration proceeds according to these fixed top
level domains through the registrars who are authorised
to provide registration.

It is determined that a process for the registration of
new top level domains is appropriate.  Thus, it may be
possible to register .tld or .impossible.

Additionally, a process to forward declare that certain
domain names are special and shall not be able to be 
registered is declared in February 2013 (RFC6761).  

Pervasive Monitoring

On 2013-11-06 the Internet Engineering Task Force (IETF)
at IETF 88 declares that pervasive surveillance is an
attack on the internet.

The IETF then forms and charters multiple working groups
(WGs) to create responses that mitigate the pervasive
monitoring threat

Overlay Networks

From at least 2003 (12 years ago) a collection of organised
groups produced applications that used non-DNS based name
resolution for internet communications.  The three examples 
which are later referenced are GNS (GNU Name System), TOR
(The Onion Router) and I2P (Invisible Internet Project).

All of these systems created a network which does
not use DNS name resolution but does use other
internet communications protocols as standardised by
the IETF.  Their reluctance to use the DNS for name
resolution is possibly due to its unencrypted public 
leaking of name searches.

The IETF working group DPRIVE are mandated to produce
solutions to that problem.  DPRIVE was chartered on
2014-10-17 (more than a year after IETF 88, and certainly
well after GNS, TOR and I2P).

Special Names

On 2015-01-24 draft-grothoff-iesg-special-use-p2p-names-04
is published and requests the classification of special
name status for 6 TLDs associated with the 3 overlay 
network projects listed above.

On 2015-04-14 draft-appelbaum-dnsop-onion-tld-01 is
published which requests special name classification
for only the one .onion TLD which is associated with the
TOR project.

Both of these drafts precisely follow the process specified 
in RFC6761 for claiming special name classification, and
are clearly acceptable within RFC6761 as they distinguish
their differences from the standard behaviour in the
7 categories which RFC6761 specifies must be listed and 
described.

Parallel Issues

As the above drafts are considered by DPRIVE and
DNSOP (an IETF working group on DNS operations) two
other considerations enter the mix; the special name
registration of .alt (draft-ietf-httpbis-alt-svc-02)
to create a legitimate place for these types of overlay
networks to be created/tested/deployed in the future, and
the special name registration of .home, .corp, and .mail
(with the later addition of .lan).  I could find no
official draft for the latter and use the short name 'corp'
to refer to it below.

[DNSOP] Interim DNSOP WG meeting on Special Use Names

On 2015-05-12 a meeting is convenced by DNSOP to 
consider the above special names applications.
What follows is an extremly brief (and thus heavily
edited and biased) unofficial summary of what
the author gleaned from that meeting:

* the IETF (and specifically DNSOP) does not wish to
  be a clearing house for special names consideration.
  From this flows the desire for an objective, measurable
  method for determining validity of special names claims
  to expidite the process and reduce verbage.

* DNSOP wishes to make claims individually, rather than
  in bulk.  Thus, the grothoff draft is rejected (or at
  least unprioritised) on this basis

* There are two parallel assessment conditions: will 
  action or inaction cause detriment to the operation
  of the internet at large (i.e have significant impact
  on any major component of the internet -- in which 
  DNS is one), and does the application have technical
  merit.  In the second condition the concern replicates 
  that of RFC6761 itself, in which it states that if the
  application has no effects on the 7 listed categories
  and could be achieved by the standard registration
  process, that should be pursued.

* the .alt registration creates a future path for 
  non-DNS name resolution systems and this in turn 
  provides a path for DNSOP to not have to re-consider
  the potentially complex discussions involved in 
  special name registration for non-DNS name resolution
  overlay networks.  i.e "they started with .alt
  and all seems well managed/operational, so fair
  play by them".

A Categorisation of Request

Below I categorise the 4 requests (grothoff, appelbaum, alt
and 'corp') according to issues that were raised in
the Interim DNSOP WG meeting described above:

* uses non-DNS as a name resolution mechanism or not 
  (non-DNS?)
* single claim (one TLD only) (1?)
* is deployed, operational and managed or not (Works?)
* issuance of request will protect the privacy of end 
  users or not (Priv?)

For each category I respond with Y (Yes), N (No), or NA 
(Not applicable/
cannot be known).

Request  non-DNS?  1?  Works?  Priv?

grothoff    Y      N     Y      Y
appelbaum   Y      Y     Y      Y
alt         Y      Y     Y*     Y
corp        N**    N     Y      Y

* Works if defined and then people start deploying to it
** Local DNS resolvers should respond, but not the root

More Commentary and Even More Personal Oppinion

I believe that the grothoff and appelbaum drafts are
the first cases of testing the mechanism for the use
of the special names registry.  I also assume that the
registry was created to be used for more than its initial
propulation with things like .local and .invalid.

Additionally, I agree with some members of the DNSOP
community that names matter.  "my-product.invalid" is not
a good way to start a venture.  Should .alt be available
"my-product.alt" is far preferrable as confirmed by a
member of the I2P community both at the Interim meeting
and in later mailing list communication (str4d).  Indeed,
that person claims that .alt would have been used if it
was both available and understood.

I have little concern for the corp request, but it gains
weight by having potential operational impacts in the DNS
space.  As mentioned I could not find a draft and thus
have no knowledge of its technical nature.

I think that the key decision is appelbaum.  It meets all
criteria which I list above.

If this request cannot be processed effectively, that lack
of efficacy throws into question the entire nature of RFC6761.

As stated, I assume that RFC6761 was well considered and 
that the registry was intended to be ammended.

IMHO, the appelbaum (.onion) proposal meets all possible 
standards for approval.

Finally, I wish to support the .alt proposal.  I believe
that it is wise to create a "reading neutral" space for
the creation/testing/deployment of alternate name space
communications technologies, and in this regard I will
quote Bruce Schneier from his presentation at IETF 88:

"Second, target dispersal.

We were safer when our email was at 10,000 ISPs than when
it's at ten. Fundamentally, it makes it easier for the
NSA and others to collect. So anything to disperse targets
makes sense."


Regards,  Hugo Connery


_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
str4d | 15 May 01:26 2015

Re: Interim DNSOP WG meeting on Special Use Names: some reading material


Ted Lemon wrote:
> George, I didn't get into your game theory because I think it's 
> irrelevant.  The IETF process is not a fast process. If
> parasitical organizations decide to try to get the calories they
> need from us rather than from ICANN, I am pretty sure they will
> quickly learn that this is futile. It might briefly suck for us
> while they learn that it won't work, but I don't think so.   We
> already know how to deal with useless proposals.
> 
> So with that in mind, I think we really are free to do the 
> technically right thing without concern that it will encourage 
> badness in the future.
> 
> As to the topic of fairness, that is inherently political, and we 
> should steer well clear of it. There is no way we can reach 
> consensus on it, and whether you want to admit it or not, by 
> advancing the argument you are advancing, that is what you are 
> asking us to do.
> 
> What you are saying is a really good argument against us reserving 
> names simply because they have been squatted on.  I agree we
> should not use that as a reason to reserve a special use name.
> ICANN already has a process for that    If we want to reserve a
> special use name, we should have a technical argument in favor of
> doing so.
> 
> But in the case of .onion, .corp and .home, we _do_ have such a 
> reason. So there is no need to resort to the argument that these 
> names should be documented in the special use registry because
> they were squatted on.
> 
> If .onion were being proposed today, and had no previous 
> implementation, its proponents would rightly be arguing for
> .onion, not for .onion.alt, because how names read _matters_, and
> it makes sense for .onion to be a special use TLD, as it does for
> .corp and .home.

In the virtual meeting, I stated that if I was developing an app like
I2P *now* that needed a non-DNS TLD, and .alt existed, I would use it.
I should clarify that I would certainly prefer .TLD over .TLD.alt,
because I agree with Ted that how a name reads matters. But, if there
was an _easy_ process for securing .TLD.alt, _and I knew about it_, I
would probably opt for that. It isn't as pretty, but it's not much
harder to educate users that .TLD.alt is the special identifier for
this new app that it was to educate users back in 2003 that .i2p is
the special identifier for I2P addresses.

> 
> DNS has had a long run as the only name database that is taken 
> seriously on the Internet, and so we no longer think of names as 
> being something that has an existence independent of the DNS 
> hierarchy, but that is not an inherent truth of domain names. It
> is just the status quo. I would not want to have to use a
> different name hierarchy designator in order to use mDNS, and that
> being the case, I don't think you can make the argument that .onion
> is qualitatively different from .local.

+1. The "domain name" is a concept that pervades all internet-using
applications now, and any alternative non-DNS naming system that wants
to maintain interoperability with existing apps is forced to use it.
That is the primary reason why I2P chose .i2p and (IMHO) Tor chose
.onion. The biggest barrier to the rise of hidden services like what
I2P and Tor provide is content availability. If the I2P and Tor devs
had needed to re-implement _every_ client application they wanted to
work over their networks, neither network would be as large as they
are today.

That doesn't mean that new application developers should not write
network-aware applications, or that existing applications can be used
without any potential for privacy-compromising leaks. There are
definite technical and usability benefits to an application setting up
its own I2P tunnel. But it is much easier to e.g. run "TZ=UTC git", or
point an I2P server tunnel at Apache and configure vhosts, than it is
to implement network-level support. Moreover, supporting a non-"domain
name" system would very likely require extensive, expensive
modifications throughout the app to e.g. remove any and all
dependencies on gethostbyname(). The Tor Browser bundle is IMHO
testament to this - its developers have added a slew of
privacy-enhancing patches, but the browser still handles "domain
name"s in the same way as upstream Firefox does.

str4d

> _______________________________________________ DNSOP mailing list
>  DNSOP <at> ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
rfc-editor | 13 May 23:13 2015

RFC 7535 on AS112 Redirection Using DNAME

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7535

        Title:      AS112 Redirection Using DNAME 
        Author:     J. Abley, B. Dickson,
                    W. Kumari, G. Michaelson
        Status:     Informational
        Stream:     IETF
        Date:       May 2015
        Mailbox:    jabley <at> dyn.com, 
                    bdickson <at> twitter.com, 
                    warren <at> kumari.net,
                    ggm <at> apnic.net
        Pages:      16
        Characters: 31730
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dnsop-as112-dname-06.txt

        URL:        https://www.rfc-editor.org/info/rfc7535

        DOI:        http://dx.doi.org/10.17487/RFC7535

AS112 provides a mechanism for handling reverse lookups on IP
addresses that are not unique (e.g., RFC 1918 addresses).  This
document describes modifications to the deployment and use of AS112
infrastructure that will allow zones to be added and dropped much
more easily, using DNAME resource records.

This approach makes it possible for any DNS zone administrator to
sink traffic relating to parts of the global DNS namespace under
their control to the AS112 infrastructure without coordination with
the operators of AS112 infrastructure.

This document is a product of the Domain Name System Operations Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Gmane