Subject: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 02 Sep 2015 19:54:19 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: No Objection

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

I'm seeing a lot of discussion (even during IESG Evaluation) that
resonates with me, but the people having that discussion are more clued
about DNS and the policy thereof, than I am.

I do have one observation that I haven't seen anyone else touch on:

I thought .onion was tied closely to the TOR protocol, so I have no idea
why the second sentence in this paragraph is here, or what it means, and
neither the string "TOR" nor the string "onion" appear in RFC 7230, so
chasing that reference didn't help.

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

Am I just being dense the night before a telechat, and everyone else
understands what this means and why it needs to be included in this
document? 

If this isn't clear to other people, could you either say more about what
it means, or delete the second sentence?

I'm not confused about the first sentence, only the second ...

---

From: Christian Grothoff <[email-masked]>
Date: Thu, 03 Sep 2015 08:14:17 +0200

> I'm not confused about the first sentence, only the second ...

Spencer, let me explain in 2 sentences ;-).  The Tor (router) ignores
'foo' in foo.KEYHASH.onion for the name lookup.  However, the Tor
browser sends 'foo.KEYHASH.onion' to the HTTP server as part of the
"Host:" header, so the server may act differently for
'foo.KEYHASH.onion' than for 'bar.KEYHASH.onion'. (This feature is
typically used for "virtual" HTTP hosts where multiple servers share one
IPv4 address.)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Sep 2015 04:13:43 -0500

Hi, Christian,

On Sep 3, 2015 01:14, "Christian Grothoff" <[email-masked]> wrote:
> Spencer, let me explain in 2 sentences ;-).

Thank you for the speedy clarification!

> The Tor (router) ignores

Those are two pretty great sentences!

Could that thought make it into the document? It helped a lot ...

Spencer

---

From: Alec Muffett <[email-masked]>
Date: Thu, 3 Sep 2015 11:31:25 +0000

Hello Spencer!

> understands what this means and why it needs to be included in this

This matter has been discussed extensively elsewhere, and in response to feedback from that experience, this paragraph will be mildly amended to address matters of DNS syntax conformance:

   Like Top-Level Domain Names, .onion names 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].  Note that such names must conform to DNS name syntax
   (as defined in Section 3.5 of [RFC1034] and Section 2.1 of
   [RFC1123]), as they will still be exposed to DNS implementations.

What the first half of paragraph is attempting to express is outlined in my e-mail to the IETF Discuss list (and DNSOP)

https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html <https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html>

…where I write, at perhaps excessive length (and mildly edited for clarity):

>> Onion names are much closed to (say) dotted quads (or other layer-3 addresses) than to domain names, albeit that to denote them there is the label ".onion" affixed in the place where one would expect to find a TLD.
>> 
>> Where the analogy between onion names and IP addresses breaks down is that the following is illegal (or, at least, has never been functionally viable):
>> 
>> http://www.192.168.0.1/ <http://www.192.168.0.1/>  (versus http://eliot.blogs.192.168.0.1/ <http://eliot.blogs.192.168.0.1/>)
>> 
>> ...whereas the following *is* viable:
>> 
>> https://www.facebookcorewwwi.onion/ <https://www.facebookcorewwwi.onion/>
>> 
>> In some hypothetical alternate universe where we were all using IP addresses rather than DNS to connect to endpoints, it might be cute to support <subdomain>.<ipaddress> and let the "Host" header (and/or the HTTPS SNI) disambiguate the intent, though doubtless this would also lead to some kind of disaster.
>> 
>> In the Onion world, the canonical representation of an onion name is:
>> 
>> sixteencharlabel.onion (compare representations: 192.168.1.1, [::1], etc)
>> 
>> ...and in the outline we sketched of how Onions work, we sought to describe them properly in their role as layer-3 analogues, mechanically generated hashes of a randomly generated certificate, beyond human choice except for brute-force mining.
>> 
>> However, the Tor software has a party trick, that (as Richard has explained) given an "onion" label for surety, it's happy to parse-out the "sixteencharlabel" label and use that for connection establishment, ignoring any other labels leftwards of that, if any.
>> 
>> Of course using (say) "ssh" to connect to www.sixteencharlabel.onion <http://www.sixteencharlabel.onion/> will not be beneficial, because SSH supports neither "Host" header nor SNI; but a web browser using HTTP/S will pass a Host header, and thus we may effect virtual hosting over a single ".onion" names.

The really short summary of this is: Onion names are layer-3 analogues, but they look like domain names and may have trivial “subdomains” where the transport protocol would be happy to recognise, honour and differentiate subdomains via metadata transfer.

Does that help, please?

    - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Sep 2015 08:18:17 -0500

Hi, Alec,

On Thu, Sep 3, 2015 at 6:31 AM, Alec Muffett <[email-masked]> wrote:

> This matter has been discussed extensively elsewhere, and in response to
> feedback from that experience, this paragraph will be mildly amended to
> address matters of DNS syntax conformance:
>
> What the first half of paragraph is attempting to express is outlined in
> my e-mail to the IETF Discuss list (and DNSOP)
>
> https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html
>
>
> Onion names are much closed to (say) dotted quads (or other layer-3
> addresses) than to domain names, albeit that to denote them there is the
> label ".onion" affixed in the place where one would expect to find a TLD.
>
> Where the analogy between onion names and IP addresses breaks down is that
> the following is illegal (or, at least, has never been functionally viable):
>
> http://www.192.168.0.1/  (versus http://eliot.blogs.192.168.0.1/)
>
> https://www.facebookcorewwwi.onion/
>
> In some hypothetical alternate universe where we were all using IP
> addresses rather than DNS to connect to endpoints, it might be cute to
> support <subdomain>.<ipaddress> and let the "Host" header (and/or the HTTPS
> SNI) disambiguate the intent, though doubtless this would also lead to some
> kind of disaster.
>
> *sixteencharlabel.onion* (compare representations: *192.168.1.1*, *[::1]*,
> etc)
>
> ...and in the outline we sketched of how Onions work, we sought to
> describe them properly in their role as layer-3 analogues, mechanically
> generated hashes of a randomly generated certificate, beyond human choice
> except for brute-force mining.
>
> *However*, the Tor software has a party trick, that (as Richard has
> explained) given an "onion" label for surety, it's happy to parse-out the
> "sixteencharlabel" label and use that for connection establishment,
> ignoring any other labels leftwards of that, if any.
>
> Of course using (say) "ssh" to connect to www.sixteencharlabel.onion will
> not be beneficial, because SSH supports neither "Host" header nor SNI; but
> a web browser using HTTP/S will pass a Host header, and thus we may effect
> virtual hosting over a single ".onion" names.
>
>
> The really short summary of this is: Onion names are layer-3 analogues,
> but they look like domain names and may have trivial “subdomains” where the
> transport protocol would be happy to recognise, honour and differentiate
> subdomains via metadata transfer.
>
> Does that help, please?
>

It does(*), as does Christian's explanation. I wonder whether there's a
sentence or two that would capture the salient points (which sound like
"Tor routers ignore leftward labels", and "Onion names can include leftward
labels that aren't used by Tor routers, but might be used to accomplish
techniques like virtual hosting" to me, at least so far).

Could you two talk, and see if that could happen?

My question is at the non-blocking Comment level, but it's also at the "is
the document clear enough on its own?" level. So you can ignore it, if the
answer is "yes, it's clear enough" :-)

Spencer

(*) and I saw your note on the IETF discussion list - thanks for sending it
there.