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

From: "Jari Arkko" <[email-masked]>
Date: Wed, 02 Sep 2015 13:09:14 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The two last references need to be normative ones, I believe. I would
like to suggest a note to the IETF list (if not already happened) that
this is being changed (alongside with any down ref implications) and only
then approving the document.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 3 Sep 2015 07:32:11 -0400

Hi Jari,

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

*If* we make this change (I am not sure we need to), I don't think there
are any down ref implications.  The two Tor documents do not have any
track associated with them.

Brian

---

From: Joel Halpern <[email-masked]>
Date: Thu, 3 Sep 2015 14:36:17 +0000

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".

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.

Yours,
Joel

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Thursday, September 03, 2015 7:32 AM
To: Jari Arkko; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Joel Halpern
Subject: Re: Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Hi Jari,

On 9/2/15 4:09 PM, Jari Arkko wrote:
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> this is being changed (alongside with any down ref implications) and 
> only then approving the document.
> 

*If* we make this change (I am not sure we need to), I don't think there are any down ref implications.  The two Tor documents do not have any track associated with them.

Brian

---

From: hellekin <[email-masked]>
Date: Thu, 3 Sep 2015 11:47:43 -0300

On 09/03/2015 11:36 AM, Joel Halpern wrote:
> 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

---

From: Alec Muffett <[email-masked]>
Date: Thu, 3 Sep 2015 15:00:48 +0000

Hi Hellekin!

I am pretty sure that what was meant was something like:

As a Git Repository Page Hyperlink Within The Tor Project’s Website, they are simply "the most current version of The Onion Specification".

…and as I think that it is pretty obvious that that is what was meant, I therefore really fear that your reaction may be perceived as unconstructive.

Let’s fix that. :-)

Being, as I am, an IETF newbie, this does not strike me as a terrible problem, but clearly there is an issue here which animates several people, therefore it must be something important.

The references to “normative” and “downref” appear to be related to https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry and seems related to a desire to “freeze” the reason / address resolution specification for which the onion registration is being pursued.

Joel: please correct me if I have misapprehended this?

The thing is, I don’t think that “freezing” the address resolution specification for which the onion registration is being pursued, would be beneficial in the long term.

The onion names will be compliant with DNS syntax - that will be an invariant.

Their internal structure will evolve over the next few years, and importantly so, because security and software change at internet speeds.

The important thing is that:

1) “.onion” exists, and that
2) underneath it, resolution is in the hands of the current Tor software, and that
3) none of the above make the DNS barf.

Perhaps the solution is to somehow remove the tor address-resolution specification footnotes entirely?

    - alec

==
hk

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 03 Sep 2015 11:02:36 -0400

On 3 Sep 2015, at 10:47, hellekin wrote:

> Come on, GitHub is a corporation, it has NOTHING to do with it.

Pretty sure Joel was just referring to where the current documentation 
is stored, not poking sticks at corporations.

Github repositories are sometimes pretty ephemeral as projects 
restructure. RFCs live potentially for ever. There's some benefit in 
references in RFCs being long-lived (it's a kindness to readers from the 
future).

This particular spat is about the appearance of the URL, not its actual 
permanence (unless Joel is one of those readers from the future). I 
think Joel is inferring that the reference might be left dangling based 
on what he expects from the behaviour of other projects hosted at 
github.

> the relation between Tor and DNS.  These are orthogonal matters.

I agree. It seems to me that the matter before the IETF is to determine 
whether tor exists, whether onion names are in use outside of the DNS 
and whether cross-pollution between tor and the DNS is a big enough 
problem to care about, not to provide an anchor for any particular 
specification.

There's nothing in 6761 section 5 that demands a reference to a stable 
specification. The fact that there's any reference at all is a courtesy.

Joe

---

From: Alec Muffett <[email-masked]>
Date: Thu, 3 Sep 2015 15:32:03 +0000

Hi Joe!

> On Sep 3, 2015, at 4:02 PM, Joe Abley <[email-masked]> wrote:
> Pretty sure Joel was just referring to where the current documentation is stored, not poking sticks at corporations.

Just in order to fight potential confusion at any point where it might flare up, lest other folk jump into this discussion and try running with it:

* The Tor specifications and code are on a Git repository owned by the Tor project, not at Github.  A simple DNS lookup will confirm this:

$ dig gitweb.torproject.org
; <<>> DiG 9.8.3-P1 <<>> gitweb.torproject.org
[…]
;; ANSWER SECTION:
gitweb.torproject.org.	3600	IN	CNAME	vineale.torproject.org.
vineale.torproject.org.	3600	IN	A	154.35.132.68

- so, any arguments which involve Github (Incorporated) are poorly grounded.

Continuing:

> There's nothing in 6761 section 5 that demands a reference to a stable specification. The fact that there's any reference at all is a courtesy.

Per my previous e-mail, I would be happy to pluck out specifications, especially if they are blocking progress, because I see their inclusion as irrelevant to the matter of registering the special use domain name.

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Joel Halpern <[email-masked]>
Date: Thu, 3 Sep 2015 15:39:43 +0000

I was talking about a reference to a document in a version repository (a github repository).  The comment had nothing to do with the corporation "github".  The issue is that the content of the reference is not stable.  As Tor evolves, the content of that document changes.  For many purposes, that is a good thing.  For informative references, this is also fine.  For normative references, that is references which must be understood to fully understand the document, they must reference stable content.  (URIs are allowed if there is reasonable expectation that the content is stable.)

Which means that the real question is whether the references need to be understood to understand the registration.   This judgment belongs to the IESG, not to me.  I reviewed based on my understanding.  If the assignment to Tor of .onion is for any use that Tor chooses, then indeed the references are informative.  If the assignment is for use for some specific problem and behavior, then the references are normative.  The wording of the draft led me to believe it was the latter.   In either case, the draft should be clear about what it is doing.

Yours,
Joel

-----Original Message-----
From: Alec Muffett [mailto:[email-masked]] 
Sent: Thursday, September 03, 2015 11:32 AM
To: Joe Abley
Cc: hellekin; [email-masked]; Brian Haberman; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Jari Arkko; The IESG; Joel Halpern
Subject: Re: [DNSOP] Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Hi Joe!

$ dig gitweb.torproject.org
; <<>> DiG 9.8.3-P1 <<>> gitweb.torproject.org […] ;; ANSWER SECTION:
gitweb.torproject.org.	3600	IN	CNAME	vineale.torproject.org.
vineale.torproject.org.	3600	IN	A	154.35.132.68

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Sep 2015 12:05:58 -0400

> Which means that the real question is whether the references need to be understood to understand the registration.   This judgment belongs to the IESG, not to me.  I reviewed based on my understand…

The references seem pretty clearly to me to be informative.  I don’t understand why there’s any thought that they need to be considered normative.   You don’t need to read the TOR spec to tell whether or not a domain name is under the .onion special-use TLD.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 3 Sep 2015 18:17:25 +0200

On 03/09/2015 18:05, Ted Lemon wrote:
> On Sep 3, 2015, at 11:39 AM, Joel Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> Which means that the real question is whether the references need to 
>> be understood to understand the registration.   This judgment belongs 
>> to the IESG, not to me.  I reviewed based on my understanding.  If 
>> the assignment to Tor of .onion is for any use that Tor chooses, then 
>> indeed the references are informative.  If the assignment is for use 
>> for some specific problem and behavior, then the references are 
>> normative.  The wording of the draft led me to believe it was the 
>> latter.   In either case, the draft should be clear about what it is 
>> doing.
>
> The references seem pretty clearly to me to be informative.  I don’t 
> understand why there’s any thought that they need to be considered 
> normative.   You don’t need to read the TOR spec to tell whether or 
> not a domain name is under the .onion special-use TLD.
The issue stems from the RFC2119 keyword in

    3.  Name Resolution APIs and Libraries: Resolvers MUST either either
        respond to requests for .onion names by resolving them according
        to [tor-rendezvous 
<https://tools.ietf.org/html/draft-ietf-dnsop-onion-tld-00#ref-tor-rendezvous>] or by responding with NXDOMAIN.

Alissa proposed:

    "Resolvers that do not respond to requests for .onion names by resolving them according to [tor-rendezvous] MUST respond with NXDOMAIN.”

Regards, Benoit

---

From: Jari Arkko <[email-masked]>
Date: Thu, 3 Sep 2015 19:28:44 +0200

Just to be formally clear, the IESG has approved the document and our comments are just that - comments. The authors should (with sponsoring AD) figure out if they want to do anything with the comments.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Sep 2015 14:24:25 -0400

> "Resolvers that do not respond to requests for .onion names by resolving them according to [tor-rendezvous] MUST respond with NXDOMAIN.”

Nice!   Thanks!

---

From: str4d <[email-masked]>
Date: Fri, 4 Sep 2015 00:56:00 +0000 (UTC)

Joel Halpern wrote:
> I was talking about a reference to a document in a version
> repository (a github repository).  The comment had nothing to do
> with the corporation "github".  The issue is that the content of
> the reference is not stable.  As Tor evolves, the content of that
> document changes.  For many purposes, that is a good thing.  For
> informative references, this is also fine.  For normative
> references, that is references which must be understood to fully
> understand the document, they must reference stable content.  (URIs
> are allowed if there is reasonable expectation that the content is
> stable.)

If the problem is solely the stability of the reference, then here's
an idea I don't think has been floated yet: include the Git revision
in the normative reference. It's functionally identical to e.g.
including a DOI - as long as you have a copy of the repository that is
newer than the date of the referencing RFC, then you can obtain a
stable copy of the documents at that time. That is IMHO a far easier
reference to look up than many non-RFC normative references, because
the git repository is distributed far and wide, and any mirror/copy of
it can provide an authentic stable copy of the documents. This is
because the Git revision is essentially a hash of the entire
repository and its history at that point in time, and can be
considered a unique identifier (at least until an SHA-1 preimage is
found, but even that would only allow a malicious adversary to fake
their own copy of the repository, not alter anyone else's).

str4d
> 
> Which means that the real question is whether the references need
> to be understood to understand the registration.   This judgment
> belongs to the IESG, not to me.  I reviewed based on my
> understanding.  If the assignment to Tor of .onion is for any use
> that Tor chooses, then indeed the references are informative.  If
> the assignment is for use for some specific problem and behavior,
> then the references are normative.  The wording of the draft led me
> to believe it was the latter.   In either case, the draft should be
> clear about what it is doing.
> 
> Yours, Joel
> 
> -----Original Message----- From: Alec Muffett [mailto:[email-masked]]
>  Sent: Thursday, September 03, 2015 11:32 AM To: Joe Abley Cc:
> hellekin; [email-masked]; Brian Haberman;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; Jari Arkko; The IESG;
> Joel Halpern Subject: Re: [DNSOP] Jari Arkko's No Record on
> draft-ietf-dnsop-onion-tld-00: (with COMMENT)
> 
> Hi Joe!
> 
> 
>> On Sep 3, 2015, at 4:02 PM, Joe Abley <[email-masked]>
>> wrote: Pretty sure Joel was just referring to where the current
>> documentation is stored, not poking sticks at corporations.
> 
> Just in order to fight potential confusion at any point where it
> might flare up, lest other folk jump into this discussion and try
> running with it:
> 
> * The Tor specifications and code are on a Git repository owned by
> the Tor project, not at Github.  A simple DNS lookup will confirm
> this:
> 
> $ dig gitweb.torproject.org ; <<>> DiG 9.8.3-P1 <<>>
> gitweb.torproject.org […] ;; ANSWER SECTION: gitweb.torproject.org.
> 3600	IN	CNAME	vineale.torproject.org. vineale.torproject.org.	3600
> IN	A	154.35.132.68
> 
>> There's nothing in 6761 section 5 that demands a reference to a
>> stable specification. The fact that there's any reference at all
>> is a courtesy.
> 
> 
> Per my previous e-mail, I would be happy to pluck out
> specifications, especially if they are blocking progress, because I
> see their inclusion as irrelevant to the matter of registering the
> special use domain name.
> 
> -a
> 
> 
> 
> — Alec Muffett Security Infrastructure Facebook Engineering London
> 
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Sep 2015 17:00:39 +0200

On Fri, Sep 04, 2015 at 12:56:00AM +0000,
 str4d <[email-masked]> wrote 
 a message of 89 lines which said:

> in the normative reference.

This is already done by the RFC editor for the Wikipedia references,
for precisely stability reasons. For instance, in RFC 7626:

   [dnschanger]
              Wikipedia, "DNSChanger", October 2013,
              <https://en.wikipedia.org/w/
              index.php?title=DNSChanger&oldid=578749672>.

While the version by the author just said
<https://en.wikipedia.org/wiki/DNSChanger>