Re: [DNSOP] Special Use Names Summary

[hellekin]

On 10/07/2016 08:56 PM, Tim Wicinski wrote:
> 
> Special Use Names Summary
>

Hello DNSOP WG,

I let a week pass so that others can comment, but apparently this
summary didn't bring much of them.  Indeed I have a troubling issue with
it: how is that actionable?  IOW, what's next?

Thank you,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[hellekin]

On 10/07/2016 06:36 PM, Alain Durand wrote:
> 
> However, there is something that can be done before: provide a safe place
> in the DNS tree where people can exist without colliding with the rest of
> the tree. We can't prevent people from ignoring it and keep using whatever
> name they want, but at least we would have provided a way to play nice. In
> that spirit, efforts like .alt and friends are a step in the right direction.
> 

We have .example and example.* for documentation, yet the XMPP
documentation uses shakespeare.lit (I don't think .lit matches any SUN
or any entry in any DNS-related RFC.) FWIW, wikipedia sends .lit to some
Microsoft file extension.  One cannot say that Peter St Andre is
ignorant of IETF processes.  Use of *example* in documentation and
.invalid in free software is a good sign that developers are ready to
follow suit and respect the norms.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[hellekin]

On 10/06/2016 09:22 AM, avri doria wrote:
> 
> As for the so-called toxic waste names (i really find that terminology
> problematic)
>

I agree it's a problem to use that kind of vocabulary to convey a
technical context.

> the so called waste pile of usurped names
>

Therefore this is also a problem to call names-used-in-the-wild
"usurped" or "squatted", because it says that there's a central body
that assigns names, and it defines who can use them, with the
exclusivity of any other approach.  I know this idea may sound funny to
a lot of people given the missions of IANA and ICANN, and the existence
of trademarks and so-called 'intellectual property', but to me, having
an authority over who can use what names *in general*--as opposed to
particular, specific cases (e.g., trademarks)--is akin to the Novlang
Committee.

Names in the DNS are sanctioned by IANA/ICANN, and those names are
'legitimate' in the context of Internet names.  That doesn't mean at all
that names not sanctioned by ICANN are illegitimate, or that names
covered by trademarks are more 'legitimate' than 'unprotected' names.
This is all a matter of transactions and legal-firepower.  But from
there to legitimate this transactional-belligerent perspective over any
other (historical, cultural, incidental, ontogenetic, etc.) seems to me
problematic and abusive.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[hellekin]

On 10/01/2016 07:12 PM, Paul Wouters wrote:
>
> the IETF doesn't have the money for lawyers in that arena.
>
> [snip]
> 
> I do not think the IETF should create "Special Names" that conflict
> with the naming process which has been delegated to ICANN.
>
> [snip]
> 
> The IETF giving them .onion in itself has been a very risky decision. It
> was based on no Big Corporation having an interest in the string. With
> .gnu people did not feel as sure about that. I think that's part of the
> reason .gnu was not also going to make it like .onion. These decisions
> are quicksand.
>

Thank you for verbalizing that.  Had it been done earlier, I'd have
joined a commercial letter of interest of the GNU corporation who sells
snowboards to the RFC as an appendix, in order to make a precedent that
a technical document can be vested or vetoed by private interests based
on legal risk and self-censorship.

Given the recurrence on this list of the term "squatting" to refer to
real use of a non-ICANN-sanctioned TLDs, and the assumption that people
should be aware of IETF and ICANN processes and avoid using such names
in the first place, that transpired in many negative comments of P2P
Names, why not consider that corporations, being 'people', fall into the
same bag as ourselves, and should be aware that there have been such a
process going on for 3 years already, and they didn't claim anything
about thoses requested TLDs, which shows *no prior interest* in doing
so.  I wonder what kind of court would accept a post-delegation lawsuit
in these conditions.

Nevertheless, I take note that finally, someone put that on the table
clearly and honestly.

I'd like to finish on the note that nothing in RFC 6761 *tells* ICANN to
reserve a name.  Instead it reaffirms that

   The IETF has responsibility for specifying
   how the DNS protocol works, and ICANN is responsible for allocating
   the names made possible by that DNS protocol.

In RFC 2606, IANA considerations say:

   IANA has agreed to the four top level domain name reservations
   specified in this document and will reserve them for the uses
   indicated.

So, even if the IETF reserves a name, it is more like a suggestion for
ICANN to ponder.  Maybe this should be clearly stated within the problem
statement and following materials to avoid IETF self-censorship to avoid
a legal threat.  As a person, I'm not too keen on the idea that someone
could sue something just because they can.  That's a very late-20th
century U.S.American notion that is not particularly welcome in the rest
of the world, and secret corporate courts suing government or other
institutions in the name of 'free trade' sound like neo-colonialism.  So
for good measure, *at least* one step to solve 'the problem' would be to
make it clear that the legal responsibility goes to the big guy in the
room, in our case, as for precedents in relevant RFCs, IANA.  If this
legal risk argument is the main show-stopper, I suggest it's vaporscare
and *not technical*.

## Reminder

The introduction of RFC 6761 gives its scope:

   However, "Reserved Top Level DNS Names" [RFC2606] does
   not state whether implementations are expected to treat such names
   differently, and if so, in what way.

   This document specifies under what circumstances special treatment is
   appropriate, and in what ways.

Regards,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[hellekin]

On 09/27/2016 02:37 AM, Warren Kumari wrote:
> 
> My opinion really doesn't matter, but I happen to think that, at this
> point, we should evaluate the requested P2P names according to RFC
> 6761  -- you followed the process in effect *at the time*, and jumped
> through many hoops. The process is far from perfect (see
> draft-tldr-sutld-ps) but that *was* the process at that point, and so
> your drafts should (IMO) be evaluated against that. If the IETF had
> been able to quickly and clearly come to consensus that the process
> was broken, and what to do to fix it, I might feel differently, but
> changing the rules retroactively feels unfair.
> 

Thank you for your clarification.  Indeed the discussion was long ago
and details slipped from memory.

> Interestingly enough, just above that mail, Stephane also objected to
> "pseudo-TLD", but we asked the WG for a better term and (IIRC), didn't
> get any better suggestions:
> "Can you suggest a better term (noting that this term is used in both
> RFC6761 and draft-grothoff-iesg-special-use-p2p-names-04)?
> They are things that look like TLDs when leaking into the DNS context,
> but are not actually TLDs.
> 

I remember introducing the term 'pseudo-TLD' in the P2P Names draft and
doing a similar research as the one I cut from your message for brevity.
 At the time I thought the Canada Dry effect would work: it looks like
DNS, it tastes like DNS, but it's not DNS, hence 'pseudo'.  But indeed
that can as well bring confusion.

I have no alternate suggestion at this point, but I have one to avoid
talking about "squatting" names: "using names without ICANN sanction".
It may be longer, but it's more accurate, and doesn't conflate a
legitimate but often criminalized practice with a fact of usage that can
stem from many reasons, one of them being the need of humans to name
things. Using names without ICANN sanction also speaks to people who
don't know why it's a problem, and places it in the correct context
where the problem can then be solved.  Except, of course, if that
particular name represents a technical issue ;o)

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[hellekin]

On 09/12/2016 11:57 AM, internet-dra...@ietf.org wrote:
> 
> 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 of the IETF.
> 
> Title   : The ALT Special Use Top Level Domain
> Authors : Warren Kumari
>   Andrew Sullivan
>   Filename: draft-ietf-dnsop-alt-tld-05.txt
>   Pages   : 10
>   Date: 2016-09-12
> 
> Abstract:
>This document reserves a string (ALT) to be used as a TLD label in
>non-DNS contexts or for names that have no meaning in a global
>context.  It also provides advice and guidance to developers
>developing alternate namespaces.
> 

Finally I read this draft after I realized the presence of this "or" in
"... in non-DNS contexts *or* for names that have no meaning in a global
context."

I must apologize for staying on
https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-04 and not
reading anymore of this draft, as it was explicitly stating the following:

"The ALT label MAY be used in any domain name as a pseudo-TLD to signify
that this is an alternate (non-DNS) namespace."

And:

"Currently deployed projects and protocols that are using pseudo-TLDs
(for example, the ".onion" pseudo-TLD (and other labels in
[I-D.grothoff-iesg-special-use-p2p-names]) are encouraged but not
required to move under the ALT TLD.  Rather, the ALT TLD is being
reserved so that future projects of a similar nature have a designated
place to create alternate resolution namespaces that will not conflict
with the regular DNS context."

Yet, this explicit recognition of existing name requests for P2P systems
was removed from the next draft on, and is obviously absent from the
current draft-ietf-dnsop-alt-tld-05.txt, which implicitly declares the
special-use names of P2P systems as falling under .ALT.  Since this
draft is reserving the .ALT TLD using RFC6761, and there's an ongoing
discussion about this RFC to figure out a proper way to use it, update
it, or dismiss it, I find the situation unacceptable.  Please correct me
if I'm wrong, but it really seems to me that this is the case, and that
the .ALT draft, which wasn't meant to threaten the history of the P2P
names, indeed became a way to easily dismiss any further discussion
about them.

Regards,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[hellekin]

On 09/21/2016 11:30 PM, George Michaelson wrote:
> None of these named spaces would "fail" to work as sub-spaces of .ALT
> or .arpa or any other community-led IETF tech community managed label.
> 

All of them with a requirement for global uniqueness will fail with
.ALT, per .ALT draft.  Etc.

> you are bringing an assumption to the table: all things of world scale
> do not have to exist at the top of the worldwide name space.
>

I don't understand what you mean.  We come to the table saying: the
globally unique namespace of the Internet needs to recognize non-DNS
ways to resolve names, that are by technical design incompatible with
the delegation model of the DNS.  The way to do that, according to
RFC6761, is to put these non-DNS TLDs into a registry that tells DNS to
always send NXDOMAIN to tell the systems: no, that does not resolve with
the DNS.

> because its not at root a technology problem: its a name problem.
>

I think we have both.  The technical aspect I just formulated.  The
naming aspect so far boiled down to "Why X and not Y?", which indeed, is
not entirely technical (and the answer is: because it occurred like
that, and there's no name collision.)

Regards,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[hellekin]

On 09/22/2016 12:31 AM, George Michaelson wrote:
>
> what community burden is taken in the wide, if a new TLD is
> allocated in 6761 to break out of the DNS.
>

I'm sorry but, what do you mean 'to break out of the DNS'?

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/20/2016 08:57 AM, Suzanne Woolf wrote:
>
> In a real sense the question at hand is a very practical one:
> “Which of these documents do you think needs less work?"
> 

Having read both drafts, and from the perspective of "Names resolved *
with an agreed non-DNS protocol", I agree with Avri that they can be
complementary, and find draft-tldr-sutld-ps-04 to "need less work".

This despite my other message which situates the problem space out of
these two drafts.

Regards,

==
hk
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJX4xUEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9gckP/AtTeoArzbW/yB9HbfLVE0BI
MEAZlaETW22K2axs+h9Xg0Yge0F0vmmUqRZMZ7rF0UegppZra0M5biF2RxAxFN7n
2iw/Jz0xmq+5TjCzc6SoBvOL8DUbFIbl2auD3F/E/zbvaHEZU240xq+PCv7018KB
aApWdLH+/dMb3xZwmXunOm4gzxwD3TyZcYTRRnTN+7Y+SGXRdoeoC0h8Qs4QSdle
VHofvLvNreCd2sUP41YjsI4Frz9SDtBHaBJds4R/0iUiPTUgOU5+qygRpfPKckVB
sp6kq0ZPOxRAC3h46+vCfOoCpJmkTtV7XdDv8plGHNK7XayVmQepdoCJt8IQYDdu
Fnt+MhND+h3rihkLzL/Hxpr9cNWybIdiP8szdvHW9Cvt6LD/uH5nLUq9fIDkurS4
ju/CKWsQnHMgrQM5tJfnwXFDERfMpP1rzNrfRQsJVtvF+MNjN3AmCNYFivgQcKyO
A5cfreYZ9J/hCaaL+E9wX25GIQY0TKxOwOTuaGgH4+ck1hqbF8+EHjrbQ942J4+2
3ip/aDj6FOhtpEA68FNJGiG+p1zkNp0S/CBHDWMcEozM6qaAErVa64N9B0jqCeWs
y5819q47/2RfAa+PaAmQKT5bRLiIxNpjRKJ4jvA/dfLvHE0rn8exeks8gjAC+Rle
81muRwDKNixMboVxalQz
=s4YJ
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote:
>
> And I'm still not convinced there is a problem to solve
> (unless the real issue is "how to prevent the registration of .gnu and
> .bit?")
> 

Even if I supported the SUDN of P2P systems draft mentioning both .gnu
and .bit, I see a great deal of difference between them. .gnu (and
.zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN
response from DNS, and use their respective protocols to resolve from
the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a
special case in our I-D because it proposes an alternate way of DNS
resolution, not using a delegated tree, but a blockchain.  With regard
to DNS, .bit is different from the other five, besides the political
effects of its specific approach (which I think should be able to exist
anyway, for the sake of Internet End-to-End principle if nothing else.)

None of the problem statement drafts took reference of the Special-Use
Domain Names of P2P Systems which initiated this years long discussion
that ended up with: should we revise or replace RFC6761.  In my position
of editor of this draft, I don't really care what happens to RFC6761,
but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and
.bit.  I don't think any of the proposed problem statement drafts
mention the perspective of actual P2P networks sharing their experience
and their existence, and coming to the table with the idea of abiding to
the IAB rule of a globally unique namespace.

We say: hey, look, we exist, and we want to say that these are not
transactional names: they bear cultural value.  They came from usage and
the history of the Internet.  The DNS should know about them, so that
people won't ever get into trouble trying to resolve non-existing names,
or trying to resolve eventually delegated names that will collide with
existing networks if they keep being ignored by DNS.

I had the time to appreciate the nuances that IETF members can find in
this seemingly simple approach, and try to generalize the issue: "what
if others come and do the same? Who's responsible? How to judge of the
legitimacy of those claims?" Etc.

But what's been going on, from my point of view of volunteer who only
has one life (that at least we share) and doesn't get paid for this
work, is choking-by-bureaucracy.  People whose profession is to sit on
IETF WGs can spend their time not solving issues, they still get food on
the table.  And so production of norms is an endless process, and if not
this one, another.

As I see it, the problem we're trying to address is whether these P2P
systems warrant some recognition from the Internet Community, is that
something we want to encourage, or is that something that belongs to
"the Deep Web", and we'd better leave that out of the picture?  I'm not
talking about .mail, .corp, and .home, that belong to another category
(I like "toxic waste"), or "people trying to circumvent IANA processes",
or "don't want to pay", or "don't want to follow process".  We did
follow process, once we realized there was one.  And suddenly, after a
decade, everybody realizes there's an RFC6761 that really shouldn't have
become an RFC in the first place, and this process is flawed, and we
don't know how to handle this.  But when the Browser Forum comes with a
deadline, consensus is easily achieved in no time, despite the draft is
flawed with idiotic requirements such as "Users are expected to...".

My take is that none of the proposed statement drafts took care of
situating the debate in its (recent) historical context.  The fear of
frictions between IANA and IETF have had more to do with how things
went, than actual ponder of the technical arguments put forth by the
various RFC6761-based drafts.  Case by case is not necessarily evil: not
everything can nor should be automated.

I believe that in the case of the 6 TLDs we asked for, there's little
doubt they make sense technically, historically, and culturally.  That
others may take it as 'a way in' and flood the IETF with stupid drafts
'just in case' seems to me the core of the problem, that was mentioned a
few times over the years, but didn't make it through the recent drafts.

> The rest of this email is about
> draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
> and no.
>

This is a great summary, thank you!

==
hk

-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJX4xScXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg95ckP/0/Ub0IPt7VQWBbjH914gbAP
v1fKjQhuMSUiuYa+KJ7AyYTvTjqH6+NgEx5T/1a5F+tcTlD7rEQ6C4UDYqUTqUBS
fa+H0i3sGkJT7it6vV5sjB9LTLb2Dmxff6uZkeBVtUbrun2Xl9uzBq9+rBloBQN0
5WDr2ykEbnTIBIM2bbBlhJSpHO6jhLgXhYQkWiFK+7c1zI2X3qNp6dlCnwJ9Gy7d
KNQNUMmBllAepF6kF0kXv07I8cEPjx9bRc6LY5wIW08Sa3j3R0UEtzBoUODFr/oJ
RbIq0bJgK8COZfEzEv6oJ1iDT64JXi2FxlPflBdqgFHiPQSX1Ermm1UtJU1Wrrcb

Re: [DNSOP] update on work item regarding special use names (RFC 6761)

[hellekin]

On 02/12/2016 01:48 AM, Suzanne Woolf wrote:
> 
> http://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
>

Hello,

This ID seems to require the definition of a new registry, and Section 6
to suggest how this would be used.  I think this goes way beyond what
needs to be done in order to revise RFC6761.  Another registry (for
protocol switch) is not solving anything.  Instead, whether the TLD
operates a protocol switch can be documented in the existing registry:
creating a new registry for this would only sidetrack the problem of
registering new Special-Use Domain Names without solving any issue with
RFC 6761.

*

Editorial notes:

In section 3, the term "impact" is used abusively to replace the
original "considerations".  Considerations are welcome, impact should be
avoided.

"[Answers to these seven questions] are inadequate for making the
determination whether a particular domain name qualifies as being
special in the first place." -> This statement should be followed by a
demonstration how this situation is factual, otherwise it's irrelevant.

Section 4 has a typo: "are par of" should read "are part of".

Section 4 may mention NSSwitch?

Section 4 has a typo: "we are actually building a catalog of all top
level domains that explain which are are switches." -> should read "that
explains".

"... has been discussed (.ALT)." -> Requires reference.
Note: .ALT does *not* apply generally, but only to those "alternate
domains" that *do not require global uniqueness* of names.

Therefore "If that architecture choice is made, some of the questions
listed in the sections bellow would become moot." is moot.

Section 5: "In the case of [I-D.ietf-dnsop-onion-tld], leakage" ->
Update reference to RFC 7686. (Also in Section 6.2.1)

Section 6.2.2: "For example, is large scale prior deployment an
acceptable criteria?" -> This is a bad example, as lengthy discussions
about it illustrate in the case of a peer-to-peer network where "large
scale deployment", besides being entirely subjective, is also
non-measurable.

Thanks for the "Pithy Quotes from History" :)


Regards,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ARCING BoF and mailing list

[hellekin]

On 01/28/2016 05:38 PM, Paul Hoffman wrote:
> Suzanne: Since you are one of the BoF initiators here, maybe you can
> clarify a few things.
> 
> - How does this relate to the other DNSOP work in this area such as .alt?
> 
> - Does this change the work of the 6761bis design team?
> 
> - How is it related to the INIP program
> (https://www.iab.org/activities/programs/names-and-identifiers-program/)
> in the IAB?
> 
> For those of us who wan to contribute work, but don't want to have to do
> it in three similar areas, having a clear statement of what is going on
> would be helpful.
> 
> --Paul Hoffman
> 

I'd like to know as well.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/26/2015 06:38 AM, Mark Nottingham wrote:
> 
> Given this context, I was disturbed to hear the design team presentati
on
> in Yokohama
>

So you mean there's an already working team on the revision of RFC6761,
and that team had the time to prepare a presentation, while the DNSOP
chairs didn't have the time to respond to volunteers nor to announce
this team.  This is simply unacceptable.  I concur that the revision of
RFC6761 should go to another group where "Internet community" makes some
sense and corporate dissent is not silenced by ignoring legitimate
requests.  Please don't expect any apologies from me for telling the
truth.  This is a carnival of an inclusive process.

Thank you Mark for the heads up.

==
hk

-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJWVvQ8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9ewoQALD1dF/Wqyh2Lo5qZ35PUANA
bvq2k5BZd1UsN488+V4v7PnAHxO7XgR8IQSYYnp1oYNaZl5WbFEPjT6HOSR3O4lr
7iSVeSxPux8hssSxorkWtBVk8oAnImGEPyIlYunBLcTyasXLY5+2fzmR1+P4/9Kk
ahjHvuQa6dOAXhqTMBizwb3kZ2PC2hFlM5LKMIBcf9GfTVmH//fbEalHYPYEwMCY
AvX9mkMvvWcWhn15OXRi50r3kQl65d0KQA2euQ8mUIe5qafDHASBtZLc81t0rAXv
fjaWT4REu+KUHexWKgI7NFF3uZ0M0Cm7imYN6+YG+AWFtPrr4SPh1BA0L4td93q8
bGxGEJrDTWRVaW2c98UO5bFxm3kqcM4oTdBD1Rg4yC1OatvuKzZp6nPrFG09G5rn
PjorrqoNx0MHxwejrTHkkhnmvmgTfPUTvkT/7zUYLTwRITDrjzOyj932COrZV+A3
dak5M5hRLhR8jswx/lh+SmY1RFAtCuNDcoFuXTOJygwSpj7WvigIORiT6ATLFlfW
mxYxkVP/Tc76anRTk5O/AIu87c5K9fr6TPiFRIL/0eKnFBEMn2qbaW7TLvAl6o89
kgYYp4u59ve0vCL6gE2sn1w1EYnctFVxpzcg9HkFl/MFuQyWdc4yb5OdFWW8sema
8hpTT/KiW1/KDHGj0kcB
=IZoh
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] 6761bis Design Team Lead

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/04/2015 03:26 AM, Stephane Bortzmeyer wrote:
> On Sun, Nov 01, 2015 at 03:06:04AM -0500,
>  Warren Kumari  wrote 
>  a message of 28 lines which said:
> 
>> The chairs also asked for volunteers for the design team on October
>> 8th; a number of people volunteered - it would be nice to know what
>> happened with that.
>>
>>
>> Sorry for sounding frustrated, but, well, I'm a bit frustrated...
> 
> Me too :-(
>

The request for volunteers was made one month ago.  Is there a design
team now?  It would be interesting at least to know how many people
showed interest in working on a revision of RFC6761.

(I see the pattern, every week someone new will ask, and at some point,
we'll have an answer :)

==
hk
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJWQN/tXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9R8EP/3Xox0Q/eDhm4reQtsCTaCkU
XkEyXbaiJZAH4+FVcpmYbvJkYbzaqa1AI1dbd1NG0dtlEwG2lf6kX6CYZXGn6jKy
o0gNMgiBQl3T5/EBuFy7y/s+nHMI9a1vBJ0lEaaek+Yqp5kUpTNJDGAuMg7ZwNA2
Fez83ANXv58w5h0Go+pRT6vebaEVqaid0Tqpg7Cj+8dNM5Z+H+hJmziTODpmKvjp
VgaRtjIhd2IWC+oRN2Muh+pnCzl4tnWnGjB0W15hpzIMRbY4d3pPymqZHCBopLS4
lbAuE+7uufCo3cWSiN8Ee2Jq6CUS6a7s/fgoY2uaeOIPEI3+v10tVmRMaEgnSdWr
vlOvT0wB5IR3Zh41Kl6Te91/olfroJHu04ZgENDryfe4ehFHJesWrZH+OSSIsNZz
8eeLTTg0hOiLvb43DAKiuja2jS7MSUyzOZnsegqz+6+NLyuwVFa/LVvINyu3x8vl
F3xThBuqEejncR36slv/+rBGyUF0xckZsYs4dQtJBlhkbssJo0uTztRkH3uiuDzR
hwFOF0TwJJjgS9y4V4xxvNazIWfSYc8zlZhGilmC3MaWiULe/W+TxuNnoeTPmwTJ
4jhgWDqhWWIa103xVkHjK5n0kCwTdyf8cVkWVBZcg0rugkSK9dAKioAZhvd/41e7
O7RBerPmG2wHh5eYkvJJ
=+C56
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/21/2015 11:50 AM, Edward Lewis wrote:
> 
> I think defining -whether- name.onion is a Domain Name will make us
> re-think how Domain Names interoperate amongst protocols beyond the DN
S.
>

Agreed, but why limit to .onion?  Can your example stretch to include
.bit, .i2p, .gnu, .zkey, and why not .exit?

In a recent private conversation it was suggested that as long as a
domain cannot sell subdomains it could be interesting to consider
(without affecting ICANN domain-name business).

Earlier we've been discussing P2PNames and came to the conclusion that
the term TLD should not be employed outside the DNS context, so I
welcome your draft to clarify this aspect.

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWAGo9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9iGIQAJClr7YvbUsiO5JmcJaThpJO
pjyA3AzY/+iuasj8zO/gXPHd+4wkROkvIRaT3y7A0+d02H5nE3BkeMbqeQNMsYXN
XE95DBqpqH9IEUkdAGtKCHQ4z8wrwVT4Lv1fPjhUiX7LnsdH7Y65Ujchasxt/Cd0
DY4SmN4q6BErsBXSLwsLoIpK3IhvDBkIAD6EqMA+6UvoNWx4rPt0ZfmD7j4KyWSV
gIsLweoaQRJCZvdjroxt/CVOfEuybdrOlfmFsnpWiwZ7lVmldJ7yL9Yl1Ps3IbTd
9ikU3brsGrT2ZzpyQRhL39vSCB81bU/e2l1t66igoOKNZBh2JViEboGXcs6DQ3oj
kNc6BAEAKL5onCHFHMQdEs66OytQ+mJrStoqHHJACbLL104emeFGpl1H4G92cRG4
mXdI03ctJTCbzOFYgPcYwnsOUFzUiB8wpnSmc6KDOyI1azQIh31IGo19sx78UG9z
HSzUtJt65WJ3L+Hp7853Ma6id3KUVkNyrvCgXKKz6nztuNy0CnSjVOlXXMB/ecvF
EOWVh9216gNdUZRg0MRGpb4FYkH6M6V8sL0ADEi+EXebKqWzVUUO7+/DDeLaqBLI
UNUbtw17LZcZ4/d0eLGM1EJYAgnrUl1aPyiWqRCjcT28AggBdWfqd+tjArFbVRa2
OnPBACcyGruzljwAWHTW
=tJJg
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-onion-tld-01.txt

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/09/2015 05:14 AM, internet-dra...@ietf.org wrote:
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/
>

I welcome the new draft.  I must have missed the discussion for this
passage at the end of section 2:

"Note that the restriction upon the registration of .onion names
does not prohibit IANA from inserting a record into the root zone
database to reserve the name.

Likewise, it does not prevent non-DNS service providers (such as
trust providers) from supporting .onion names in their
applications."

What would a DNS record about .onion in the root zone be used for?  How
is it important to mention what the document does not prevent?  I gather
the latter "non prevention" is to authorize SSL CAs to produce x509
certificates for .onion services.  Maybe this should reference the CAB
forum more directly.

*

The last line of Section 4 mentions: "updated to drop any request to the
".onion" TLD."

Wouldn't it be better to avoid using TLD in this context?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJV7/zlXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9GYAP+gLmub/TuFSwI0dUn1BD2Yan
at2YR+SoLwExhAcXsPlP+Rvrz5p8/5YsHZc0rWIhx7K5wuiso95fvmufMW2Q5qiP
zFWw2GTsgvoFkCJ8PrC2AJh9u0sZK+Qvo3xtPFXBHuDRl8+2Os5hy5CPX6+2wiyc
VylPD5PNy3yLaFz7IjALNq0qF7rjtKdUBkuoSCgLIAOzyZu8v9GWUClWLlJUSoZI
wHsUN0+3A+4Xj68uXJjWpA4I7jOCgfhdDwoIs+2/msEK77AL/3gkFgkRQHvidYOW
2mbLRQw6hyWrzVg7FTixCXjEtTgjEaY8GKcePxHfwLxONgmk/6lHcR9Qj96boKzC
EImoRh2OxOfa/Sa6n9D7HQKYmb2lY5eZiaAyYfPdMuZpKIZAPc2SQFBNP3I0Db3z
byu6T3xtOt+ORBLQRK+XGzj/7SvkFEdm+QJH254hzDzEHD2aKalzwn3ebOM76Udl
VOsJj0SpEkG2deALW1fOWH4M7CycJLsKHPWlWlk9eHaQP//cNdF90p9JJ6f6KMdD
mFD1ocJDCaJIlnzjLDZXBuBXbg3wsrIKidxLIgAv59QR9lZIVFLnZR1ZeHcJjJJd
IfdTQHy9PwjOp/YZOtC5ZyPbpeOMEnsyQoCzbwFWDhck+QCZChYj8AsOYPEWHMJg
fset/GuLJGzFny0wuKQe
=I37F
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/03/2015 11:36 AM, Joel Halpern wrote:
> Actually, DownRef won't  cut it as far as I can tell.
> 
> The two documents are not stable.  As a github reference,
> they are simply "the most current version of foo".
>

Come on, GitHub is a corporation, it has NOTHING to do with it.  Git is
a version control system.  An RFC falls to me exactly in the definition
of "the most current version of foo".  When something needs to be
amended, it is: that's what erratas and RFC updates and obsolescence are
for.  Please leave the strawman alone.

> What the onion folks said to me was that they were working on
> creating stable, referenceable documents that explained how
> this should work.  I understand there is a time problem due to the
> certificate.  As a reviewer, I don't see how you can register
> without a stable reference for the meaning of the registration.
>

The referenced Tor documentation does not affect the reservation because
changes in that documentation won't affect the principles set forth in
the relation between Tor and DNS.  These are orthogonal matters.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJV6F2EXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9xPkP/Ap/uXhU/+HrmZrJ6Bi2bWpS
2rOeIzUWmCB3NlZbK9SfkSVS0hzWtZ5G6C4sGHGegs1+D1O7T6Ow3R1UkI4tyYWP
Kf1AqWpNtP6uJLPR3qNgf9ukWFiBbupHwcInBmQc0fGuERuLLIAKXd2/J1o/1myW
Ryzh5yyWQbQ6zqHous9K5UKB1pEZVfNTK25ZZizSDoHVZoanmYBWwJLd2TvUd6aa
aCCbwCSalWij2OglXBSd59iZ2Z+amjuFQLjsmeUR9S3BFnkDuSTf6eaptrWBSoS4
OzirhaosmcfNNTS29LvjisS70Wdho3KpBOdU53Pg0aPwpSjJz1Zi1QH9+ne17hKF
EkiV+gg+Zh5eDV7vS42xBCFG2MXragJPlhJSt2sLZJ28+KYNNfj9iSMPdvA6IIa4
qHRDdeK4CYq76zOprXZ0SmQobt24GEhq7oN4rqunkzOHlTrTDT74ytsrcI/tYz/t
MGWNsXy1hTBzSEE97lQ6fBzAgIPWKu2DRjnHde4zHw7A8ZUvTUTsXDakrlOd67i0
E5szt1Xk4638DpzTwe7gNJx2I9NLvM711O9dkWIIGbsXDrxI3TZAzLRVbJIqkDEK
uzx5pBwWKWraJuNqXspN+xtuiePBhwxdskC7YZasTMveLXBPitiWPBKzQDXXSG5K
fRehZAbqT2xVqb7xR9cs
=sX8t
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/01/2015 07:39 PM, Jacob Appelbaum wrote:
> 
> Tor doesn't leak .onions
> 
> If the name is reserved and the process is followed, we'll hopefully
> be able to stop most of the leakage in the DNS.
> 

One clear example that was documented earlier is the "pre-fetching"
feature of some Web browsers that will request links on a visited page
"to accelerate the Web" in anticipation of the user's next move (which
sounds quite wasteful indeed).  In this case, if a page mentions links
to .onion URLs, a browser that is not configured to use Tor will hit the
DNS root with an inappropriate request.  On the contrary, if the browser
is configured to use Tor, no leak will happen because the Tor resolver
will take precedence over DNS resolution for .onion.

Once the RFC is available, browser implementors can add a filter for
.onion to their prefetching code.  They certainly don't need the RFC to
do so, but once it's RFC, it's more likely that they do it.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJV5jFpXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9n5sQAKRzvkBwJ/ibOoRlajG5AsRu
ACnykyUsP9aU2Hpv0kJFm7AvfKOy0gwHeYfWY/czjbvsC6X5sJ/Hoe+ZYUcPTwGQ
hjsug0m/F4htS4s6O5WbzLwc3506kmzw2PvyGzvJBpKZzgGU2gvn4H0JuVHemMXR
yNaQw21MFJIWOlhO0eshMr84SBoiaoO6IWEBjiITdtq1qsZNhPQRipn63r8VY2ul
mDTPSUcHvN4sblj2kiCCNVt0O8j6GhS3xc9H+EVe8Iz+Rk3hDbJtxBKZhSOZY309
YEjUhlkQ7CgmkTQa0fxEQsjSq3HSjLcfBCXkovCbt0i7ReEHP/YPr4cFtfWZIk7v
+Wnk1PuMI17SPnyglWiZxl3eLT0h4j4mxlrEAvT1TkeHmTu1CItTm9xcxuksdErS
3ncZPsUZAOObrw01tZVJ0YmF3kT4F5NE1ThlxrDIA9ygPT5cqgwAlXo+6thjff7y
dgaWi5swXYzzFh68KTgMxP8rWzItM+hV4k0SjYEXNVlYKLBKtUqFIaR0jNatVDN2
1Auy3p9+h+iw2DQnBDXtWMiQ6CprG/yn3yEsVueSobnwX8sNHHMRsIadifjAlh50
CnyYxb1BKuwkoJ61eHymKcDAD6Bz5i+gtpfEfBBxC5yzibQq8Dm/rNGMioyzz8k7
Bk6aSDSHHwq9P/0ZBxAb
=F5Fc
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 08/10/2015 01:50 PM, Ted Hardie wrote:
 ​
 It does a fine job with .example since that's fundamentally
 just a reservation, but .onion is showing its warts.


Hi Ted,

I fully agree with Alec, and do not understand how .onion would differ
from .example in that case, especially since as we're speaking, onion
names are fully compatible with DNS domain names, syntactically
speaking. Can you elaborate on the difference you see, and why should we
need to think forward to a non-existing set of future registries where
onion names could end up at some point if at all?

Regards,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/20/2015 10:34 AM, Eliot Lear wrote:
 So... Alec and I did a bit of wordsmithing and what I propose is a
 slight clarification on the existing text, based on this exchange, and
 here it is:
 
 
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain components.  Only the first first label to the
left of .onion is significant to the layer 3 Tor protocol, while
application layers above have access to the full name.  For example...

*** Like TLDs, .onion addresses can have an arbitrary number of labels,
but only the first one is significant to the Tor protocol. The full
address is still passed along to the services running on top of Tor: for
example, an HTTP server may distinguish www.anexampleservice.onion from
static.anexampleservice.onion, although Tor will only use
anexampleservice to route to this server.

Rationale:

- not sure subdomain components is any clearer (unless it was defined
in the recent DNS vocabulary draft)
- Tor is not a layer 3 protocol, moreover you can encapsulate layer 5
sessions, so it's not about application layers above either.
Introducing OSI layers in this draft would only bring confusion.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00

[hellekin]

On 07/19/2015 01:11 PM, Tom Ritter wrote:
 On 18 July 2015 at 04:25, Joel M. Halpern j...@joelhalpern.com wrote:
 Major issues: It seems to this reviewer that at least the definition of how
 to use these names, reference tor-rendezvous, needs to be a normative
 reference.  It appears likely that tor-address also ought to be a normative
 reference.

 Minor issues:  It is not clear that a github reference without version
 identification is sufficiently stable for a normative reference from an RFC.
 
 Hi Joel,
 
 hellekin started a discussion on the tor-dev list about getting a URI
 for the specs that can serve as a stable pointer to
 https://gitweb.torproject.org/torspec.git/tree/ and a version
 identifier.  So we're working on this.

*** And, it's done!

https://spec.torproject.org/ now hosts links to the future-proof URIs
for the Tor specifications.  Internet-Draft authors can now use:

- https://spec.torproject.org/tor-spec for the Tor Protocol specification
- https://spec.torproject.org/rend-spec for the Tor Rendezvous specification
- https://spec.torproject.org/address-spec for the Special Hostnames in Tor

When the IETF releases the RFCs for Tor specifications in the future,
existing IETF documentation will happily point to the correct documents.

Thanks to the Tor team for their prompt response!

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/17/2015 11:20 AM, Eliot Lear wrote:
 I have no particular objection to the concept here, but I do have a
 question about one sentence in the draft.  Section 1 states:
Like Top-Level Domain Names, .onion addresses can have an
arbitrary number of subdomain components.  This information
is not meaningful to the Tor protocol, but can be used in
application protocols like HTTP [RFC7230].

 I honestly don't understand what is being stated here, or why a claim 
 is made about HTTP at all in this document.  Are we talking about the
 common practice of www.example.com == example.com?  And what
 significance does that last phrase have to the document?
 
 Eliot
 

It means that when resolving .onion addresses, the Tor protocol only
checks the first label in the onion chain (e.g., facebookcorewwwi in
example.facebookcorewwwi.onion), ignoring any eventual label under that
(here: example). But Tor doesn't remove these labels: they're passed on
to the application at the endpoint.

For example, imagine Facebook runs https://static.facebookcorewwwi.onion
to serve images for their website.  To the Tor protocol, only
facebookcorewwwi is used to identify the onion service and find a route
to it, but once the connection is established between the Web browser
and the Web server across the onionspace, static.facebookcorewwwi.onion
becomes meaningful to the Web server.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVqRRNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9MaoQAIZvDEz9M1MT7ExyRPTGgiSy
Zdbqyclu80jHkomkXsDTdiBSpMeZ5h3i5txeeDg+qlxLguHj/+s+Bap0O9e6gVqc
l8ypZyntPVTYQgWvI8/vdLXHGn6TD0H+z9HTYEgIqJKY6cDOJfpVaGHw/gtYeM3R
IkVjXpsXP7/fyici1jHtAkA3j98yWOZWF28bY692CHEgCTJcwbL/GVdeYeUvHnHd
2C+uNdg7tN+EEDznWmq3zCQ9a2EDhRv8tXVMzFDx6Uce+cWQlXHFDbILhNE6GPXK
c2trDKQTIL+kSzyI77jQx7ONqvT/CqFClLvNchUPq3qX90VxCR3ZZIxxga+vxQR7
trxwnuJr+TZ9nECt1xeR8LZ4DDymVSsygdYrcvTGSPfIogZwWjL4B7oWKjH3CjPl
reSgq+eFYfIEyF3fHyrYhUCm3H8amMEqP5HArYi+WTnaZE86LkE5gFxxJhKDFhLT
gLkxSlLIsAuE8ozjzEbEWIsjUQEUahb7XroD39W97hhAXmvONkbvP45weZUbnYz9
sH7LpLJqzls3b255tjGgckO3voEC4BfJfx2EROx+m+m+MOMh/HaboEn0DUWK8gax
HDVOnnt8wcqG7sNvtIyDi8fYHf7UIDOY7I441shS8FNquKufnJ2M6QqUTIutU9Vd
DHA8mfKy+yS4KNYOZxXl
=6d6o
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/17/2015 11:32 AM, David Conrad wrote:
 
 No. .LOCAL was not already in the root zone. .FOO is.
 
*** Therefore the .FOO label is not available for Special-Use anymore,
end of story. A Special-Use name cannot be an already registered name in
the root zone.

If you referring to e.g., .corp that has proposals both for Special-Use
and normal ICANN assignation, this is a distinct issue, as the label is
not yet in the root zone, and there are good reasons why it would be a
bad idea to put it there (already existing name conflicts) but not
compelling (if the .corp registrar is ready to deal with the extra load,
or if capturing all the leaked requests from random devices around the
world is not deemed to pose a security issue...).  This is an entirely
different matter.

Now if there's a prior request for Special-Use and an ICANN registration
appears after the fact, that would be a problem: if someone would ask to
register .onion or .gnu today, we'd run into the problem you're suggesti
ng.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/17/2015 07:07 AM, Andrew Sullivan wrote:
 On Thu, Jul 16, 2015 at 11:39:24PM -0700, Paul Vixie wrote:
 we only need one cutout, something like .external, with an
 IANA-maintained registry of non-dns uses, each pointing to an RFC
 that describes as much as is possible to describe about that use.
 
 Why is an IANA-maintained registry a good idea?


The discussion is drifting away from .onion.

It's also drifting away from at least half the current applications for
Special-Use Domain Names, the half that technically CANNOT SHARE the
same registry, and that technically CANNOT BE ADMINISTERED by a third
party.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVqO7oXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9b6sP/0Bn4oayyhgCfdJtXAfkSl+2
OQTRxv24lUGYVZIB5dI1dWm3Fwjan/V7Lvwe9zam9lszWO/wi5Kb8HU5ZpP6ibf4
3HmRWRW7lhy4gzR4kuzWp8iPFhDzF+YWF3bmTRMdJi6Rgi0sff+yA7wMiUajM1yQ
lfHMnM2M+XgBJQBOikvKt3Y7ywsoo0XGp/gYSCl04tEL8hJ5pTpdcZlHt4XsAZbs
51yq7VinSUYxE9wHFdNEZZWcrro9Iy190Q6jvHOKn3fZKYDUqjdYygQ1X81Ditd6
xKSMz5tRNKTtjyZz6rJ6X6Gvo9CDgacoOcn646SpILodKApg+qCHY3+CF+sHclI6
K6TDepE3JxNvOxY6dWojeidIWsvSPx6jtUzRZ/vltza3PB31jipzkNjO2Vu5WNF8
3NURcIFw6dEex01Ws6ce4wGQcmoh10qBHXubY1X/06graUL5HXyTACPLwFvVIqRt
9XEIFQA+6sSA3SAIF5XZSV6MnsV3LKildmwN2QZxROa9WqM2W7wjPiTe8Vu97s/v
V/5Xk75Z5nWYm2l2o5bZNeWClREnFEMqSw+PxYkj08bgfJbRj37/m59VXSjrMVcr
tseujhtDgPZCUlH8uz3imfmOH6Jq4yJd0IlsqZXZLhsScUgBHvPU+4BmaSxYETq5
QU9wfOKJ4jSlj5ORtmDJ
=8LuS
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/17/2015 12:17 PM, Eliot Lear wrote:
 On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear l...@cisco.com wrote:
 I have no particular objection to the concept here, but I do have a
 question about one sentence in the draft.  Section 1 states:
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain components.  This information is not meaningful
to the Tor protocol, but can be used in application protocols like
HTTP [RFC7230].

 
 I just leave the IESG and WG with the comment that two of us old
 timers are trying to divine the meaning of those two sentences, and
 that can't be good for others with (even) less clue.  Personally I think
 the easiest approach is to remove those two sentences, but if others
 really disagree, then a bit more clarity seems in order.
 
*** Removing the sentences sounds fine to me: they're not relevant to
the name registration itself.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/17/2015 02:57 PM, Paul Vixie wrote:
 
 i would argue, by the way, that onion is a kind of technology, onion
 routing, of which Tor is the first and best-known but not the last. so,
 i'll prefer .tor.external over .onion.external.

 [snip]
 
 compared to alt, yes. note that .external is long on purpose-- to avoid
 conflict with nature.

*** By conflict with nature do you mean that having to type .external
with one thumb would strain it faster, leading to an obsolescence of
hand-held devices?

More seriously, does that mean you're opposing the .onion draft, or are
you simply drifting away to the later work on RFC6761bis? I'm asking
because the authors requested .onion, not .tor, nor .tor.alt, nor
.tor.external.  I suppose that if .exit was part of this draft, it would
make more sense why .onion and .exit instead of a single .tor. That
said, .tor would save more thumbs.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/17/2015 03:10 PM, Paul Vixie wrote:
 
 i apologize for the lack of a pre-existing syntactic framework into
 which tor's names could have been encapsulated from the outset. i
 apologize even more for the fact that tor's perfectly reasonable request
 for .onion is now causing this working group to consider scaling factors
 which tor by itself would not have cared about.
 
*** I apologize that you feel the need to apologize.

There's certainly a need to adapt RFC6761 to the realization of the
community of its transformational power. But it's unfair to put the lack
of foresight of the community that adopted RFC6761 on the people who are
using it, especially with good reasons.

I think it's important that the IETF recognizes that the free software
community of developers of peer-to-peer systems spontaneously came
together to approach the IETF and solve an operational issue of their
systems with the DNS, causing problems to the DNS and posing security
issues to the users of P2P systems.

This is a concrete example of the Internet community cooperating to make
things better. This has nothing to do with future issues of scalability:
it's a distinct problem that we have now and are trying to solve
together. We already identify that RFC6761 causes problems and that it
needs to be worked on, clarified, etc. But that should remain a separate
issue.

If there is an RFC and when people come to use it, suddenly it's not
valid anymore, because people realize in hindsight that it's flawed or
that oops, it's not what we expected, it poses a serious doubt about the
validity of the institution. The danger I see, much before a scalability
issue in DNS, is that developers who are more interested in running code
than rough consensus will simply run the code and ignore the human part
of the process, leading to a transformation of the Internet like
everywhere else in society: where cold reductionist views tramp the
human and leaves us outside of the living sphere, until we're redundant,
useless, uncared for bloodless servo-units.

I get the gravity of the situation. But I doubt that trying to fix the
issue by tying the existing applications to a non-sequitur by fear of
creating a precedent will achieve anything good at all. On the contrary
I believe that now the jack is out of the box, it's important to realize
that new applications will not be treated the same way that they were
until now, pending a new version of RFC6761 that updates or obsoletes
it; that among existing applications there are different cases, some of
which are pretty easy to solve (e.g., .onion) for they only seek to
prevent useless and potentially dangerous requests, while others are
more complicated because they involve ICANN processes, SSAC
recommendations, etc. (e.g., .corp, .mail, .home).

Treating all the Special-Use Domain Names requests as they were a
monolithic block did not work, and won't work (I'm talking from
first-hand experience given that this WG has postponed to death tackling
the single P2PNames draft), so it would be much more effective if we
would take one step at a time, and not project future conditions where
they do not exist yet and are likely to change drastically once RFC6761
is revised.

My 2 satoshi.

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/17/2015 10:41 PM, John Levine wrote:
 
 A mechanical criterion might be observable traffic from at least
 100,000 different IP addresses every day for at least 30 days.
 That'd be a horrible criterion, not least because it's easy
 for a modestly well funded adversary to fake.
 
*** Also, if I may, because it would not encourage developers of new
protocols to approach IETF early on if they already know there's not a
chance they will match the criteria; instead they will run the code, and
once they have a large user base come to IETF and say: hey, look, I
created a massive problem, do you want to fix it?.

(Completely agree on objective vs. mechanical)

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tor frustration

[hellekin]

On 07/17/2015 10:39 PM, Ralf Weber wrote:

 Am I right that there is leakage of dns requests with 
 .onion TLDs? If so isn't that a bug in their software?
 
*** Almost:

1) .onion is not a TLD (sorry, I made the mistake myself to abuse TLD,
although I had defined pTLD for that purpose--as in: pseudo-TLD, but for
consistency we're using Special-Use Domain Name there)

2) yes, leakage of requests for .onion names to the DNS is one of the
problems we're facing.

3) No, it's not a bug in the software, it's due to broken configurations
of the local resolver and applications wrongly sending .onion requests
to the DNS (e.g., Web browsers' pre-fetching feature)

 authoritative servers (who never would get a request for .onion anyway)

*** They could if there's no RFC to forbid it. Actually they could even
with such a document, but other actors would then rightfully decline
their non-NXDOMAIN response.

 This is the dnsop working group, so I'm not sure if I have
 to know TOR to participate here.

*** But to participate in a discussion related to Tor (not TOR), it's
useful. I refrain to participate in discussions where I don't know what
I'm talking about: I already have difficulties with the topics I think I
master. That said, participating is the best way to learn :)

 I'm ok with .onion being  a special name, but we should just do
 that by normal DNS mechanism. What's wrong with answering REFUSED?.

*** Refused does not mean that you're dealing with a non-existent name
(3 Name Error), especially one that is NOT in DNS.  It means that the
server refused to perform the request, but does not inform you of the
specialness of this particular .onion Special-Use Domain Name (RFC 6761).

 Answering NXDomain is much harder in a DNSSEC world.
 
*** Well, Tor is not in the DNSSEC world, it's not even in the DNS
world, that's the point of Name Error in that case, and of the draft in
question.

Regards,

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/15/2015 03:55 PM, David Conrad wrote:
 
 I'm intrigued how you derived an insult from my statement
 that it was squatting.


I guess that's the proximity of blunt and squatting that gave me
this impression.

 
 You're wrong.
 

I stand corrected.

 
 Indeed .onion can
 do without caring about the DNS, but this is not the point. The point
 is to recognize the variety of techniques within the scope of DNS so
 that future implementations can rely on the DNS as a correct source
 for global information about namespaces.
 
 So, I'm now confused.
 
 I thought the point of putting ONION in the Special Names Registry
 was to ensure that it did NOT rely on the DNS.


Sorry for being unclear. I meant: to recognize, within the scope of DNS,
a variety of alternate techniques (not using DNS but potentially
conflicting with it because from a user's perspective, there's hardly a
difference between this.example.sucks and facebookcorewwwi.onion)

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVp0GzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9MMsP+wYSAvO6FEq6ewPKQr8oSO8e
gZ+Xo6G0rV3oxmMBoDHCsjzs8ODZK5DxIhRNVpzAym9L9RGyRjMWD/iOq+X5hUMi
/9Miu6tln+TyT/fsa5Wq7IIyy3fWTLPdVikfbPx3+wFYKjb8dQOFYjPjKtC6p4g4
w8RzFeimzOKEDGhjfS5N1G45/A1jK3iFHVhjiSrYVo7W503BGByechTg+hsoB9qc
HheVWanwi25K9fdbl6XNoTt6NR0q7IeUlEmmYaNP08FeG31NS2GXP9goWsd8vjIn
zuP4m4kg/tFwbU2Sa/JWTik62cdzpTJDZrvvDFoKrL8lVzIM+2CWx69s7wPcWS65
tBTxy1RuED3Ky+7oiml2evSMOB5sQlOqjsqt9Gdv5ZssLkRVuY26XDEy20y5VxK6
1BwPRCUkoOfynT+cM12E+2ixGlVCcGNtDBQidAgeo6Jsz6iI7MgQbZXo9Sj76jVC
WMoxkqznlu2SGVSKzEhMVhtH8nsWRL4+rf2z/05ddHbIMfTLLGgf1iqY1T0OOYlZ
tLc8FSdA2P/W/ffNAYfFDJ86CZZJVwXX5VLDe04YjEEW+Fq+YLHmvUsp/u7R1a4n
ghGn33spuObvT9+2dZlCw2s82czAtOI9aig5BqNWccCVQ4vONda6MGlIohNAJ0eh
Xi8J1T4hvCmzD0uYOPqP
=VUOf
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/15/2015 03:46 PM, Edward Lewis wrote:
 
 What if I copied the onion draft, changed all of the uses of onion to
 carrot, and then threw in some supporting documents to describe some
 other system that used carrot as it's base identifier?  On the heels
 of onion's admission to the Special Use Domain Names registry, could
 I expect to have carrot admitted too?


Do you have running code for carrot?

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

On 07/15/2015 09:42 AM, Edward Lewis wrote:
 
 The document defines the use of the name by referring to a couple of
 references, none of which appears to be published in a way that can be
 referenced except by URL.


I agree that the URL could be use more foresight, e.g.
https://torproject.org/spec/protocol,
https://torproject.org/spec/naming, etc. I already suggested this form
to the Tor people without response. That said, an URL is the right thing
to do, as long as it does not change. Once the URL makes it to an RFC,
it is the responsibility of the domain operators to keep it running.
When the Tor specifications are updated to RFC status, then the .onion
tld RFC can be updated as well to point to the new references.

 
 Drilling into the criteria that are presented.  Not all of them.
 
 1. Users.  The draft states human users are expected to recognize .on
ion
 names as...  How are users supposed to recognize them as (special)?  
In
 as much as the document says nothing about evidence of deployment and
 adoption, how can an expectation be developed?  If I hadn't been readi
ng
 the thread on DNSOP, I wouldn't have thought onion was special - but
 I
 live in a cave, so what I think isn't important.


The original P2PNames draft use:

Users can use these names as they would other domain names, entering
them anywhere that they would otherwise enter a conventional DNS domain
name.

Since there is no central authority necessary or possible for assigning
.onion names, and those names correspond to cryptographic keys, users
need to be aware that they do not belong to regular DNS, but are still
global in their scope.

 4. Caching DNS Servers and
 5. Authoritative DNS Servers

*** Well, isn't it the point of this draft that as software matures
onion names will not be in DNS queries?  These points are to minimize
the consequences on privacy when misconfigured systems leak queries, and
to minimize the number of bogus requests hitting the DNS tree.

 6. DNS Operators

*** Again, this is not about enforcing, but about establishing best
practice. People can rely on RFC documentation and conscientious
operators will apply what's written there.

 7. DNS Registrars/Registries
 
 This is the place where a case should be made for the registering oni
on
 as a Special Use Domain Name.  Given the story to date, that onion i
s
 not to be in the DNS, then don't change the protocol (5,6 above) but t
hen
 set up barriers to putting it in the DNS (7 here).  If you do that, th
en
 Name Resolution libraries (3 above) will return name error or NXDOMA
IN
 to all queries in the onion domain of names.  I see this as where
 registry policy documents can point (by reference) to a list of name
s
 that are specially reserved or restricted.

 
 My concern is that, if this application proceeds as documented,
 the precedent being set could be regrettable.
 
*** Are you suggesting then that only 7. is kept?

In any case I recommend reading the original proposal for .onion in the
P2PNames draft 04 for an alternate view. Maybe some of the questions
there can be useful here.

https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-04
#section-4.3.1

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/14/2015 11:37 PM, David Conrad wrote:
 
 To put it bluntly, from a certain perspective, 6762 and
 dnsop-onion are essentially about the same thing: they are
 formalizing squatting on namespace (by Apple in the first
 instance and by TOR in the second).


This is blunt in more than one aspect. That you consider squatting as a
negative is insulting for those people who actually need to rely on
squatting not to be excluded from society.

But the argument that this is about, correct my paraphrase if I'm wrong,
taking over by force part of the namespace is in my opinion misguided.

The Domain Name System is *one way* of managing *a* global namespace.
That it is the canonical way of naming things chosen for the Internet
does not exclude that it's only one only way. Special-Use Domain Names
exemplify this point, and particularly P2PNames such as .onion
demonstrate the viability of other techniques than the hierarchical tree
of DNS to manage global namespaces.

The objective of this registration is convergent with the idea that the
DNS is the canonical global namespace of the Internet. Indeed .onion can
do without caring about the DNS, but this is not the point. The point is
to recognize the variety of techniques within the scope of DNS so that
future implementations can rely on the DNS as a correct source for
global information about namespaces.

I regret not to have mentioned this before, and hope that it frames the
problematic beyond territorial claims, operational issues, and security
issues.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVpnXeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9r5QP/i6bE5b7u5M4JrIN+98GS8HS
SG0wcDwVX13SWZujJ92ZFGy7lHDfG9wQr8WO/AoAlWT0vMzyfixMpWJZ66gxxthA
F0fdZtI4N4nfjwolpQUnBnY/39yW1sumYg50AsS5dmX026F+wkjqidIV2s5PiZQr
D4GC+6XvvYMvsYmLKwv8JeK1+wqkRw9nl2YSX6Wt/U0EwaI/VpIgjYkaT0VIFjw+
c5OBkRfdaY4pFZ/NMfjiIvcYQp7MQhFPjvpsRMFtvtwpn+ZiJKoB4e3dOPCeL1S2
dANLyutiodFTMGYGWn9W6Zcfv9SckSOiblH5qvNpkMcAumQe09fTQGxNX14OQXWr
g6qV8oeNc2k1DsmPHM9UsDYSJmEy4zikGKLCcjpOC3Y4h+6aqyvBsby43dJfr7Fy
tajr8nh1IcA8VZtM/K5+rqMZabg0EPIPujkchdrJTZ8+jiT0uT8pEDR4VammAcOz
9sMufzxdv30yYDYuFpTeTAf27z8h1232yhKOHaBaueDsZmva/IccHyHiw4ZQg/6Y
NEoZ87UJa1lXWqJ7+XeyOfwJp1adPwXWb2IiNDIjXndXwt94yBPinAL/3E/2gnfw
/XSKMTaeGBtixhllwidAtBSX7EeWTGQl7kWlH8MsvoLvpcZmuTTHpuWZ9k5VEcTe
rn6UM1/Ooyjp2i90Gz7q
=jn7Y
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] perspective Re: Thoughts on the top level name space

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/08/2015 08:36 AM, Suzanne Woolf wrote:
 
 It further seems to me that an attempt to list names that are
 currently in the public root zone or might someday be in the public
 root zone has a high risk of being simply backwards if the purpose
 is to identify names it's safe to use in other contexts because
 they won't collide with names in the public root zone.


I can see a distinction here between names that are currently in the
public root zone, and names that might someday be in the public root
zone.  Obviously, the former is a finite list of names in operation,
and can serve as a reference to avoid name conflicts with non-DNS
namespaces: they already exist, so they should be considered solid.
Besides, if I understood well, there's a procedure to send
decommissioned domains to a 50-year-purgatory before they return to the
unused set.  On the other hand, this latter set of unused, potential
domain names is the complementary of the former in the superset of all
domain names: making it special as such would determine the future of
the namespace, which seems to go against the idea of letting reality
unfold and adapt to it.  So I'd recommend a clear distinction is made
between existing domain names in the public root, and the rest of the
set, kept as undetermined and irrelevant to daily operations.

 Our current
 approach as documented in RFC 6761 comes at this question from the
 perspective that the IETF can declare whatever names it likes to be
 so protected by extending the standard with a new entry in the
 special use names registry, but takes no account of any possible
 distinctions between names currently in use at an arbitrary time
 for the DNS, names that will (or even might) be in use at a future
 time for the DNS, and any other categories.


I'm not sure I understand what you mean by currently in use at an
arbitrary time for the DNS: it sounds to me as an equivalent to the
superset of all possible domain names that I evoked earlier; if a
domain is in use now, it's part of the set of existing domain names in
the public root, otherwise it's undetermined.  Or do you mean there
should be a preemptive complete assignation of the domain namespace?  I
don't think it's possible to predict an ordered way of revealing the
namespace until its exhaustion: it sounds mechanistic.  Maybe you're
suggesting that some names should be reserved for future use?  In that
case I fear arbitrariness may be the rule.  What example categories
would you think of?

 We might want to decide which, if any, of such distinctions are
 meaningful for the purposes of the IETF identifying special use
 names.
 

For the sake of avoiding name conflicts, the distinction above is
necessary (existing, i.e., registered by IANA, or not).

Regards,

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVnqZPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9KiYQAJoYiCpysih6Afs2TIRMFjCz
qqK17dtdesnEGDCGVoj3IFSfSFDcj2CFauxb7bppiemZGx/Ot1Gnsly/ULCI9TC7
1UGP/QkmLHPXaU9xiGoDssEoMtXxMfD89zi5RxqwIW5NvUg8CH4UUU3njW+oLCzG
EA1LH0V8PmOhLvWmI21FN02csq5w+4crTMytfbgT6rywnYJgAUB4mYLUMzl1XSI/
DlYW5PwHCC4T6dD8GkA4bvcB8Ve8fjXO+zk2PlOdtQy+9cA0I14Ah8Y7Fo3HDUOI
5fmdLi5B73E+KedYLVrAs+MZENGd0qfoHZRcLPN8yObQ2NSFIXYxV1K+tI/QhzP+
2/D+oemihDvaV1Vi8rNAHknzSUG3afMtrsPjC/9vcooYeqXPQjavKDYJg7UZDeT6
lphoa5r4AeQd6321cKcDbT55y9/Pq5OJBCGa1bWLNlax4DGUZ5juy1j2NLD+faLU
jIUW0bT3t6m3meQsj/dmw9xX3ITHz8ESF9NbicItJ4uLpjXdIxNoxgVJzuQEEM/f
jji9E6bmqe8IbqiXbSk0aNGf1O4h7nXDXrzTqlB6L6x/4n+eZVzWTykZbMdOlUnH
xuW020sWk9GXh/EuKE82p+xCDYK6b0ES5e9sU9kVFCoiaXm5JsCe9ygmQvRZM485
2t1TLkEDrrUesg3iT7PW
=Z2EX
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] More after onion? was Re: Some distinctions and a request

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/02/2015 10:05 AM, Edward Lewis wrote:
 
 You're right.  To underscore, it's because of the groups that
 don't engage, and have no responsibility to do so, that the IETF
 has to defend itself.
 
 It wouldn't take much work
 
 Keep in mind that the IETF isn't a thing, it's a collection
 of people volunteering time.  What I mean to say, not much work,
 but it's like trying to jump out of the ocean back into a boat.


I could not agree more with Str4d.  Processes are not at fault: aren't
we having a rough consensus about the Internet as an open society?

For your information, draft-grothoff-iesg-special-use-p2p-names-00 was
published on *November 14, 2013* [0]. It has been submitted to 4
revisions to date, without counting the newly split drafts at the
request of DNSOP list members into a draft per system (.bit [1], .exit
[2], GNS [3], and .i2p [4]).

As a final comment to help you catch up with the process, the .alt
draft [5] first appeared on June 06, 2015, and the original mention of
.onion was removed from its fifth revision following my request to
confirm that .onion was not covered by this draft (per the draft
author.) I think you know this because your comments were also included
in this version of the .alt draft.

I am very surprised that you did not read the P2PNames draft, and hope
you will now read the 5 drafts that came from it (I include .onion [6]
to the 4 mentioned above).

Regards,

==
hk

P.S.: As Christian Grothoff mentioned, I was interested in making these
5 drafts leanier, following the .onion model, and bring the (common)
details into an informational RFC instead. If you think 5 drafts are too
much reading, that might help, especially as there's a lot of redundancy
from one to the next.

[0]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam
es/00/
[1]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-bit
/
[2]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-exi
t/
[3]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-gns
/
[4]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p
/
[5]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
[6]: https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVlUYyXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9zpIP/3QJF7Eni4RrzwAn5U3ITnqo
vsv/cTcVYTm2EybW3mFaY/UeE868HyHrsF0mXOIxwm/B6lFCAKA47B5m+zvqhRwA
I1euxD9L/KOoB/8//sE+JLzKffiwGPaI2MY6r3Wiqb5ivijy1sVVuwr8GV2QdvoD
Nvflcnu+iXX3IQJpZTDxrrmKjYIdgXxCxKPKYquf4kE3cMWv/5sEolYvTH1eHlLV
MBGzzKZntE487u0RGEiym0teE0xV3U09Ln7cpppMmKrrKs3UkcXfqFbB+fhKHP+N
J54Pif+ndiMeBAcYuoj4/OXtT+x1r3rOR8PLgUvdlYfBsJpjOlREAVqDP/c9R1sW
PWkSkrBmo1hTkQv5ZPt/EBc6Fiovq3k0ptnO3GXn4XOT1udXarlAXpZm7KvzY7Sc
DG6Q2EXM8//w4jwfC3mBt+jFEskijEh6G2sNo0z8lBsgyU9EZuSkUGMtT3c1nLaX
jnV0Qd90tpD9tP/dGk/U4S8V4Wg9fhBxlDbMYiEFRttaGdL4MGFXoSDcHLuqDTTX
QAtDx2kvR/yhLJY5OHO1qGvTjixcfMz82COrRCEsczH4psjS/iRziT1DlGX2aMQr
6kSOPq0EtabdfYwsHSETfh4KC1DfzzIEVlvFen3hs9sIrj631HACoZfMLNYcjbmH
vNO8NaLUMJsIIi9eniQ2
=0u6r
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/22/2015 04:21 PM, Tim Wicinski wrote:
 
 While I understand why you feel 2.6 should contain information about
 user's privacy, it currently seems to meet the requirements for
 [RFC6761].

*** 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJViKtrXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9u4gP/i5EMKWth68+zoOW+lI7Oimg
mbkNqfJy7vxXvI3CpIrKvfH/dS7HtQEwz2IXWltjUqf5ahsnxBBMlk2wHw5Gi8EK
F1El9KkUK29A7467ZkfwbFxa7uzCIozxGlFafDZr9lzWZjMoynx7R9Lao9wq0h7I
RqluhOv9pm7Mop15u/3oWWqL/SIysQgWHvrVeZ4AsFwx6LKN7kU/KLj1REQOQeq+
vFsW8otJ2A0k3chw7Y37FX5OLk3a2RrfLCVoRQ7ECLDtyQi7VwpaxlCupV9bJ3lZ
aIUKTzmdx+TPv1r899j9aag01yo1YLtMwzkccFUZmUTD4vkbYB5vmgjbB0WYx/1E
RcoXd5t6vOJC0bEOFtxP7180A4MLqPr7mQ98zYOFstrON6SATNcgkmbTyrM41kND
8rppB2ixlm9AdPLOop7kSO/9pisZQytDJCZ4M9+/OZ3ER2JaZN/jfYj/iBSqfsuM
FXpYaPSkUMFdUokvS7fSXwDUhtzXQ4rBimtveu9giATTLtaNzX+PgfE/kTr1u/ch
a/QAInDWQi9v1nB0smaKmhjNt3WdJAMsHgjbMge/+jLIvHwV1qcIqsBSqLIvw4v8
1wT7TiSsSMlRJH0PxzBqtWsIzfkNjW9Wr8O+LqVQa4RZRle0LPt28qQLOxKQHBZY
M4eXTDaS7moKdkdI4pWW
=4z9Y
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/20/2015 03:12 PM, internet-dra...@ietf.org wrote:
 
 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVhqxdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg92R8P/13kDLdvyuX/TPpnlSpWFVvS
xxNm2cSuErqpwlH1MbnsI8GuQCtZxbq5qmJ+nlVAqe7LlWSNboJu15X8Ve/SFtDk
YV4p99XqSmaY16zpwzcozQcDr62ze/Xu2uJ7Mw/WXNz6WrGS79SzL1KpYgvTJgIc
z7t9l/gcKxciyTu6/+m7QATakR4NNYD9HqEMQqDyJEqYZX27eh1+Z75APiD1DXS9
7VIxsraVsT23ZymGHRRrOKNA5rThNwCqPukxBScY58wleUpp6fO24LZqSM7GdIfa
OgmHWpp3ntv06DYlwm3E65B5GhquVMm+PrkWS/LJ42iymhOiNQ/2mfFboBB2X2US
7mqC1lR+OsxcpYa7KCdOQYJu9PmhopExmjPhnggEnXJ/WU7gk61j0z4N6RTqaLXP
4vOW1yP/P+Ic3fi0pQdOJ/7XyTKqSHqa0biBu1otwH13qhZqQw9HJSUlruJrHo0W
8FkEhzZYraTsZVdCerRKThvHcArIYe+sLM/iFvBwUQEtxkqbkPeaUCxrafib5dkc
3jer23bOnblXlDnF/goLSJZd00EAe/6lgOXKPSx++ie6GBEmLBlDyHSIdC30DbQ/
HrCm0mFZkQxMAav/6mb8Ibyf991BNHoC/vsuyv+OKmJUOwF+p6mkrGjRAXK9xSJm
RMSYsKjlrg34BwxE5Fan
=kGu0
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Post-Interim considering the 4 proposals

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/15/2015 08:28 AM, Hugo Maxwell Connery wrote:
 Hi,

*** Thank you for this report.  I hope to read the minutes soon.

*

I note that you omitted to mention Namecoin and the .BIT pTLD.

*

You wrote, referring to overlay networks: Their reluctance to use the
DNS for name resolution is possibly due to its unencrypted public
leaking of name searches.

Even if that could be a relevant argument for privacy, the technical
ground is way simpler than that, as introduced in the P2PNames draft:
the DNS is hierarchical, and these systems are peer-to-peer, and use
peer-to-peer mechanisms to manage, delegate, and resolve domains.  It
would be like saying an electric car has reluctance using gasoline
possibly due to its liquid form.  P2P overlay networks are different in
nature, they rely on algorithms to ensure the attribution and resolution
of names can be automated and never conflict in the global namespace
they use.  They achieve this without administrative decisions, but
solely on the basis of cryptographic integrity.

*

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

Was that discussed during the interim meeting?  I have an objection to
this form: although it makes sense to consider domain names for
reservation on an individual basis, there are at least two sound
technical reasons in favor of registering more than one domain at a time
:

1) proximity of specifications (e.g., .onion, .zkey, and .b32.i2p are
all self-authenticating cryptographic hashes of the destination service)
,

2) complementarity of names (in order to break past the limitations
described by the Zooko Triangle, .gnu and .zkey are complementary; the
Tor Project uses .onion for resolution, and .exit for tunneling to
specific exit nodes)

The latter means that if one domain is reserved and the other not, the
system is dicey.  This point is particularly important because it will
influence the next step for P2PNames.  As I mentioned already the plan
to move on is to turn the P2PNames draft into an informal RFC and
extract the domain reservation bits to respective drafts.  Although I
disagree that P2P overlay networks should be considered separately, I
even more disagree that they should not be considered as whole systems.
 Thus the most obvious split we consider is to do one draft per system,
which happens to be a single domain just for one (Namecoin).

I'm all ears, thank you for your continued attention,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVVgEeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg93hYP/1B9Az5mlP+l2cpsgYx1mO1q
K3Arv0pPKH0pBDeD4E2dXAmTHf5fIMBklLrloK7LSs2HFc8Wc0as1fLhqjtv8nvg
S3urt5tF2dPfhtfTnKPBmIxOw3DvGsAau1BJQjRcVU78eVDt1Qu7HEGrr819oSbS
awGFB3dka0WjdjmFVcfWDDaGlr50MSoKc30mGo6JwtP7a4+BCUbLa7PgguCoIGlQ
rBlwkQ/TdF0FMdJKA2gj79jJhKe+fPPWJsIPZbiomGRdKRNlgmKMSvT7XsheVUtZ
b97ukR83wh0W5nj96njD3XNbUSWcdtMayB825zhCFyUTRtAlHH9CY5NsXy6IdfCO
n0Nr9vo2iVnOnQ6JWre8FByYtCVxz3XwKn4Gl040WcaWtayjm9VErel2GSjq2yPe
x8WMEQhzgX1HdFvrEsXR2QiFrW2X9WOpwJKWstD/UED4oqzh55RKXI4+/OAkkMby
9gvCscJap3Wcn/190nS+MDGimiIyzc4RWC1Eg5k0wyTy7jBWPqpragEMudwlJb0Q
lbM7Qb5VpPIb2/JpEcQSm0hgwu1vemnBpztKOgQcuawuh5fu2SqJ1POMIPkKEEXW
H4E3RRo6tTi9LYeb7C/9okoFoHMjdmydO0vvNpC1cupSSywzy40U24MRk23OKp/Z
LdO+17iVjiDltnK8HEyT
=3A44
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/13/2015 05:51 PM, John Levine wrote:

 which means that ICANN is sitting on $3.7 million in
 application fees which they will presumably have to refund, as well as
 five withdrawn applications from parties who got partial refunds and
 would likely expect the rest of their money back, so we can round it
 to $4 million riding on selling those domains.

*** Maybe that means the business model of ICANN is not fit for the
technical model of the Internet?  I don't think it's IETF role to lower
technical expectations and requirements for the Internet to fit anyone's
business model.

That.  I said it.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVU8HtXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9QwgP/20CeLAn03JP7H8WIdkcQPPe
MQuDq+fXdTwLXKOnHET2m4C8bM4feJ5yymk2OVHvhrtkB+s/ikYu8rBs1E4pJ6wh
QsEW+yfWPPF2bVZW3Hpwn7eCu22mmZL42mzF14t1gwMbwuYeoWvLmjfR03X/HFoz
derWEH7TmkbWHmJzcrqxNx7k7PyTuBPpsCHv/JJAyaJxfhzsCtH/XqFv+duNYdf5
Zb8US6frSU48TrUZnwDCPycUFRX/FcjMDKKeCwTayc5jGBTZcSqiT2aAcAo0dlOM
GXzZg2XU2Z3CVfAYcmcsRE6inKVdXXegYtux4eSP3PZSR7+B7D8YE330T2QcG6At
ftUpxSsIWHM7rHaQXHK2Jd8OOavYDCpdChfk8OxbVaqkxVX5UrbDM+TC+borDe3+
wfTtISsHDLP08EPmXERU0G4CuGOO6MwEFlNkZv7DzthwEMjogIfalxEwg1PRnuD/
RoTpLvteJNnAlIN6hEi/5Vt8Xo2YvV3X5aorBA04M+eQVUlXN+AbsmiXm7z0lU2D
6sCGl0DGCiK/C7OqBPNT7pcJaPHZDawt7HC1ynJuOu+oDupzFng3/rNXzTPn5539
KfyTceEX5v0CbOAGvFSQUHKyBM21pG/W0M/SWUpkmKg/A9J/loJNNUn1le3+8Jxw
/h/rzSypoUibCj2wLHCQ
=a4Ah
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/13/2015 03:05 PM, Andrew Sullivan wrote:
 we should not be poaching on turf already handed to someone else.
 Managing top-level domains that are intended to be looked up in the
 DNS -- even if people expect them to be part of a local root or
 otherwise not actually part of the DNS -- is, I increasingly think,
 part of ICANN's remit.

 Managing things that are domain names that are by definition 
 _never_ to be looked up in the DNS is different, and we have a
 legitimate claim (I'm arguing.  I should note I'm not sure I
 completely buy the distinction I'm making, but I want to keep
 testing it).

*** I better understand now your reluctance on P2PNames: .bit has
exactly one feet on each side of your argument.

I was waiting for the minutes of the Interim Meeting (especially the
parts concerning the adoption of OnionTLD by this WG, and the part
concerning the P2PNames draft) but I must say that the P2PNames party is
already contemplating working on split drafts to facilitate the
proceeding in a reasonable time of non-controversial strings, including
to support draft-appelbaum-dnsop-onion-tld (albeit with some reserves),
and clarify the discussion so that such arguments become apparent.

Andrew you will have an opportunity to test your assumption more
practically soon. :)

I'm looking for financial support to pursue this task: I am not employed
by a generous corporation and most of my colleagues do not have mandates
for that either.  As usual the fringe of innovation on the end-to-end
Internet matches the hi-tech-lo-life style of Cyberpunk novels.

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVU54fXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9DcsP/RbC+jpOJn+/Z9PJgxV6GQ7i
OV3PUXId3CjPtTxoNG7rQ+0yVBv8aZKl/3KmSWRIqvvUsthO6djj/CJr/rLBp+UG
g6I0f4IKdrb3RBbdeIHK6dK7Ck3MTSRel3dkUhIpH1jRPtdGyLxqIwl8nRjPPMDe
MC1GSja56ZIrCniAn7pSYAxus3C0uud2bKGVpqHAz4aeZY9UrTRsHTZbaWp/XL8u
4tX4jNKixcGxZQFDmuCBoqNfnrRY98uOTkzSlUfPsGy6bW/A7+w/VS8CxjuPRNnx
O+HzyQjSil2K9JzxCg1GPmWlVfaSVD3lTm8i1Sa9DOF2XeJ2jA5o5qiQc8arJRgQ
Yv6CIbfD1KcdtTEXIlZ1q4TJSiQX5wH/pRvmUVD0DS0xhtKxeKwxgfpwF/rRw3eO
zN1KbsfyMoSC/T+Pp2ZeLeFLznpuro4VWkItdF7h56wgvVxWdG9RDeLPJQTHnqyT
ZuGeHnElLO0RDKmVc0kcxRufcS+MjQiyFiouS9Do2i5TZ5MM8JJDwUiCFxQqIY6D
Vm+RWc2b1R5ePPsgSk8RCod9MbD4u/HDgt/SxBH1r+x08143fmhnE/OSDr0lYXfa
Rw6oyI5yXe0urooLqkwgcg5yZkIXovbrpZ1X6cGcOny84mpzQd98trqwC0QvID7U
SCNjKlU26jrDZh7qDIeK
=YtU0
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A comparison of IANA Considerations for .onion

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/12/2015 03:12 AM, Alec Muffett wrote:

 ... both Firefox...
 One of them - the Tor Browser - is using a SOCKS daemon which knows 
 that “.onion” is special and shouldn’t be looked up in the public DNS.
 
*** So in my understanding of the scope boundaries of RFC6761 IANA
considerations, which seems to be the main difference between our drafts
and our respective positions, the former is an application, while the
latter bundles an application and a name resolution API or library.

In this understanding, the result obtained by the naked Firefox is
consistent with the application not caring about name resolution, not
considering .onion special, and returning NXDOMAIN for the unknown
domain like it would for a non-existent .com ; respectively, the Tor
browser bundle matches the description as well, serving the onion site
successfully and without prejudice, thanks to the availability of
non-DNS Tor name resolution via the SOCKS proxy.

(Other successful Tor onionspace-browsing setups could use a naked
Firefox with an IPtables set to direct packets on port 53 to the Tor
resolver: a separate application + resolver setup.)

Sleep tight

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVUaEoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9GxUP/2/6Ra6ocakvChEHgKUzpaaC
+c0nENpPgvZUHlwHM75ZOlvqlXaZkW2yAfK6diTZSGXd6v6Sduq1s0O2olgg5TVN
3rcuLWfbYwRl0m6bQgOotWU2S2qumvwy49Ad38W8FarOYRerH9NTeqJQ/Vu52pl/
zWQx7IjqNT3rSYaT2ecrE0rcfdtXCyspFjvGvP9Dg92lyeipLSiDHAxSsAyudO4S
RPve4LdDx+6/WKzpO1TiqcpD/ggwVAY4Mj7jGDLC6DRHml0WakZ07PGxj1a7gaUN
XbXtmMkC5lZgtsxxsk572C+a6BEth66zlvuJ2IusrJyXZSsGfvQJxxPMjzyk8Y9Q
D4wdMSKV1pnyBWvF5hMbmqaQIo/jZyeMSBUKSNA92mYS5+KUXpclxqQisDNNWSVj
4cQqcc8AhF+kxSUWqFqg6/RVMpZypw+WEoOpGxHoszCqJqPI+XFGOG6jDA6IypYn
/FEFUrX8u1OFP6Py2fzVeQz6IbJaGnNU/MsNI9hmcDa81OPjcXWUzBMXOkL/++jZ
TBheZlOrhdQ/+GcrHaBITChBjyO6eUsV2Uls6NaarWrBWjlsPdjw7K+v+0xh6LyU
Mc6/RuJnfpE3KYzRoIylcUJ9ypkoiRG82xM+qfPgTPWU0Kfl+mIMx0oNOvedXV+m
pIq1dVpWb7arRFUpuCFs
=p038
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A comparison of IANA Considerations for .onion

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/12/2015 04:18 AM, Alec Muffett wrote:
 On May 12, 2015, at 7:44 AM, hellekin helle...@gnu.org wrote:

 *** So in my understanding of the scope boundaries of RFC6761 IANA
 considerations, which seems to be the main difference between our 
 drafts and our respective positions, the former is an application,
 while the latter bundles an application and a name resolution API
 or library.
 
 Being a SOCKS-based service, of course, any SOCKS-enabled client can
 talk to Onion-space; including SSH, for instance.
 
*** I'm sorry Alec, but I don't understand the meaning of your response.

On the one hand you seem to agree (of course), but on the other hand
you seem to talk about something different.

Let's see.  Naked firefox is one case.  The TBB is another.  SSH is
yet another.  All three match the application case.  But only the TBB
comes with a built-in Tor resolver (and matches the name resolution API
or library case.)  Do you agree with that interpretation?

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVUezHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9RcIQAJhwbgNCL9WFcMb7IohlMy07
1dWrMkFjYFBVpCU05LslPVaqY7+XhKcAp1F8tJmNE9QJSyC1+ngozN5n1U1NZ79d
L3Nq/ocKFpVjtaHUq4WbxyuUlJ7u0mSou2HWtFqCchDb5Ps8GuUpiqTwLe4Q2H5L
5ss5vveeB2fTF8J+ErbmbGrgBxWlDfZrGxH2uD69Q/cWjfbdCg3hRJCaS2yWb/Xn
9eDd6C7odt30xNEMfHtr7kzqxAQL8g73fBO2U3Cq1kEZb8brTabByv+soc9MbS10
jlfQlrl1UH7dxbbai7OQYRFqIyl9gAB7LHTy1WB4mk5LG1xbuvqfOzrtlNDk+kmr
WeVz48F8Gliyuf7cOwG1BarnYkk/heAIDLETqN6eMqhLqJ5c5DTfA5Z/TgULncWf
AIa1Mt1k66mz/Gxfqxzcv9GG6IxmnCHmIJeCpoXCp0cvqOjNzdySWbtnABkCKBSK
HptGysbY4l6PWPkIFCGAJZ15lcwO40E4pFfX5iefWitiUZLY0HwJ+2yVCWvzgNC9
JDYnVSsDf0d5EV7bvMG/UwMqZ92O83krYrCUJLfQUbBB6foZialTKV8b2LgLqd7B
DLkfhPZ/CYlvbUZLR2M3nUxx/JQVXscUF88hk+9txQh2kHpm0EMiydM2jP+I84hu
y7pO9+YLniBiYAqnwpwv
=gPmw
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A comparison of IANA Considerations for .onion

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/12/2015 09:23 AM, Andrew Sullivan wrote:
 
 Is your complaint that appelbaum-dnsop-onion reads to you as though
 such special applications are the only way to do this?  If so, then
 you're right that it needs adjustment.
 
*** Yes, my concern is that we can get consensus on how to interpret
what an application means, and what a name resolution APIs and
libraries mean in a consistent manner in the context of RFC6761, as it
can lead to wide differences in the resulting rules for the readers.

==
hk

P.S.: your previous response was instrumental in my understanding of the
difference of views on MUST and SHOULD, and on the point developed in
this message, and I thank you for that.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVUf1iXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9CCoP/26lZAk6UymUHKe6CyjG+XDe
yvIgtI/vWvIlr2RvUycRO6mQwrDij6ZHi7lt/+ku0Xqrr+cDlNo55zfw5DrzJ8G7
r31m7RS1mq6y4H9aPxkGwgB3FhrAM9A7hj/3Mu0zgewv0QrhSgW+zW9pw/315SM3
h5Xaj4tVx6tsXAPkG6pefDaXFfXjJhuRtL0vXsk8pn2s1kc/2RekX0InUABEiKUf
h6Y3M4uoYxfoMcbj6a0x7udihaANxt9/6B/npqjvyZXrSemYsxvUqEOcw32NtweD
+C5EJJur7yFrAL3xYvRHKSVJSs1XJvjY3FvpfC0yhYmEUO7QUHmMYYAYVjCVpgEF
2raqdVaFoICARdiCbm/d5dQujfXPQfti8o5vQy72H2ZYiSgScO3GnwYHil70RhkN
JcTbWeQ2+oyKvWEuVwF/I2E0WWXXSbZmbRKCKJQ4RnKfM1IOxfCnpx3wBoLk8nLX
hKAB9pgjyk0T8T7v9wXeCKyIP18L82iGJQi9MCc/YOaSTL1tyNKjs/Hso5p1LSxS
tuAAouE5TONI37Ud77Up13Mw9OJkCxse6o2bNs0Jox4laxvJV+nAJzSOwa6F6noj
8sU0Gv+v037U/bZQHRq/PIk4ELoAs3dxPhpG3AHCH0iqFPDAvTd/WkNzK/zmhPnN
TeB49F986AAe85Hph8AA
=qKXA
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

How does one join the meeting with XMPP?

I confirm that the WebEx software is not compatible with my OS.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVUiIFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9VCIQAI5+8oZzWYIf3ZihCERVZ0zD
OL7jg1eSjGF7WShQXLko/PLqo+Aj5bN58h1r/0LB5+QPNE/SFJtOuTz06S7xIr/y
5IeYxEUhPhWHUOP0fp2CRCIspOV69SKFvLYmLXhEUrOJl+TlJtJXqTlNQ3H0DG9f
d/fZ8doYUrwMeoLkb0CW9NhcazHwCeUL8rUQcqvuNVKdsrrHd1fFph0hrhZzKW1+
3EkotHeVPPpJmWb1sj7+Exp44EEzz4vg1JM7BI9AK4HGGte6R3IMXAlF7HAJxBG9
uK6dcT5pRJEmPjxafkvmeyPwYlwRzWcqsbJTxRJz9bbpuScWLECicgprPgESLjBV
r2tY/np/YbZfjZwje5K3j+CIyQcngYvOiPd5lcKc14W4lqOTjQoxmT5BWJK3/mqF
Yf8JRDWleZVHhFtkgQ4VIitQO8B2eGc3xqnRosRTu0kCHJtFmSSshdNjprKu9Ev9
eI/YJ6Vpi4pb5RmNHOogyR4Ntxl7WK05YmJ1gJ0fqJDsVhGx9etwBnIvOb101QIT
FV1um7iAYG8OdPylinQ1gxVW8aXjowmOLpZXW9XhCbmjJA5gN7THJ0TkhajUvTNy
S9rKBzpi1AAOYhZtBn9Q2/ddbMRI0hUjXcrh3UfMLceL1d5e6vbPi7a/xFBFh+Bz
X4wrNgCIzvfb3wMwiN1x
=10bl
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] A comparison of IANA Considerations for .onion

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since Alec Muffett seems to have better things to do, I feel obligated
to do what he should have done before publishing his draft: comparing
the IANA Considerations for .onion in the
draft-grothoff-iesg-special-use-p2p-names-04 (P2PNames) and
draft-appelbaum-dnsop-onion-tld-01 (OnionTLD).


# OVERVIEW

draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the
processing of .onion special-use TLD, as the P2PNames draft was
considered too controversial (and maybe too complicated?).  But this
work, although sporting the name of a co-author of the P2PNames draft
and claiming support by the Tor Project community, did not benefit
neither from concerted action with, nor consideration for the existing w
ork.

A simple comparison of the IANA Considerations for the P2PNames and the
OnionTLD drafts highlights critical flaws in the OnionTLD draft that
curiously didn't receive any attention at all so far (except my own, but
I reserved my comments up until now for others to come up with this, in
vain.)

I noticed 3 major issues in the OnionTLD draft:

1. the users considerations pretend that users must use onion-aware
software in order to access Onionspace, but I assert that you and I can
use an ordinary Web browser, type in a .onion address, and access the
requested service.  Not only OnionTLD conflicts with P2PNames on that
point, it also confuses users' awareness and application software
responsibility (and possibly the scope of IANA Considerations' first
question).

2. more importantly, where P2PNames imposes NXDOMAIN response to
authoritative name servers, OnionTLD makes it a soft requirement, thus
leaving the possibility for name servers to hijack Onionspace without
user consent nor awareness.

3. this error is confirmed for DNS server operators, where OnionTLD
makes it a soft requirement not to override responses.

Given the complementarity of 2. and 3. for successful dragnet abuse, I
have difficulty believing in a coincidence, and am very concerned that
such points could go through an IETF process without an itch.

That the P2PNames draft remains controversial should not remove from its
qualities, and notably its technical fitness and attention to detail.
As the editor of this draft, I apologize for the shameless
self-promotion and urge the DNSOP WG members to not confuse diligence
and precipitation.


# IANA CONSIDERATIONS DETAILS

This verbose section details point by point the differences and put them
in context with RFC6761 questionnaire.

## 1. Users

- From RFC6761: Are human users expected to recognize these names as
special and use them differently?  In what way?

*
The OnionTLD interpretation is wrong.  I want for proof that I can
browse Onionspace with an ordinary Web browser that does not treat
.onion sites any differently from a .org or a .net.  The OnionTLD
interpretation also contradicts the P2PNames interpretation, and pushes
responsibility to the users (who should know what they're doing).
Moreover, the OnionTLD interpretation also says that onion addresses are
only available through [onion-aware] software, which is not the case.
*

P2PNames says:  Users can use these names as they would other domain
names, entering them anywhere that they would otherwise enter a
conventional DNS domain name.

Since there is no central authority necessary or possible for assigning
.onion names, and those names correspond to cryptographic keys, users
need to be aware that they do not belong to regular DNS, but are still
global in their scope.

OnionTLD contradicts this: Users: human users are expected to recognize
.onion names as having different security properties, and also being
only available through software that is aware of onion addresses.

## 2. Application Software

- From RFC6761: Are writers of application software expected to make
their software recognize these names as special and treat them
differently?  In what way?  (For example, if a human user enters such a
name, should the application software reject it with an error message?)

*
The OnionTLD interpretation only covers the case of onion-aware
applications, and then do not specify the response.
*

P2PNames says: Application software MAY recognize .onion domains as
special, and SHOULD use these names as they would other domain names.

Application software MAY implement mechanisms helping the user to ensure
their privacy expectations are met, such as warning the user if they do
not detect an active local Tor resolver, displaying a warning on
first-use of an .onion domain to explain the necessity of a Tor resolver
to reach such domains, etc.

If an application knows how to differenciate between DNS and P2P name
resolution, it:

   *  SHOULD NOT pass requests for .onion domains to DNS resolvers
  or libraries,

   *  MUST expect NXDOMAIN as the only valid DNS response, and

   *  SHOULD treat other answers from DNS as errors.

Tor-aware applications MAY also use Tor resolvers directly.

Re: [DNSOP] A comparison of IANA Considerations for .onion

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/11/2015 08:21 PM, Alec Muffett wrote:
 
 This might be an issue so long as your threat model includes blindly
 unaware users who are typing .onion addresses into non-Tor-capable
 browsers in the (presumably first-time) expectation that it will work

*** You probably mean to say: human beings.

 
 ...on a network infrastructure which is thoroughly pwned by a capable
 bad actor.

*** You probably mean: the Internet.

 
 Please explain the contradiction, I fail to see it?

*** How can you fail to see that P2PNames says Users can use these
names as they would other domain names, while OnionTLD says they cannot
?

 
 As before, ignoring the potential for privacy-leakage of which site
 you are seeking to connect to, this notion of ZOMG THEY COULD HIJACK
 THE SITE is not a problem if you're using Tor-enabled software
 and have awareness of the issue, per the draft security
 considerations.

*** So you recognize that if your Tor setup is wrong, and you're not
aware of this, then it could happen that a malicious entity could serve
a copy of the original site, but resolved over the DNS.  This to me,
sounds like the well-documented--not hypothetical--abuses of NXDOMAIN
that were historically performed by Verisign, Comcast, and others.  Are
you sure you still don't see any difference at all between MUST and SHOU
LD?

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVUUlGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg962AP/0A7YE1UslDCKctnm2CRC39V
OMIPlVRITQNyAXE7FlqFL5W1PoebmZZsU5ITFiTUXnsPEonPon4KU9ZbGkFVhZ0q
BQdGL77d1F6dCzBX0E50ePaBgiwFVS4mqIdNH0QWIgk4iE+3pduLP5kZSZcFzvuJ
OWy/sOCZMdBdCUzV13Rg7UzYql89uYFGpg6o8Ti7AkdQM2soGdkht6mx/s4kN7qJ
BE2JpXbgKvyYwlwx5J6kvwhN2tnhIDWFLGRZ3U6pqHZXaI9QvzfoLaFm/for7Ha6
psjBirbqXJ5/+PPv2qt0ad4sJCBE3FFknLL+c4zDWGWo8ReiqOjDJ2yc1Jru31Lu
a7EOejrv6Oor/owFBEIElzI/X4gdnwpuA5P4GSTFnjartAPzn98aylTC3S0GZwAe
KudvUZABkQOOE/jTGGckYRYPmcQhOUXz4dfWQ2ZismYVEoNzqQFLrfU+6GmlkY4X
Im70HVL5i72LMljuphlfForu8XPDdl0/uTPra6mE65cA9Wf85PBenbSd/YKGd33b
Z+LxReRj5Q5l8+nDyQZJNqadadwPdsvPh4WknBDbio7CpX86bBHfNA4xEHe/lUGr
J6k8KQ1SRilOfDF/9U7REQwQ3J3LSzTIObGxvtxtgJ3txRNzt+PmSbIiuApYrwj+
l6Vq+UOxnV7rCEHEjoOl
=/L7B
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/08/2015 01:48 PM, David Conrad wrote:
 Mark,
 
 home, corp and perhaps mail need special handling if we really
 want to not cause problems for those using those tlds internally.
 
 Why?
 
*** Citing IETF92 slides by Lyman Chapin and Mark McFadden: [0]

these are the 3 names that were identified as posing operational
hazards by SSAC and both ICANN name collision studies.

why?
• operational and engineering reasons only
• problems related to potential delegation of previously invalid labels
that have frequently appeared as queries to the root
  • lots of evidence here
• https://www.icann.org/en/system/files/files/sac-045-en.pdf
  • affected labels
• home
• corp
• name collision problem
  • lots of evidence here as well
• https://www.icann.org/en/system/files/files/sac-062-en.pdf
•
https://www.icann.org/en/about/staff/security/ssr/name-collision-mitigat
ion-26feb14-en.pdf
  • affected label
• mail

==
hk

[0]: https://www.ietf.org/proceedings/92/slides/slides-92-dnsop-9.pdf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVTPdGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9GncP/jJVKUyyAQgFJyw2R8BMeUgO
VXWxuhSrhfgYP4UpEowaCRCaHrWaN7DsOeGmpTROGKjsoR4ynIWkp15rv+22SZyI
PrjtftuFR6H4JV+3iLjUq0Mm1cas8ytLGcPQt7lQo/gZzs7h2tXLsIoL+u1IYgoT
Irok3Y/0LwPM8tB7vL5AGGPOOUZvmRirXqCcPF7ZGg8adY0odY2rwwtm5cAGOaMB
QXk/Hky6ua464O0i7kCET/hZLtjIWLbeZxpso2jw+Sk3n78p4WZFZFvE6YfTNgHk
1gGS5/By764wgPg9FEEFLjFXnxIubjyJQMUqEuOIDJccuFxp5KiA+Bx8BZ1KTmbO
xmww7fVbKs/UmwP7Kq/sTwJpJGNi+PMs4MTzCtoM1MuxzyDi8WPU/mMxOnjJ+cSh
ZGR/OFFIbt564nDveSuuElFOhxpfyEma90zTMKkiU+cl48cW4VJ9/4KaZF12DvYb
MgLBHSo8osl5uBtt7Ppc6YvfGxgszBk2J6V04t8EqC1grbS8LTFbg4lUT9VQuyuL
JzSOvjsVlxlJwnDUnNF9dKRQCSzpXp8un5xGjtxE3bkvxuCTlrQFKlnbdRNtG3/A
I0KFK+mSdbe+oi0n1DEw6osAY5YJXZf9PJaN/a65dexkS98NT8Dx9/nfpB2/Is9I
rBaEIlkanMRGvoIBnQwp
=ZgS+
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/06/2015 03:07 PM, Suzanne Woolf wrote:
 
 Logistics details will follow shortly, but we have a webex URL
 
*** As far as I understand, WebEx requires non-free software to work,
which is a problem that will certainly make my participation more than
difficult--as I do not have access to a system running such software.
It's not the first time I notice that participation to Internet
governance requires non-free software (e.g., in ISOC as well).  Given
that the process mentions XMPP, would it be possible to use that instead
?

 
 http://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
 http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-na
mes/

*** I am concerned that the newer draft's IANA considerations are very
different from the older one to the point that they might conflict.  I
already pointed that to the authors who seem to have ignored it.  I feel
it would be critical for them to lay down the reasons for which they
introduced such incompatibilities that, to my reading, demote privacy
considerations from primary to secondary concerns.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVS3U5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9jDYP/1QyuSygoVxMxH4RzhRbIryH
95ateC2fyKeGMTwAEZ6tv5JVPYqLlWhWG+gWeWIipgFzvy5U+IbbkfzrLroIz8jB
E/1wHTTgdeSkRbgH8IYZAsqWOd7w5xdU3ZwxzvujwM771RBH96EU0DEHJZEOJhDS
r/r4MAbr60lrzWRo41BPDPc+s6K1cJziLbiNC7g9fSVR1Xinow5cBZiPwY8lA3dl
9ahpjy3n1NGVQXFetxyUKjIV8SYdEVdhBp4ANYzwM+9CVoXQ7oo/LNkS6oOY7v5R
dDKwAFBcPjQWYmFVZcUGE6huSu/gtJrzqKURTDs1OvZ5A+3vGnyhQMl6ysXUFfVr
j/TrfIiIMfzgR3Nr+D1yEmp4su0XTk3WRDkzh8b7JW4kL8dlPdgninOgMSz6p8gK
G/iVkUsRS95TdbSxql1Pm3YK1D2KGSIHxMMxIzOYtfk/Y6ZDIqcht76hHL4DP722
Gc0WGW5kUe1/VvJge12RGBU3CK5wzbcYBmFJcTgSH8vNuKEuRWog1vxlAg+lAObO
YLC0ZwluBIXpGP6M9ZzRoIEbdlYw8j+/VtYxaGoPzAC4qi5BVD2cdf48HxgMYHHf
L4JRicYHSqDzT9rwzH+EUSs3/okBaHy9vkRlgrZGDAdPFFwaiszAblGTnGf9qMHJ
KLIO+tTMGVbR6eJmzGYY
=hTUY
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Upcoming P2PNames draft

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The authors of draft-grothoff-iesg-special-use-p2p-names are about to
release a new version of the P2PNames draft that integrates the comments
we've received from the P2P systems community.  Unfortunately, the
previous draft didn't receive much attention from the DNSOP WG yet, so
if you have additional remarks on this specific version, please do so.

I am definitely concerned with the fact that the P2PNames draft is not
mentioned in [0] while draft-appelbaum-dnsop-onion-tld-01 was adopted by
the WG, without any consideration for previous work, especially, as I
mentioned before, with the existing incompatibilities between the two
drafts.

Currently we have two conflicting interpretations of IANA considerations
for the adoption of .onion, one that was inserted in the DNSOP WG
process by way of chutzpah, and one that is actually concerned with
privacy, but was left pending because it means to cover a logical
surface for all known P2P systems at this time who are willing to
collaborate.

==
hk

[0]: http://datatracker.ietf.org/wg/dnsop/documents/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVS5ckXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9FNoQALPJnAVdRJSneoZhp82yL+QH
pNSsFsTQXS/h30pknYXqjVHzum6lluxtwHLV02xI28tQS4XfOJq0hwx5CC+rU3x1
xudbxTaM3mZzCyRTMxQnlaPb7HKlV/soC/rTpbrtcvLPnrMx9MOptoLyh/qvd46U
p1b3pAnKchFmSpfqyV5w6wU9SqXb5BDoPSftpHXNkHPZ1opzh3RlBKEPz3nCoo73
/MfhqiyRuF1wKfWOpIuSIsXURQ/8HUuAZsh2K7w4I/lMluasuRfhLyoOkOd/0vVp
PNMBgvUsI97BQYIar6jpNB6R6Xb16VWQFk6XfHghPD8XGyCHL/lNux8sULSYqW6h
PrvpJeBjb85y6aq1ozBC4LSm0dAu5CMZgTi0JiGgek1HKPFifcgnrv7c6Q2oRUKm
5GFs8hfMHL4qkfVecPW0nbnehfmAMCPkzPwvJKSaJNrHrwlaFNE6tb5L3DGBf6WN
r1nDwT6tY4zu0zBteRiHe4bS5xVP76UYUCxahNkm339qFYuD1wczItfUXwrccxD4
BygArpA9DDopGVRYDlAoFWZAKnBDpCEmKPq00ERMr0itqVv4x9avxh8shr8U/HQy
bCxR5jnKF0iQHqXlA7zELrTicxMt+kysFkv4VBizSj4vk/vZ9kuYwEzkpbVgDnCg
JxQP0E7Vl+LOZJqDR6y+
=Ay6L
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/23/15 10:31, Andrew Sullivan wrote:

 if somehow the onion name leaked and ended up in the DNS, it's not a
 big deal

*** Well, although you're right as far as *applications* are concerned,
this is still a big deal because humans are using these appplications,
and that's the prime interest of having such a TLD reserved in the first
place, that the DNS does not propagate any leak.  So I agree with your
amendment, but not with the not a big deal statement, which completely
ignores the fundamental privacy implications of such leaks to the DNS.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVEejFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg91bEP/j112GQesXFel7AOtPEV++jo
gtTA2k8maagKs5hjJTpw9dq7Oi0U1CEKTq8ZSoizIoQTAmgtMUZZNnRqOE6Tszhu
VhMnhBP9xC75nEHrjQQOZC8A/mmOxTnSDkxX5/46wTP+4CVQ9ZbjLhVTHClf3ipf
wZpqwCsmC8h0lvefw663jbEtU0wnOX+e1JnzKN8Snsoap/989uYBVfCzD9Xrykld
3MTGLgMiPmv1qqejPeM+yqqoqeL/VxeQDXsaHi40HUnDQDQCGQNXqboSKPbEuUg3
VxLMEqPKXd762RRsWQznDqG23H1S/DY59FG+U4GQ0AzcS5FYxM4Moito/WW2LLk6
JLDXFQt0XcW5OMZbxhz6LuZwzpVCkCNf6wnEcLT7CQFDCKs0O0K8sg61PNeOKwyP
Ps0igpjuJ1hfjZIX8iEI6QoG9ktnY0tVtqw1k7aA4lRcuU8nxyflGANPwtE8KDTt
pUGFOXjL5hH0iC+ufv1pmNJCSvKhSprifvb+hMPZt3gksJeJYO62RqrZR7dXl4HU
CXO1FvNuCIoqhjZ/8n86JBLjpZ69TPq7zchJ2OFAeW7TY10/FSHqLrTiMFWyOJ6l
XyHbg6mU2Av5osSKVMzQNZhY3HaOnrnlpOrn4Tv58si/M8pMK+VE1lxfgDcnV9dH
mOEcz8LrmOB67pC0Dl5o
=E7vq
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/24/15 20:03, Alec Muffett wrote:
 Hi Hellekin!
 
 I would agree that leak avoidance is “a major” rather than “the prime”
 point of having .onion reserved as a TLD.

*** Agreed.  I came from the privacy side of the arguments, which tends
to consider human life as more valuable to data retention.

Alec, would you care to explain the differences on the IANA
considerations between this draft and the P2PNames draft for the same
section?  I found more than I can process now, but I guess you already
know about them, and I'd like to hear your reasons.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVEe+qXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg91PgP+wf57qp4wYL3Tdun3ntRI/Ik
KUBYuBoJkO1bzVHk3Eq+Nc2zbAMLja8qLm75LF1Q/2Onae3QTRatathQis3M2H+O
aZZLKZZ9mI5fOtqEmRoFa4Hl9rOUdcY4hDMdU7rAQ7EZnzK6KQIOYrxa4PMbUVf8
X21qz/UWtD8jDezPv64QksksLfNQrivjlDI/ecD/mWAT+mPW7Df8cQnQ6dEE/fMr
EdWEOfo8BE9ARJJ9M1LMzCcObQq1T2eoDLe0HXu8SID4+JHtLqbF15vQ9BILXHIX
jeEFIQeGsBlPaMYl8ZJffHGmEqCT5CtkZUTm/m2oJtU7VZ3zLu+p7J6A9UV7p3n6
PR6JQdya2Mikd3FAUTV5gOA+fKbKB40UXdZ7juMIJz2riqm0c1gHbS0/wzTDadqE
IVGMQbl+ngjs6VKI0l7fuz6AW9vwk9IheS77RCa2sNAv6XpnUgCGlTHBr2Ymnldf
MkeWPQWZI44fGEPQC7jTI9KonpxvqTpfFGSqKV9VpzIDNGX0Bsov0ixQCz01ZlVZ
PxrLLv3MjN1deDrgi4rgT8Qo+3roed9MlPzfyMPUDKXJIX3OP4uu+ZroYk1t6ddz
mqVUWdBwN00n01leRAkadqMrdq9wamO4mRd8hREA0S1mxAZqG52E//yxssg1KNUM
RFL3ZdFKS+A/0zgYyYrY
=kDtq
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 6761 discussion (“special names”)

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/18/15 08:01, Jaap Akkerhuis wrote:
 
 Following this discussion from a distance, I cannot help wondering
 whether this is special names stuff might in violate RFC 2860 section 4.3.

*** Assignment of special names belongs to assignment of domain names
for technical use according to that section.  Do you read it differently?

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVCXICXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9nukP/ikl8/kSob/+tEdkmy2W/rxa
gaNmPtkvKSnFxOhHLNL2aUf0M23b/mJXJkVzX42PupqOpKX8aLIp/pb6Zb+XZMR8
As4eA6Xs6XaO/deoLTGVy0ihMpECtwrdk+FD1P+cWkgTzaTZajrRDakYiUwlJ8nq
dMkaStxakHp+K9+Xt66enxTw8J7JmqKFxTQppumdpRvE/CsyJ3tBOeQOz7h4yInZ
KSuRXCSB5Odi0OqTUPu18Egsu6l5RlesnVHobCkq6USp6Ctc+udFqrSpyOivzRzJ
N3lIFk19snovxZUDx47TpNW2bXW1eTDGv2rMqgia+HUl1K1ZhgF7vy6/C+89XUv9
CoLZB9DjVk2Ej/d7/jfWclK6h9/YsMElne2Tny70uTQJF3MU8s9E3NJGxy8cO3Xb
oVc8Iu6wRVfQyi4EJBJ6HsMNRtkxtlqz+3oDoQSVU7WZQTqpTuVXGFWNThp3vjC1
EgrlHT3EG6xjpoKoBwjRWmoyVUSg7m7UoUgsxWGKNAuGcrIaojhA/qDswFQ1YdrO
21oCyTM6YQ4XSwMgqRcyIRNe2NCQJMXHNcYvagW8IM46FjpSgZ6kXFjXPzxmrSx8
V6QP4ct6k3zC6qRiwcfsAD2kt/p9gZSfTmlEEZIq9a5v3T5HIP7wjZEr9nBpzWoJ
na+Wl6rJg0hQKxrebcCX
=7T7q
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 6761 discussion (“special names”)

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/17/15 18:39, Tim Wicinski wrote:
 
 the implications of widening use of RFC 6761.

*** You certainly mean: the implications of using RFC 6761, given that
so far, it's only been used by its creator, Apple Inc. in RFC 6762 (if
6761 itself is not counted).

widening use of RFC 6761 sounds to me like its use should be reserved
to some entities over others.  It does not seem fair, and implies that
RFC 6761 cannot be used like any other RFCs.  Did I read something wrong?

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVCKHtXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9htoQAIWvIQWwEOZXOn65+n6eLWy0
7jT3xxAl4PQPZK4LNHB7sthw7cnuDAxSJwL1vRZ4hwuXLekodcUg9kGORxS+bgWD
rWnE1dmqPQE1G6xtyvbes0lDOIgiXz1iE6sC2yI3MBEbe+B6FG1QwjOPJH6LpCo+
8gh0KeBmDdjDjWE4Mrt85semiNZMGQo6XAbA9K/zQioW1MYjlpHfgcGJEJx9itDc
5i2K2etykSQTuj3g+OM/0ujgzZMlX98YevP9Dy/S8ULCrmtHXWXx0L+YCqfPqC9u
G8jZov1OoELU7owrz2JRqOnrPj2+cwoqg6A/rZbVUuwa39Be25XcyGP/3YDwWFYP
sZgRR3i8hbDHLGbS37eqJmr/lxqAft3tJCIpNMSar6R2sRsMWTuTSfxSntsFBZpS
bfh0ZfobIlMG6Nq5SPZAmp5X/FUqTH3gN8YoOvwmtsChwNBNr5JmLLUYcZFLZLtC
LIW3EDcvrgwqyr7S9aIrYQM0uVwpdG4sCbrRRbRE6Q9SNwVVUk2QQw1uSXSr7h0x
4QbObwlsyZbv1OMxxqF8K3UEb+x1Qc0/pNKcx1qqazRyeLtSAaEZIDo2Ylri+H7l
Sxn7s121OT4e9srQ7oHGLHBk3ZWHdWQtaIQB4Qxu37rj1wxiYe17nH8VWwcdP/UJ
BqXPq4Ls2mvDvilIga4b
=MuWM
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 6761 discussion (“special names”)

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

 
 Do you have feedback on the idea of an interim meeting for DNSOP to address 
 these drafts in more depth

*** Thank you Suzanne for your clarification.

My only feedback is that such meeting is very welcome.  I hope the
discussion will be fruitful and will enable DNSOP to get things done
with these drafts.

Would you please share the list of drafts for completeness?

Thank you for your attention,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVCL6IXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9Tk0QAJODcsSUjb4KQSdQ9C5hJOK5
qcJzAvzifq6jUcvFNQavmc1DtWMb9uhImz4j6AENp5/YExWkNlC01qvHXnI2zo6Z
xXggZFTndzSGQdOh79wkZLJbgqM1SwzQIzCLAymsQpLmp5OCJoZ4zR/D+46qKMMv
rpxlXdHZ6RCYcyw9QTwUR6+nkI87HpJKJ8daj5CeZD8G0f3Q5ephC0X6OaJldoIt
exjbg5I5lD58rSdjEn/0M2DPAy8BkgIH6DdBMLTF8r5z2GskF+HLhuNPEHb2B6Jm
HBBFkGS7CIu7UdcO2p1ZCnh/CUm0N+BWYYASOhpqL4/pbi4zzcPoAQ8MyLYSIEZ0
9lEU1uqpSDm9DDJkPl1V18l8AZBdADBEPNi9byZBznuKonuIA8KmMlBWuXC/PF0B
xsb0Lg7YZUS+sUc+KoB8bug4FS9vjDVnpVk4ZOsceXhqvdOPppRnFCMeycei/+/i
Uy7EpU8qKoPJU+mG8zulADcWAtt1i5oJHIrAxUmRXH/ja40V3Pe4HFoNHt0Ksdf9
WWmsQgEnEOcXXkT0nA0KQEvsK8Z42BvGu5LbVbKiLjyg0ix3EZYNGyzSIcz8Vh/l
nhzom/HsJvjf9Jxo2w+BMUS0In5SZQwkqyoxKmsmXCaBEKQwFJs74ePhiA/A7vVe
57eOOK2g85HdA8vhWt15
=lEY+
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/17/15 12:58, David Conrad wrote:
 
 I doubt arguments of this nature are particular helpful.

*** I feel obliged to reflect this to you.

 My personal observation is that one of the problems with your draft

*** Maybe you should direct comments on the P2PNames draft to the
P2PNames conversation.  Your comment suggests that the Introduction
section of the draft did not convince you, yet you didn't say anything
about it, which demonstrates the lack of interest in moving it forward.

Now, as I said before, Jake and Alec's draft offers an opportunity to do
actual work on one of the P2PNames pTLDs without the distraction of such
argument you put forward.  Can we please do that?

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVCFGZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9SI0QAJbC4Xp0q/DpP/f/0NC4b2ef
yo5oVXKiAAztb/6ED5OUGaV/KIWIV2GP2pwI1rxK8FrTWge2kajFLAmTXCcY3aGN
fh/jdY08XgPqO5lFXfMa6hCq5vXQVJareig8tgOl0k18DckjN6f+v2njgN6fvnUj
2l+FPSl6GxtVzLGLmly/qvRJU27Xi35UoTIj87xVGXTHpXBm9v4bkpz7vwyR4HYl
nBzIkV7ZteEd3kjGu9KMiOw80FEq/bI8hQii92p4jRw1FOTHiFvF+8qW1MzBRTg0
iYbYyKEZpSxw+7q9U6vzvXzPCuD2iCPLG6VAbjB56OtGdO8Cq23Q8LUUpeUeb1wx
gzupSHuS0WbsOYxb4VRqVlrsb6Aw0/0PQ2zWyS/MgdKlgXY/mRRjf+6awwMl1iaW
L1bpqvvvwWmRALRRV3bP1k8F2wOroP5A67kSoUaXs+ZSHqzxdzeARIQ6GD66Lst/
YvggjZxrav6Z1QhtVqS9xTczt16lvCSbn8lxnOWSn+inNSmEV7lPuhuyWZh/bkGh
Lr0ENl0MULn/+zuY+7S//9AxtyTjWVsUOxrsEn+bmR6T9kr91fX9wIpKOHOllVHL
en+NGf1qXy8863rxZwZicW+TUKbs2m9dKyYWGebhjBVJ2XronFMz3aAWxTRIyIX8
yMg26gCiIiO9Mv1wH1/u
=2MAs
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/16/15 23:20, Paul Wouters wrote:
 
 It seems odd that two documents would be requesting an IANA action for
 .onion ?

*** Well yes, it sounds like a mistake to me.  But we can also consider
it a god-given gift for people who argued against multiple TLDs in a
single draft to remained focused on the actual objective(s) pursued by
the draft(s).

 
 Than perhaps I completely misunderstood things? How does this relate to
 DNS or DNSOP if it is about issuing SSL certificates only?

*** Sorry, but I'm not the author, so I can't answer that part.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVB7UAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9dbsP/1XXwwZPW3wWRNmFMJVqa3jy
QGf3sPSmiJSsWoGMv0X5E3dQCcLn8c8Th58myYsOFJSKGhMTekhxgBySWCayscJG
FSHFjwk++UTwRgO0vy/M9/oJbCjGdpOh/fegZrVeeOhR21/I9Q3kzBzd+QL9WdV4
uwowqKIHBpjUv3rk0JKIQFrAepm5YQJ4uoVF1cdq6q8nwT8G2mxl5t4gBvuiqW8Z
IGHUaxnOnmFhr2HT/jnGWXD9ksY1Rk8cFifqGYLzToksPBsKCQwr4z1xwE/lAgP7
XwhISW96Zf6FbyiUFVMHpYoGhPGBd6Fz/e+NoThNccUzqx1/TaEg4WC0MuuhyXvs
8c75gVsKLf4rPUPoNTXkU18DU2kMqoO8b+KjuYSzAXQHRHlgbI3519To0OtjKerU
/lYtdGJ3ylCZh8wOFGTV/J5+vUXL+L6S6haqmtPoOcSLFBQH0ziouwRywdS7v2YF
X6Ir7esAgugQMwS/ZalJyexnEqu1M2AVcbXCu6pQ2J77pRnRDS2Dl5mg6NJPVjeS
5p+SnOYP+NfpUSHaZl3RtfIudXIwVTRUpsD9F5e21jKpPTniwp24si/ZfmZd/K/E
5pBCfXOoN5uIRqdO123rdTvUtSpO+jRrPhTUN7k53tsvip0pppbtRWQ7S/bYOuDd
sMNliOkUv0Td6Q3r7vKc
=QfoC
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Strong objection to draft-wkumari-dnsop-alt-tld-04

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/15/15 21:00, Warren Kumari wrote:
 
 draft-grothoff-iesg-special-use-p2p-names-04, Section 3 (Terminology
 and Conventions Used in This Document):
 The abbreviation pTLD is used in this document to mean a pseudo
 Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
 reserved to P2P Systems in this document.

*** The terminology in draft-wkumari-dnsop-alt-tld-04 for pseudo-TLD
conflicts with the one in draft-grothoff-iesg-special-use-p2p-names-04:

  pseudo-TLD: A label that appears in a fully-qualified domain name
  in the position of a TLD, but which is not registered in the
  global DNS.

If P2PNames is accepted, our pTLDs *will* be registered in the global
DNS as Special-Use Domain Names.  So, your definition is in direct conflict.

Moreover, draft-wkumari-dnsop-alt-tld-04 mentions:

  Unless the name desired is globally unique, has meaning on the global
  context and is delegated in the DNS, it should be considered an
  alternate namespace, and follow the ALT label scheme outlined below.

Therefore names reserved in draft-grothoff-iesg-special-use-p2p-names-04
are not concerned by .ALT: not only some of the P2PNames are globally
unique (.ZKEY, .ONION, .BIT), the others (.GNU, .I2P, .EXIT) have
privacy requirements that cannot be delegated to a DNS zone: the draft
says: pTLDs are not manageable by some designated administration.
Instead, the DNS software must be aware of these pTLDs and return
NXDOMAIN *without* passing them on to the DNS for resolution.  The
draft-wkumari-dnsop-alt-tld-04 does not cover this case, and cannot
cover it in a better way that RFC6761 and the Special-Use Registry.
(Please review
http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-04#section-2)

Meanwhile, draft-wkumari-dnsop-alt-tld-04 suggests that the Tor project
could 'root' their namespace under onion.tor.example.com.  This is not
only technically mistaken, it's also irrelevant to this draft, as .onion
names are (probabilistically) globally unique, they have
(self-referential) meaning [in] the global context, and they (will be)
delegated to the Special-Use Registry (which prompts for clarification
of what delegated in the DNS means--I suppose it means to a registrar,
which is not the case).

Can you please remove any mentions to the Tor project in this draft, as
it is irrelevant and can confuse people into thinking that .onion names
can be delegated to the DNS?

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJU4W58XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9kiUP/0H4ohVtJ/TVLYZOnZQ7ux2G
snY/KiLGKBmNoh6i4K4aY4vwBaN+5CFekRvR9I02MXXZcGmAQGCmutl08bxyICq2
aK3UDAvYlUJ25uulcgLI3zdRXxPyQJpEdSHn1cbH++XixbRPfOldQQmc/7R7II5R
lniX5+2ONCxFQ0d9iur0vcxcCrm+jZnxSULKSMSqtdHIPJDiFzA2FPm2gT/gfUeC
mpAP6MK/QbC3MrvPs/TEqgOnodaYVLezR/7vdGSk2FpxrAQHvg8bwRiqnO5vWBzH
u04aqFTf2AMW8BqGwzwhOLseomfNwGa+rKSe+1dPR4t/UZgTiU366gv/HLnxgD5s
4oWqeTe7w2Dyi7mN9okmNlcg1TbT11N79vz4QA9GiJ86VdfjeFD9Sm9lAtV8gi5j
9Wu5FcAT4+MhJ2AyOh8SuYOT6ovkhlqcBoBPIIK0NQxZND0XR+KuTonXFolXMmd6
5FGsGOiNEI2eNRIi/NUyZ7sHWuI3/K2CbtO8OALfgC5j87zifqq7hdvIAsU5OMoH
XnsremBGazIw24Y/t60bynsvdGuMxgz9UQe+Xgm1/vEt2uExo6WdF5FQuj2s78qW
/slT00UmzrwRrR52/CsA5cvWjFyHxwlad6hSiwNfC6xrphXJJC+Nz4jDyseZXpWT
PIQ9coQG6LpL+tTi/X6S
=LDL6
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updating the DNS Registration Model to Keep Pace with Today’s Internet

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/05/2015 07:59 PM, Mark Andrews wrote:

 But be careful.  There be dragons here.  Computers updating computers to cont
 rol who controls the domains?
 
 Computers update computers all the time.  It's about establishing
 the right controls.  There is nothing technologically hard about
 giving someone the right to update just the NS records.
 
*** Except when they do it on your behalf without your consent and under
the (invisible, unspeakable) pressure of a police state.

For the record, as a regular Tor user, I do not have the same reverence
to Cloudflare's customer service.  Although they keep defending the
thesis that website owners must select an emergency defense mode to
actually block Tor traffic, as more websites use Cloudflare services,
they become unusable without a proprietary javascript-powered CAPTCHA.

Given their jurisdiction, and the current war on cryptography, the
potential for abusive breaches of privacy with this system are
non-negligible.  Adding to that the power to update the authoritative
name servers for a domain, and you have a perfect Internet for Police
State.  And until now, without any IETF-approved alternative.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJU1AifXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9P5gP/11fxAttLj8JgNlfsckEbmjD
lA3cmTU8khH9fhDlFWTXEfZS7XIBsXkMv619is4N5UvS/uGyKQa7D5nVGbVs8vzn
/cHFhulqP7AXMN9z85bPJqFcJbdjwdDc+lAr2d+sahv+NZ0Ah+kfQkw5G/jm+drl
zzQPr6rIxce55YeH6chc2hChs5vOvn/khxGfTk0uB1fp77Eqy9VhOz1lZN3S672h
LeXQRPURyzw2ZBa/YWbLT9LpF2QAjTi1ajRAH/SIqw5ZspcAWo0tvIqo7dM1o7xx
hC+ZkFjuu/sMXx4kSE6aj9qhRAmwEqz96r33twFEjflRJReJ2v6Vto8z+jirMyoP
G7e0XtkfYJ9XfJ91KHsn6rqQu9Z3q174HUJPl46aUgDkNQpzSw7aFm/A1GeqT+HY
UsRLDOAbnEBECRoKJW3dedjymFZr8Jy4/8mh+CapJ4jLbSvAP2W2S0G/ahTZ9NUO
UXrr9Dij/XyjqxlG7otAiEHBMTd7y27j/LrKDWIh9Vn51jKGrzCV/xmAMjjL7SjJ
jgML19rd6YBJDbWSEejDuWuzKzC1wMm44Y5Gkw3FguQtoY7nj0KP+ZJKN3o2HHyZ
5jvkiBEfayPM5Js4XvrP4Ny3mnbCV8OSWehd5Rnawoyl0ZaXufkYRDMkBJ2ABpZb
UqD2cRRi7EYtrsndeJnE
=9L6K
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Complying with draft-grothoff-iesg-special-use-p2p-names

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/25/2015 09:01 PM, Paul Vixie wrote:
 
 get the IETF to recommend to IANA that these names be reserved

*** Yes indeed.  Can we get back to the draft-04?  It sure will bring up
some interesting if not controversial comments, as some parts changed
substantially to address most of the previous comments.

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUxaE/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9fUAP/RWiebtpevUa0dpNsSAppUgr
nivORo9Yn0rs0EEnMaF/578V4/bdfJo2trCJmH2hmWb4ELXOIKPLKzErQCQFzTE6
ykVdE82WNgUhexRCyq78D0i2/XO9ER5jAcECh9Bx63fd36qqXFy0w0guVF2OVTDp
3hO9RCVC6ExZK+bFPlS0It67cYwWoQK0sbkZ6zzyc21ao6fACpwjrg0hT8+t49k/
+9k3tIobdzU4vAWOhhaf6TiIPZizBqdWnJ3y73YRXu6IYjas1nymHy6dWK7qIdKt
ccCdEL6zAkPdRuAS7TNaq29W5YMFvnj6m6k8uEMR6YHbKuOe2KFAVY3QYeZohr2O
onCm5AtJ2P6Iv/byEoYCoqljG0ujGobUT2N9IhFVkt2vpPbaIUjAVFhk0/mqjC99
RmLqUhWQg+jN43PqWYjPZDA7KKm77uWeniqIFdEy9mKFAcrrmyObSiH8xJkquM28
gRLltFW6DwvDVRvtbNHi+cdQVKcQU4eHpLUAGBdBeF2oqPmXLAWFf7LcJ96CP78U
AMFirFoQEq2QWtWP1CUei+rY3V6DrEb/JslonwTuI5/TWEyVdvBSKMlYG10O4k44
DnVogrDcaJNDpv4/I1rhMtdA05Dvvx8viP/EWpzC8BVxnXxldD5MvtbxlYRToxUl
xaPZIdwmmClM6CIXBhzx
=H+G7
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] P2PNames Draft 04: we're adding MORECOWBELL

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear list members,

today the French newspaper Le Monde published information on a secret
NSA program, MORECOWBELL [0], that reveals the agency has been using the
DNS infrastructure to monitor host and website activity across the Internet.

This monitoring also enable Battle Damage Indication [1], a military
term to say in this case that DNS activity is indicative of physical
damage at a geographic location, and thus can be used to determine
whether a target has been destroyed, in the case the bad guys'
government didn't already shut it down themselves, so that the good guys
can repeat the attack.

Peer-to-peer name systems using pTLDs effectively protect the Internet
infrastructure by removing authoritarian censorship as well as attack
vectors leading to physical destruction of servers.  To serve resilient
names and protect the safety of fellow sysadmins in exposed datacenters,
to give a different beat to the Internet: please support P2P Names.
Here is draft-04:

https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/

As always, you criticism and constructive feedback are very welcome!

If you tweet, please use the #P2PNames hashtag.

Thank you for you attention,

==
hk

[0] MORECOWBELL, the video: https://www.youtube.com/watch?v=1UXHiPWrZxg

If you ever witnessed an actual cow herd, you know that we don't need
more cow bell, but more cows, as music comes with many bells, not a
bully rhythm from a single one.

[1]
http://www.lemonde.fr/economie/visuel/2015/01/24/cowbells-nouvelles-revelations-sur-les-pratiques-de-la-nsa_4561547_3234.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUw7bVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9mM4P/ipVNe+7BDlr1YUue2OKeP0F
YxnFBqMluHApymoc4tc58R1+h8QmVKIkRw0qi8Ebv+eOOgK64fogGyTMVsPeQwmD
duNfVxijB3/5TtuFTK3/uk3o3CsN3ttQX33OreOG/IqFsShZGZHW3RNJikwaKJ9B
8lkjqrF/9oravmHBCz5LCwDH//FJfrHNhCL1OVtox0up7mj9p9DC6VBbJ+HBqs+H
PJGS5fG0jJJhLRPUfSW6uzOPKk+N19sJ/0u2mG0RLIp4RKUaqFZ9AF6MEv50BKi6
bwa+Q+mPKnTlPfmGTlR9yy5Klr8q/MQPbk8xV9yO2T4N/GFi4QK7BZ5g76Zlz1nw
IcNCQUrNmygswntQ/bL8p+QCl98A9HO7D+t/ykAXeutWAoXgshndVbHFX/Id7sm+
t1QluaR6RPEAZc9P59rRW4NggRWU9eOqZXkg3cpCCyul42dql7Cj4Qqp85fTi0of
nVwGDYo4BgWMyL661ndYQ6+EuVLOqhx5RGuQmDXN5s7zUKhSi1ORbbJTFCFwsjY3
zjyZRJZaiGYEAsDSFEqiGFzELdx2w2S9XwAZ3K61vKbpBd2qmAJEaIA4QFbGup5M
OGpKc6j95YHG41cT9zwgTxm9AFBTY7Z+aAX7SzMsvaTJimZoX7/wy2WUUbFDxNg6
GXp8cGpXQujwCR4GoWKM
=Byj3
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] identifying an identifier's name space was Re: draft-grothoff-iesg-special-use-p2p-names-03

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/06/2015 09:42 PM, Rubens Kuhl wrote:
 
 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) 
 
*** 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUrIh2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9SiEP/0cIbiMGZiv52OT0iqfXC/iw
Uu7dpIG4dhBGTxJgNmIrezU4l0B+DYJklRueaJqAXpGKwwTpiy10cS67y0D19+7O
ydpPIpxOlVmJg1T48lXu5FzYSmKfDFJBfz09hyZ574aqcBHGtKrVnQlIYGnNLSkg
AeARZ+r7fdtaLjtmdNkw81iid5oVCvLXJsG0n4EU0l8DuKl8XTBWBWgeGH7fCWGL
niASncm89V/o8yI41g/JUwGCi5iBSlGD9G6nAZZFSJBZ1IZ5lwCZFRmoZKdhvjNm
QxJijJjpW4Z0k9zl0u/mCRKbd9B6eyZ+X2GoJGkc3tO16eeL5eDVfTwBx4+52EDb
8VV5jU+kWvTOitqG8jQpJsW0SAhWdfzyJFSxal7tMi+eLvtvW6TKUXcOmuZbibJw
2X6LB1bowPTMJ3emvSxgieCbcRi2feIjyJN9Vq+eivJrzI2puryeaPM0oAYdqhbK
Sd5DQADXHUbxuWB+PcgvnOXGOUcoB7arm0Pe/1iDeycotIU+OJsahpvS0T8x9cVD
gdsW4NO5njIVnuqQzQ1DSBl1msflYsf28nJawz/ZK2Q+yO4uWCR6w4dctsEyc1uc
QYyaxgcBaUXpWvponUf0xjqbKUenyPApVrILRYNbtV1FZYZhkbencTMvOMpWSSeU
yNZjZHlUdxTvAgeyRmpZ
=GD7F
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] identifying an identifier's name space was Re: draft-grothoff-iesg-special-use-p2p-names-03

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/07/2015 12:38 AM, Andrew Sullivan wrote:
 
 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.
 
*** 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.

 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.

*** 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
 problems, and so ought to be evaluated differently.
 
*** At least we shared that feeling, if not the scope of kinds of
problems :)

 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.

*** 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 

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/05/2015 03:25 PM, David Conrad wrote:
 
 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUqy0EXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg94mQP/2NIS70S8Pf8ZaoXsOy0uMG7
57IL7+0DQSug60NSeZBcSMqEBZsMUdtWA5gnnxTph6nSQaDCDdyGuE8UghhoMSTO
nKr8rjUDeCMOGoYOmB5z1ldhJkezz4b1ryRPVqQoClne4aJvnVzLwB5hCeGYVi1B
vZAC9BgkctdMMPcTv7lD2nc2cOv0C8qXxAiG9fPT+sTrYoaTm0j47+spyWx73NF9
eJWlpu4/Q6xgNzoShBoGAB/e6+5W1sOTLNMLwQMaSF/Yof54q2Uj+T/JOCLFQx0U
e8czocLdhym1dXtEJwW686Q6XZjEGJ8kvfkGjqjChASkhuzD5P5+Wg6DLX6AmmMC
Z5kc0ltuZuTKheKbOzoVmL2HAmvW6qwKJgyCcKGFMvVyG0ddcdroylpsQ/F5G9ha
Pw+DCIqdti9nPS8x+DSQR9JPsKWGPbZaQ8Su/AWhIr/z2Zw5nbo1iMLcmMmbWuXd
rIWYaCd3RPIq0P0tIN6gnCIEXSI5HkH0E+GPxPcapWCZT16Oz9NqBBu85xp9x7aC
4zY5Bj8IeRu9GQy+ilH4EzFMALwu1qm0bXINmPiJlhUBkbMbsT0SJUg2Qx/9lvLm
+8Qm7bJm70QT3hsasXTWD8z+5/PD+cFA1zR3CRqYIt5KVYOoeA2YGBdDyaxmKfsT
wFGvQzZ1jGSwx82NmA+C
=tBlR
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] P2PNames Draft 03 Released

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear members of the DNSOP list,

the P2PNames authors wish you a merry Grav'Mass.

This document registers a set of Special-Use Domain Names for use with
Peer-to-Peer (P2P) systems, as per RFC6761.

https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/

Notable changes include:

- - Shorten abstract and focus scope
- - Expand security considerations:
  - Add reference to SSL certificates for non-DNS domains
  - Add reference to SSAC recommendations on name collisions
- - Update references for GNUnet, I2P, Namecoin, and Tor
- - Remove alternate (confusing) use of dot-tld notation
- - Add Leif Ryge as author
- - Integrate community feedback

If you're tweeting, you're welcome to circulate
https://twitter.com/hellekin/status/548082724980797440 and the #P2PNames
hashtag.

Thank you for your attention, and happy birthday Isaac Newton and Jesus
Christ.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUm/x3XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEEgGw2P8GJg9RQYP/01aI726PQr7/BIhUzelE1hI
12EWL50hd8jpUSsXZpdQpGxRMw317YixZgrGu1JcvlmVfcixROFnhw7K8qfSmMfp
aFTqkcE/lb8oeqNX4kqL75d+oyb6AyJz9lkqrhPz4eaDTSMGD3W6bjGXn7diHB6t
uFpDvT7zUBIJv2Z9asFH9zYLBqvshhbY6oM34TjpJX2c9QUIfOx/MRg6ScHYoiNg
RfIceaUx0XebNR7KrMb1j924t+vfnrrzkyhR0I1d+FhZZVSWk0eslIN756t1mB86
ytO2bKmoNx/wbqCl9cF0hbiOHTVaYx1koD7AVcNXE+07eYSaO6UPaY4Qhbdntm+O
dIsOlFlKOZ4mehjlVPrc9/B3cDPSF8KldUa5rC3KrkORBZKnijWQE9cEIs5z7Dwf
M66oSuJmwYyhe5h9UDsQmsoMnrZ4jvyq45TpybXoI1+Soi9lSbplA4kNDXKmNbwa
pzYrPJfrBFdgGvd7QeMHkm1eaMoWXv/TBJrPp+vFNhkOgCVlVgdotTRPtKhtwe7R
tngmGPstsmmayEZ1aXl2GMCR9iyO20Wp/QftjXImiSGBbiR1ZgzEgvhD1lhdhL6b
YWatm/jWXRLI95Ep2AHD0i6UT73DuZ0BeDTOfDSbpogkL4xDBtg3YYFBGOEnKYO3
efGzEZbD4f7Ej8RxowwO
=iv56
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft on censorship, and DNS

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/09/2014 06:35 PM, Phillip Hallam-Baker wrote:
 
 If you want to do anything useful in counter-censorship then you have
 to think of using steganography
 
*** If you use steganography, that probably means you're sending secrets
over a cleartext protocol that can then be deep-packet-inspected, if you
pardon me the expression, to discover patterns of steganography.  If
you're not, then you're already using encryption, so your possibilities
to avoid censorship are much larger already.

 
 Port 443 is loaded with censorship issues.

*** It's also loaded with commercial applications, and that means
cryptography.  Censors willing to coerce commerce are usually of a rare
kind.  So far escaping the Great Firewall has been done via well-known
ports as well.  You have to be NSA to decipher live traffic, and only
then when the partner companies use the ciphers they're told to, at
best.  The rest of the time, all you can do it store and hope to crack
sooner or later.  But that's already not about censorship anymore.

I find it actually easier to block little used ports than highly used
ones.  DNS, SMTP, IMAP, HTTP, HTTPS all come with encrypted
applications, at minimum using TLS.  Discriminating port 12345 is
certainly easier than any of these 5 ports IMHO.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUX/kMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3MDM3QTJCNjlFNkMxQzA1NjI4RDUzOEZE
OEU3QkQ4MDk0MUM4MjkzAAoJENjnvYCUHIKTUKoQAIKnqqaP5lWyvru7k6UIg6Cg
5O5DniHBUGarr3beURTtG83Shys90tkDVIqVPJqKjvHHsLV356Nuya945JM45aNe
inN8qBr2aNc3mPqrqmEABO1e5CbDizdQUjFZEjBXVt3pVc9Mrpz38+W4hmFHTqHz
RwpyxKMgfOUjbl9GyAYVldOAQqkavqnLkaVpIYM4jgATlordPsIJLpLM1+sExwo0
YAVleOLFrEwe8e1oaRt484bebXE/Xbmi+MQV+YYsX5VoeHkb6GejW7JfDA5f6yoE
byIZjffvQBiCGKGTUSd0ATyd7RYJm59LZgZ+4Qu2k3bZ0nq0inulomxbHiZERqDz
utV+Xm4Xa8F0pyeddGjlskhIB10GhTP736JVa7Vhgg8hZRZluqm5/5JuWE7in4Qy
3X2NdcPby0ngPZQFQi9EgrToe6KVvH4aj7jtrfsdlGT0rhAv2Bb2QMhvQxMLxSOZ
xYTMeqEhl0QyNXVpzkw1C5m1rcZZw1hgh1DrxKJQ4a3aiWuKieinevQtaMaNynNh
/WOdAlQhBPj7jAGnZy8uuhaM9Zbr+uOAqvl25mYkPnJKDEGtGx/4bbE5hvbYnI01
BWnmtVzjfCBaLavUcRSaawo3fOn0BtDGxDvfeM7aMr1NCMi767l3PYXhQ/KAG6sI
g35vYl/azWZLgCb/aVhI
=NcF3
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-grothoff-iesg-special-use-p2p-names-02

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello list,

the authors of *Special-Use Domain Names of Peer-to-Peer Systems* I-D
are inviting you to review the latest version (02) of our draft.  It
includes changes prompted by community feedback, many coming from the
DNSOP list.  Among them:

  - a recomposed abstract (see below),
  - removal of the out-of-scope noconnect pTLD,
  - a split per domain of the IANA considerations.

The latter accounts for the inflation of pages, and the authors are
aware of the repetitions in sub-sections of title 5.  We hope it will
ease peer review and allow for finer-grained comments and improvements.

Diff:
http://www.ietf.org/rfcdiff?url1=draft-grothoff-iesg-special-use-p2p-names-01url2=draft-grothoff-iesg-special-use-p2p-names-02

Datatracker Entry:
http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/

Abstract:

*

   This is an IESG Approval document requesting the reservation of six
   Top-Level Domains for special use, in conformance with the
   registration procedure defined in RFC 6761, section 4.

   Peer-to-Peer systems use specific decentralized mechanisms to
   allocate, register, manage, and resolve names.  Those mechanisms
   operate entirely outside of DNS, independently from the DNS root and
   delegation tree.  In order to avoid interoperability issues with DNS
   as well as to address security and privacy concerns, this document
   describes six pseudo Top-Level Domain names (pTLDs), reserved for
   special use.

   The following six domains relate to security-focused peer-to-peer
   systems.  They are: .gnu, .zkey, .onion, .exit, .i2p, and
   .bit.

*

Thank you for your attention and consideration,

Hellekin O. Wolf, editor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQJ8BAEBCgBmBQJTGUubXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg96F8P/2kS5X733/D4jEo7t8uAykp1
rsrI33eJ770uRyWFuNWJ9ULUtuviprKr9B20HVeZXwLSVMQEofBqNjqY6/7YaMpw
YfWJkArX+rPw5shFyyEnvQG3aBPBOYymXhUTJadKym2hHnQywFYl1h2+VGFa9woP
F5Cwmxdynp+59UaM7X9yqgqsGYomyXPmPHBwebcPtE6DCL0dfmH7C74Jx7bLpXXV
5RkXGvHEt3aQlnvJ/67O3D3fYmezj2FZnV6cAATy1++cW3PRGI9IqmfwDrpaHsUp
VLwTjLPh2/kf4p0+hQMgboRdOsU7bHhXLmVW1YHAZrGwyFEfWbNAhhHuG4sA6IyY
ErSJdv4EYLQBHD3getKt6PcxRuMgyr8DiKHDA3OlqysXGyQ8RkSVEfo6GgJmpmII
AEYBjm55O0LzfyBuIdvBVi5md7EHzDtSypObAVtNbisdxUp99M1CMkpORAv+O3Dj
2E6+O5QD1y8c1StsgZjhTVmX4Ay6AlGPSGNGKeP63PumFqjuAz2V1eP4515qACCg
eVvZnkMA6JMAUU2OTxE6FIpLlIVieMhm5HhonpgdsyFSqcn/Dl5hPR0T62Jneo5s
mgkh6/6agDldpR+QgilTe5Sbnkvq6URkFu81LJUHHQbbqMnxG62x4iDv/fjzCwSf
eVbIlXFeoepsnROBQ4o5
=y/bQ
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop