Subject: [DNSOP] draft-appelbaum-dnsop-onion-tld-01 - seeking consideration and advice

From: Alec Muffett <[email-masked]>
Date: Thu, 16 Apr 2015 17:25:53 +0000

Hello All,

So a couple of days ago I posted draft-appelbaum-dnsop-onion-tld-01:

https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 <https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01>

Again, the diffs are minimal from -00:

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-appelbaum-dnsop-onion-tld-01.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-appelbaum-dnsop-onion-tld-01.txt>

…and I am cognizant of (planned, delayed) interim meetings to cover broader RFC6761 discussion points.  However I also have an elderly systems administrator’s eye towards extremely hard (and CABForum-sourced) deadlines and process, and I also hereby will admit my complete ignorant newbie-ness towards established procedure for DNSOP and RFC adoption.

“Everybody has to be a learner-driver at least once.”  :-)

So I would like to invite the community, please, to pass comment and consideration on draft-appelbaum-dnsop-onion-tld-01 which (if necessary) can be addressed in one last round of edits-to and review-of the document; and if someone would also kindly point me towards the process for seeking a “call to adoption”, I would be most grateful.

I hope to see all of the DNSOP processes - both established and ad-hoc - interlock in a graceful and well-oiled manner.

Many thanks and best wishes,

    - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Warren Kumari <[email-masked]>
Date: Tue, 28 Apr 2015 11:24:06 -0400

On Thu, Apr 16, 2015 at 1:25 PM, Alec Muffett <[email-masked]> wrote:
> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
>
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-appelbaum-dnsop-onion-tld-01.txt
>
> …and I am cognizant of (planned, delayed) interim meetings to cover broader
> RFC6761 discussion points.  However I also have an elderly systems
> administrator’s eye towards extremely hard (and CABForum-sourced) deadlines
> and process, and I also hereby will admit my complete ignorant newbie-ness
> towards established procedure for DNSOP and RFC adoption.
>
> So I would like to invite the community, please, to pass comment and

Some initial comments, and sorry for the delay. These are all (IMO)
nits, not substantive.
I found:
"instead of using the DNS infrastructure, .onion names functionally
correspond to the identity of a given service, thereby combining
location and authentication."
 to be very confusing.
After a while I went and looked at the diff and saw that this used to be:
".onion names are hashes that correspond to the identity of a given service,"

I'm guessing that you changed this because of some comment? Anyway,
this is in the introduction section, and so I think a little more, um,
introductory text would be helpful. Perhaps saying that they are
hashes of the key, and functionally correspond to <handwave, handwave>
?

Also:
"In this way, .onion names are "special" in the sense defined by
[RFC6761] Section 3; they require hardware and software
implementations to change their handling, ..."
I'm not really sure if this is completely true -- I agree that
software implementations would need to change, but I don't see how
*hardware* implementations would need to change -- largely because I
don't actually understand the concept of a hardware implementation of
the DNS / .onion resolution stuff. Sure, some CPE runs *software* that
does DNS, and some hardware accelerators run some DNS stuff in FPGAs,
but I still don't see this a "hardware" implementation.
I'd suggest just making that be:  "In this way, .onion names are
"special" in the sense defined by [RFC6761] Section 3; they require
implementations to change their handling, ..."

Also:
Throughout the document you state that thingies should return
NXDOMAIN. Personally I think that this is a well enough known term
that it is fine, but it isn't really defined (hoffman-terminology only
sorta, kinda does). I'd think having a "should respond with NXDOMAIN
(RCODE 3 - Name Error)" (or 'Non-Existent Domain') the first time it
is used would head off future comments....

> consideration on draft-appelbaum-dnsop-onion-tld-01 which (if necessary) can
> be addressed in one last round of edits-to and review-of the document; and
> if someone would also kindly point me towards the process for seeking a
> “call to adoption”, I would be most grateful.

The process for seeking a "call for adoption" is that you email the
chairs, saying that the authors believe that the document has had some
discussion, that it is relevant and that you would like them to start
a call for adoption. Actually starting the CfA is at the chair's
discretion - they can say the document hasn't been discussed, is
off-topic, that they'd like the WG to first focus on <something else>,
that there is an interim coming up soon and would like the document to
be discussed there some more, etc.

When you do ask for the CfA it is helpful to also state that you are
not personally aware of any IPR that applies to
this draft, or if you have, that is has been disclosed in compliance
with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more
details.)

Note that once the work is adopted by a WG, it becomes "property "of
the WG -- the chairs select authors (usually they keep the existing
ones), but the content has to be what the WG wants - the authors
incorporate the WG's consensus (and if they cannot figure out what the
WG wants, they can ask the chairs to determine consensus on a point).

> I hope to see all of the DNSOP processes - both established and ad-hoc -
> interlock in a graceful and well-oiled manner.
>

Hope this was helpful.
W

> —
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Alec Muffett <[email-masked]>
Date: Tue, 28 Apr 2015 15:39:27 +0000

Hi Warren!

> hashes of the key, and functionally correspond to <handwave, handwave>

That's very observant of you; the reason it was changed away from specifics of hashing-and-truncation are because the Tor project are currently in the process of overhauling hidden services, and it's entirely possible that the next mechanism may be substantially different - hence wanting to keep the description abstract and forestall arguments that the (eventual) RFC might be invalidated by evolution of technical details - the Tor Project will drive the implementation details, not the RFC.

> implementations to change their handling, ..."

That's an interesting point which I shall bounce off Richard Barnes for my clarity; my reading of the text was any device - software (e.g.: Browser) or hardware (e.g.: printer, IPMI, wifi router, etc...) - which wants to resolve a ".onion" name, must create ".onion" differently and eschew DNS in favour punting the connections to a Tor (SOCKS) server.  QED.

> is used would head off future comments....

Noted.  Thank you.  Thank you also for the extensive help.  :-)

    - alec