Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 27 Aug 2015 16:46:37 -0400

Hi,

I don't see any on list responses to the points Christian raised, have
they been addressed?

Thank you,
Kathleen

On Mon, Jul 20, 2015 at 4:09 AM, Christian Huitema <[email-masked]> wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> The document proposes to reserve the “.onion” TLD for special use by the TOR
> project. The document is short and easy to read, went through the last call
> process, and is probably ready to publish. I just wish there was a clearer
> structure to the security section.
>
> I am a bit puzzled by the way the security section is written. Since the
> purpose of the draft is to reserve the “.onion” TLD, I would expect the
> security section to present the security issues mitigated or introduced by
> this TLD reservation. As far as I understand, the main security issues come
> from client confusion, which could cause “.onion” names to be resolved
> through the standard DNS process. A number of bad things happen then, from
> simple information disclosure that a client is trying to access a TOR
> service, to potential spoofing of secure TOR services. In fact, the main
> reason for the registration request is to mitigate these security issues, by
> requesting that standard DNS resolvers and servers recognize “.onion”
> requests and refuse to forward them.
>
> The security section makes all these points, but it also mixes in a
> description of the structure of .onion names and their cryptographic
> components. I believe the issues would be easier to understand if the main
> body of the document included a short description of the TOR naming process
> and name resolution.
>
> The security section also does not explain how the “leakage of names” issue
> is mitigated for legacy systems. By definition, these systems have not been
> updated and do not perform special treatment of “.onion” names. The TLD
> reservation probably helps somewhat, but this is not discussed.
>
> Then, the security section also does not discuss how malicious name
> resolvers could be deployed in order to attack the TOR network. For example,
> if TOR security relies on DNS servers “black holing” misrouted request to
> resolve “.onion” names, what happens if malicious servers replace the
> suggested black-holing with some malicious tampering?
>
> -- Christian Huitema
>
>
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Alec Muffett <[email-masked]>
Date: Fri, 28 Aug 2015 14:10:24 +0000

> On Aug 27, 2015, at 21:46, Kathleen Moriarty <[email-masked]> wrote:
> Hi,

Hi Kathleen!

I'm Alec, I am one of the co-authors of the draft.

At the suggestions of Mark Nottingham & Richard Barnes (cc:) we have refrained from issuing revisions to the draft because of the impending 2015-09-03 IESG telechat, in order that discussion does not derail for pursuit of a moving target; that said, we authors and our helpers and experts in IETF process (for whose help we are extremely grateful) have been discussing the best ways to address the handful of issues which have been raised.

One question under discussion has included a proposed amendment from IANA regards "registration" versus "delegation" and whether the notes kindly provided by IANA might, if their suggested amendment were made, cause a lack of orthogonality between the draft and other relevant documents. Suzanne raised that matter and we feel it's something best discussed and perhaps addressed in batch with other changes.

In particular reference to Christian's comments:

>> through the standard DNS process.

That is correct and is the intention, although perhaps my preferred phrasing would be "present '.onion' names as if they were subdomains of some other domain within an arbitrary top-level domain" - since this is really about the existence of Layer 7 proxies attempting to provide 'semi-transparent' access to the Tor Onion network as-if the onion namespace were a virtual namespace of some corporate enterprise.

An example of this would be:

https://3g2upl4pq6kufc4m.tor2web.org/ <https://3g2upl4pq6kufc4m.tor2web.org/>

...which is the (independent, non-Tor) Tor2web organization's link to the DuckDuckGo hidden service; the onion address is hidden as the leftmost label.

Precisely the same website is served though another proxy at:

https://3g2upl4pq6kufc4m.onion.cab/ <https://3g2upl4pq6kufc4m.onion.cab/>

...which is a layer 7 proxy run by Seotecs UG in Germany, but whose choice of DNS domainname under ".cab" leads to a more obvious risk of confusion.

>> A number of bad things happen then, from
>> service, to potential spoofing of secure TOR services.

Some bad things are possible, yes - HTTP man in the middle, not least - but to my mind the risks are little worse than risks the likes of "www.fac3b00k.com <http://fac3b00k.com/>.cab" would offer, and in fact I believe such risks underscore the importance of registering ".onion" so that SSL EV certificates can be brought to bear upon the mitigation of some of these risks.

>> In fact, the main

Incorrect; the main reason for registration of ".onion" is CA/B-Forum Ballot 144:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ <https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/>

...which permits the existence of SSL Certificates for Onion addresses until 1 November 2015.

If (upon that date) the ".onion" namespace has not been recognized as a global TLD, all SSL certificates for the ".onion" namespace will be killed and SSL will no longer be able to mitigate these threats for Onion sites.

This will lead to the shutdown of the Facebook ".onion" site, another that is owned by blockchain.info, and the SSL service for The Intercept magazine, amongst others.

Thus, my motivation.

>> body of the document included a short description of the TOR naming process

Per the comments above, a draft explanation of Onion address syntax (summary: they will remain compatible with DNS syntax) is with Mark and Richard for discussion but is on hold for the reasons explained above.

Regards Onion name "resolution", we believe that that matter is best dealt with outside the scope of this document, not least because the resolution mechanism is defined by software which is open to change.

It seems more important to confirm that Onion addresses will remain legal within the constrains of DNS label syntax.

>> is mitigated for legacy systems.

Simple: it's not.  The goal of leak-reduction is to reduce leaks, rather than to assure security.

There certainly is leakage of lookups for the ".onion" TLD to the root servers, and eliminating that 100% is unlikely, but it is a wasteful thing and should be inhibited for reasons of hygiene rather than security.

>> By definition, these systems have not been

Agreed. That's never been the intent of the document, thus it should be fine.

>> suggested black-holing with some malicious tampering?

Tor security does not rely on blackholing DNS requests, it relies upon cryptographic technology.

Tools which are Tor-aware will not have the leakage problem.

Tools which make a half-assed approach towards Tor access  by passing names through DNS resolution should be encouraged towards failure, but it is not required for security.

    - alec

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 28 Aug 2015 10:31:33 -0400

Hi,

Thanks for getting back to me and Christian.

On Fri, Aug 28, 2015 at 10:10 AM, Alec Muffett <[email-masked]> wrote:
>
> On Aug 27, 2015, at 21:46, Kathleen Moriarty
> <[email-masked]> wrote:
> Hi,
> At the suggestions of Mark Nottingham & Richard Barnes (cc:) we have
> refrained from issuing revisions to the draft because of the impending
> 2015-09-03 IESG telechat, in order that discussion does not derail for
> pursuit of a moving target; that said, we authors and our helpers and
> experts in IETF process (for whose help we are extremely grateful) have been
> discussing the best ways to address the handful of issues which have been
> raised.

Comments from other ADs are asking about the comments that have not
been addressed.  The effect of this is that the ADs are reviewing and
don't know if outstanding comments from reviewers in last call will be
addressed.  I recommend asking the sponsoring AD if you could upload a
new version today.  I didn't cast my ballot after reading it yet as
the SecDir review wasn't addressed and Christian had some good points.

If we at least had a version to look at that addressed the points, it
would help some of us... even if it's posted elsewhere.

>
> One question under discussion has included a proposed amendment from IANA
> regards "registration" versus "delegation" and whether the notes kindly
> provided by IANA might, if their suggested amendment were made, cause a lack
> of orthogonality between the draft and other relevant documents. Suzanne
> raised that matter and we feel it's something best discussed and perhaps
> addressed in batch with other changes.

This would be important for all ADs to see.  Although the IESG is
copied on this message, it's a follow on from the SecDir review, so
they may not all read it unfortunately.

> That is correct and is the intention, although perhaps my preferred phrasing
> would be "present '.onion' names as if they were subdomains of some other
> domain within an arbitrary top-level domain" - since this is really about
> the existence of Layer 7 proxies attempting to provide 'semi-transparent'
> access to the Tor Onion network as-if the onion namespace were a virtual
> namespace of some corporate enterprise.
>
> https://3g2upl4pq6kufc4m.tor2web.org/
>
> ...which is the (independent, non-Tor) Tor2web organization's link to the
> DuckDuckGo hidden service; the onion address is hidden as the leftmost
> label.
>
> https://3g2upl4pq6kufc4m.onion.cab/
>
> ...which is a layer 7 proxy run by Seotecs UG in Germany, but whose choice
> of DNS domainname under ".cab" leads to a more obvious risk of confusion.
>

Do you have proposed text to address the concern about how the
security considerations section is written?

> Some bad things are possible, yes - HTTP man in the middle, not least - but
> to my mind the risks are little worse than risks the likes of
> "www.fac3b00k.com.cab" would offer, and in fact I believe such risks
> underscore the importance of registering ".onion" so that SSL EV
> certificates can be brought to bear upon the mitigation of some of these
> risks.

I think the question/request here is to more clearly state these
security concerns so that the security considerations are a bit more
thorough.

> https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
>
> If (upon that date) the ".onion" namespace has not been recognized as a
> global TLD, all SSL certificates for the ".onion" namespace will be killed
> and SSL will no longer be able to mitigate these threats for Onion sites.
>
> This will lead to the shutdown of the Facebook ".onion" site, another that
> is owned by blockchain.info, and the SSL service for The Intercept magazine,
> amongst others.

OK, can you propose text to clarify this point?

> body of the document included a short description of the TOR naming process

Understanding and seeing the proposed changes would help a lot for my review.

>
>
> Per the comments above, a draft explanation of Onion address syntax
> (summary: they will remain compatible with DNS syntax) is with Mark and
> Richard for discussion but is on hold for the reasons explained above.
>
> Regards Onion name "resolution", we believe that that matter is best dealt
> with outside the scope of this document, not least because the resolution
> mechanism is defined by software which is open to change.
>
> It seems more important to confirm that Onion addresses will remain legal
> within the constrains of DNS label syntax.
>
>

OK, stating this would hep to make the security considerations section
more complete.

>
> There certainly is leakage of lookups for the ".onion" TLD to the root
> servers, and eliminating that 100% is unlikely, but it is a wasteful thing
> and should be inhibited for reasons of hygiene rather than security.
>
>
> Tools which make a half-assed approach towards Tor access  by passing names
> through DNS resolution should be encouraged towards failure, but it is not
> required for security.

I think a discussion on this in the security considerations could be
helpful.  I see your pints when systems behave as expected and are TOR
aware, but also Christian's points on possible malicious use.  It's
helpful to put out the full set of considerations in a draft for
future readers who won't see this thread.

Thank you!
Kathleen

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2015 10:55:17 -0400

Supporting one point about updating the draft:

>> pursuit of a moving target
>

I really don't understand the allergy that some of us seem to have
toward updating drafts.  The fact that people are reviewing the draft
shouldn't matter.  Why, if there are updates pending, should anyone
consider it more useful to continue to have people review an old
version, when we could be posting a new one for review?  It makes no
sense to me, but it's common advice.

I suggest we encourage people to post revisions when they think it
would be useful, and only hold back under specific circumstances that
we think merit an unchanging draft for a while (such as, we have
updates proposed but they're still being batted around and aren't
ready to commit yet).

I'd rather have people reviewing the latest version, rather than
re-raising things that were already discussed and addressed.

Barry

---

From: Alec Muffett <[email-masked]>
Date: Fri, 28 Aug 2015 15:17:20 +0000

Hi Kathleen!

> On Aug 28, 2015, at 15:31, Kathleen Moriarty <[email-masked]> wrote:
> 

I shall have to punt that one to Mark Nottingham, esteemed holder as he is of all the drafts and master diffs. :-)

Regarding the other ADs, I have tried to address as many substantive questions as possible on the list - notably the extended "DNS-Syntax Compliance" thread - but seeing as I am a neophile at IETF process plus have no idea who the ADs actually are, I have not been in a position to chase them all.

It took me a while before I even worked out that I was permitted to subscribe to the IETF list, which I regret.

If there are outstanding undiscussed technical issues or questions which are inhibiting bringing this to a satisfactory conclusion, I hereby invite interested parties to throw them at me for resolution.

Suzanne's commentary to IANA upon the IANA feedback was as follows:

>> To: [email-masked] <[email-masked]>
>> Hi,
>> 
>> If I understand this correctly, your reviewer is suggesting an additional attribute of how .onion names should be handled beyond what's in Section 2 of the draft (which is incorporated by reference in the IANA Considerations)-- instructions to service providers besides DNS registries/registrars.
>> This is fine with me but given the level of controversy around this draft and the application of RFC 6761 generally, I suggest being very precise about the text. Sec. 2 of the draft is based on the template in RFC 6761, and what you're suggesting goes beyond what's in that template or called for by 6761.
>> As long as it's clear that this additional category is specific to this request, and not a reference to anything in RFC 6761 or intended to extend it, it seems like a good idea.
>> I suggest clarifying that most of the text in Sec. 2  corresponds directly to the template in RFC 6761, and then adding the additional instruction to service providers.
>> As a side issue, I'm not sure how human users would be expected to tell that .onion names are special. But it seems to me that there's no specific application behavior that depends upon this, so I'm also not sure it matters.
>> 
>> thanks,
>> Suzanne

A related draft amendment has been circulating amongst the Draft's authors and editors, waiting for the dust to settle somewhat, per the discussion above.  As an aside, though, I would here like to highlight the IANA action state:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/?include_text=1 <https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/?include_text=1>
> IANA review state: IANA OK - Actions Needed
> IANA action state: None

...which apparently means "Document requires IANA actions, and the IANA Considerations section indicates the details of the actions correctly" - which seems to suggest that IANA are positive about the extant draft, and that this is a matter of minor tweakage to them.

>> https://urldefense.proofpoint.com/v1/url?u=https://3g2upl4pq6kufc4m.onion.cab/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=%2FfAFQ13o0m7HiSM3O188bvFMSONzst4zlJ8bo6dYuRM%3D%0A&s=23bfc666beb74aba72eb6b16f7ba1c58c5aeeb3f75252e913372b1089c0f4858 <https://urldefense.proofpoint.com/v1/url?u=https://3g2upl4pq6kufc4m.onion.cab/&k=ZVNjlDMF0FElm4dQtryO4A==&r=PKCvk5ihsZdnlobuFIuhTw==&m=/fAFQ13o0m7HiSM3O188bvFMSONzst4zlJ8bo6dYuRM=&s=23bfc666beb74aba72eb6b16f7ba1c58c5aeeb3f75252e913372b1089c0f4858>
>> 

Not regarding this matter, as no concrete improvement has been seen as necessary; the current text:

   Also, users need to understand the difference between a .onion name
   used and accessed directly via Tor-capable software, versus .onion
   subdomains of other top-level domain names and providers (e.g., the
   difference between example.onion and example.onion.tld).

...seems to encompass the need for "consideration" of this point without restricting itself to advice which may become dated with future Tor software revision, or else commanding the user to perform research - which latter would appear to be a rude imperative.

> security concerns so that the security considerations are a bit more

Our thinking regarding this was that the risks described above are important, but they are not exclusive to the ".onion" namespace; it is entirely possible for a company with a registration for the "com.foo" top-level domain to create a layer-7 proxy forwarding to "http://google.com.foo/" and perform the same hack (mitigated by the same solution, viz: SSL).

To point it out at length as a risk in a onion-related RFC seemed unnecessarily pejorative.

Would you disagree? Do you feel that ".onion" has some special concerns in this regard?

>> https://urldefense.proofpoint.com/v1/url?u=https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=%2FfAFQ13o0m7HiSM3O188bvFMSONzst4zlJ8bo6dYuRM%3D%0A&s=b3befe71127444bd5c5d8342465f3d9cf5446aebfb7192e279c91459e23c80ae <https://urldefense.proofpoint.com/v1/url?u=https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=%2FfAFQ13o0m7HiSM3O188bvFMSONzst4zlJ8bo6dYuRM%3D%0A&s=b3befe71127444bd5c5d8342465f3d9cf5446aebfb7192e279c91459e23c80ae>
>> 

Again, this seemed unnecessary to explain in the draft in pursuit of registration of ".onion" as a special use domain name.

Should at some point in the future SSL be superseded, mentioning the historical artifact of Ballot-144 and the SSL-based reason for registration of .onion (which might be chugging along perfectly usefully on its own recognizance by then) would be strange.

Am I incorrect (or perhaps not thinking broadly enough?) to think that the goal of the draft is to register the special use domain name, and that the meta-discussion of "why?" is not *meant* to be in the eventual RFC?

Perhaps that information is meant to get included and then is cut out at the last moment before publication?  I would appreciate guidance on how this works, please.  :-)

> Understanding and seeing the proposed changes would help a lot for my review.

Mark, Richard, ... :-)

> OK, stating this would hep to make the security considerations section

For my clarity, I imagine you are suggesting that this consideration be added to the security consideration be added to the security considerations?

That would seem doable, if something sufficiently brief can be constructed, because much of the actual mechanism which should lead to the desired behaviour is described in Section 2 of the draft, the elements of which are heavily modeled upon the examples provided in RFC6761.

Continuing...

> helpful.

Excellent!

> I see your pints when systems behave as expected and are TOR

I think we can come to an accord, but the consensus of editors and authors will need to be involved to draft something.

Now: has anyone else any open questions regarding draft-ietf-dnsop-onion-tld-00, please?

    - alec

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 29 Aug 2015 20:10:44 +1000

Barry,

> On 29 Aug 2015, at 12:55 am, Barry Leiba <[email-masked]> wrote:
> 

*sigh*

I'm sure the authors will be happy to update the draft. The advice we Richard and I gave was ~two days before the IESG telechat, and it didn't seem wise to update it at that point.

If the IESG would like to set a clear, unambiguous policy about this, I'm sure it would be welcomed; personally, I've heard advice both ways, and have not yet figured out how to make everyone happy.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 29 Aug 2015 08:17:53 -0400

Hi,

Sent from my iPhone

> On Aug 29, 2015, at 6:10 AM, Mark Nottingham <[email-masked]> wrote:
> 
> Barry,
> 

The telechat is Thursday of this coming week.  Since there are a number of comments that require text updates, it's a lot easier to update then to have each AD chase down what changes are coming in various threads.

You are correct that opinions vary.  However, this draft is showing up with AD comments about outstanding comments from last call that need to be addressed and we usually don't see that.

If it's possible to update over the weekend, I'll read it again and will specifically look at updates related to the SecDir review.  Other ADs are likely to focus on other comment updates.

I'll find time later today to respond to the email on the SecDir review in case that helps.

Thank you,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Aug 2015 08:32:27 -0400

>> re-raising things that were already discussed and addressed.
...
> If the IESG would like to set a clear, unambiguous policy about this, I'm
> sure it would be welcomed; personally, I've heard advice both ways, and
> have not yet figured out how to make everyone happy.

I know, and I agree that we need to give clearer, consistent advice on
this.  Let's see if the IESG can get internal consensus on it, and go
from there.

In the meantime, the best thing is to let your individual responsible
AD say what her advice is for the particular document at the
particular time.  That way, you're not second-guessing that AD's
preference.

Barry

---

From: joel jaeggli <[email-masked]>
Date: Sat, 29 Aug 2015 14:16:09 -0700

On 8/29/15 3:10 AM, Mark Nottingham wrote:

> If the IESG would like to set a clear, unambiguous policy about this,
> I'm sure it would be welcomed; personally, I've heard advice both
> ways, and have not yet figured out how to make everyone happy.

Well... you can ask me. imho the situation looks like the following to me.

I think it's fine to have the discussion, propose the updates and hold
the draft update till the end; or to roll a new version as the product
of the discussion. The former runs the risk of accumulating a discuss
either from me or from another AD due to something that "really needs to
be addressed" prior to exit from iesg review. the later that we need
more time, if it comes shortly before thursday. ( the call is now at
0700 pacific) so it's extremely unlikely that I will manange to
re-review something submitted late wednesday evening.

I'm kind of waiting on the update to the iana language I asked for on
8/15 and that is a barrier to publication, but I expect we know what
it's going to say in that respect already so I'm not going to hold up
the dicussion on that...

thanks
joel

> Cheers,
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 30 Aug 2015 20:16:19 -0400

Hi Alec,

Thanks again for a quick and helpful response!

On Fri, Aug 28, 2015 at 11:17 AM, Alec Muffett <[email-masked]> wrote:
> Hi Kathleen!
>
>
> On Aug 28, 2015, at 15:31, Kathleen Moriarty
> Regarding the other ADs, I have tried to address as many substantive
> questions as possible on the list - notably the extended "DNS-Syntax
> Compliance" thread - but seeing as I am a neophile at IETF process plus have
> no idea who the ADs actually are, I have not been in a position to chase
> them all.

Ah, the AD comments will come in a bit more formally as a set of
comments and may include something they want to "DISCUSS".  Stephen &
Brian (I think) entered comments that referred to unanswered comments
from the last call process (from people other than ADs).  This may
just be the IANA questions answered here and I'm going to stay focused
on the security stuff to not duplicate efforts.

>
> It took me a while before I even worked out that I was permitted to
> subscribe to the IETF list, which I regret.

Please do ask questions on process or to learn more about the IETF, I
and others are more than happy to assist.

>
> If there are outstanding undiscussed technical issues or questions which are
> inhibiting bringing this to a satisfactory conclusion, I hereby invite
> interested parties to throw them at me for resolution.
>
>
I'll skip over the IANA text since others are working on that, but
appreciate you including the text and I have looked through it.
> If I understand this correctly, your reviewer is suggesting an additional
> attribute of how .onion names should be handled beyond what's in Section 2
> of the draft (which is incorporated by reference in the IANA
> Considerations)-- instructions to service providers besides DNS
> registries/registrars.
> This is fine with me but given the level of controversy around this draft
> and the application of RFC 6761 generally, I suggest being very precise
> about the text. Sec. 2 of the draft is based on the template in RFC 6761,
> and what you're suggesting goes beyond what's in that template or called for
> by 6761.
> As long as it's clear that this additional category is specific to this
> request, and not a reference to anything in RFC 6761 or intended to extend
> it, it seems like a good idea.
> I suggest clarifying that most of the text in Sec. 2  corresponds directly
> to the template in RFC 6761, and then adding the additional instruction to
> service providers.
> As a side issue, I'm not sure how human users would be expected to tell that
> .onion names are special. But it seems to me that there's no specific
> application behavior that depends upon this, so I'm also not sure it
> matters.
>
> thanks,
> Suzanne
>
>
> A related draft amendment has been circulating amongst the Draft's authors
> and editors, waiting for the dust to settle somewhat, per the discussion
> above.  As an aside, though, I would here like to highlight the IANA action
> state:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/?include_text=1
>
> ...which apparently means "Document requires IANA actions, and the IANA
> Considerations section indicates the details of the actions correctly" -
> which seems to suggest that IANA are positive about the extant draft, and
> that this is a matter of minor tweakage to them.
>
>
> https://urldefense.proofpoint.com/v1/url?u=https://3g2upl4pq6kufc4m.onion.cab/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=%2FfAFQ13o0m7HiSM3O188bvFMSONzst4zlJ8bo6dYuRM%3D%0A&s=23bfc666beb74aba72eb6b16f7ba1c58c5aeeb3f75252e913372b1089c0f4858
>
> ...seems to encompass the need for "consideration" of this point without
> restricting itself to advice which may become dated with future Tor software
> revision, or else commanding the user to perform research - which latter
> would appear to be a rude imperative.
>
>
> Our thinking regarding this was that the risks described above are
> important, but they are not exclusive to the ".onion" namespace; it is
> entirely possible for a company with a registration for the "com.foo"
> top-level domain to create a layer-7 proxy forwarding to
> "http://google.com.foo/" and perform the same hack (mitigated by the same
> solution, viz: SSL).

OK, that makes sense.

> Would you disagree? Do you feel that ".onion" has some special concerns in

I'd say just that there is special handling expected for this as
opposed to other TLDs.  The differences is where new concerns or
considerations exist.  You've pointed out a bunch of that already, the
SecDir reviewer thought it could be better organized.

> https://urldefense.proofpoint.com/v1/url?u=https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=%2FfAFQ13o0m7HiSM3O188bvFMSONzst4zlJ8bo6dYuRM%3D%0A&s=b3befe71127444bd5c5d8342465f3d9cf5446aebfb7192e279c91459e23c80ae
>
> Again, this seemed unnecessary to explain in the draft in pursuit of
> registration of ".onion" as a special use domain name.
>
> Should at some point in the future SSL be superseded, mentioning the
> historical artifact of Ballot-144 and the SSL-based reason for registration
> of .onion (which might be chugging along perfectly usefully on its own
> recognizance by then) would be strange.
>
> Am I incorrect (or perhaps not thinking broadly enough?) to think that the
> goal of the draft is to register the special use domain name, and that the
> meta-discussion of "why?" is not *meant* to be in the eventual RFC?
>
> Perhaps that information is meant to get included and then is cut out at the
> last moment before publication?  I would appreciate guidance on how this
> works, please.  :-)

You're right, the why isn't necessary for the draft, this background
was helpful though.
> Simple: it's not.  The goal of leak-reduction is to reduce leaks, rather

Are there privacy considerations with leak reduction?
> For my clarity, I imagine you are suggesting that this consideration be
> added to the security consideration be added to the security considerations?
>
> That would seem doable, if something sufficiently brief can be constructed,
> because much of the actual mechanism which should lead to the desired
> behaviour is described in Section 2 of the draft, the elements of which are
> heavily modeled upon the examples provided in RFC6761.
>

It's fine to have them in section 2.  When I read through them again,
what are the special security properties that users and applications
should recognize that are mentioned in the first bullet?  Are these
properties provided through the subsequent bullets handling
requirements?  I'm guessing that's the case, but since they are not
sub-bullets, I'm not sure.

> I think a discussion on this in the security considerations could be

OK, great, so I think just adding something on this point in the
security considerations would be good.  We are fine on the other
points and I just have the question about security properties for
section 2.

> I think we can come to an accord, but the consensus of editors and authors
> will need to be involved to draft something.

That sounds good.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 31 Aug 2015 17:58:01 +1000

Attempting to address all of the outstanding feedback I've seen:

* <https://github.com/mnot/I-D/commit/b3cdbbd0964532c88fefde3786d82b8bee1c62ee> uses .onion "names" instead of "addresses" consistently.

* <https://github.com/mnot/I-D/commit/941719e8de43a642c2fab9049927b60d23b7012d> clarifies the requirements placed upon registrars, as per the IANA review.

* <https://github.com/mnot/I-D/commit/bc57060e84ea338ff107f623b9e43498ee8d8309> updates the Tor URLs, but does NOT flip the two references suggested in Gen-ART to Normative; as per subsequent discussion, they aren't necessary to register the TLD, merely informative. Please advise if I read that wrong.

* <https://github.com/mnot/I-D/commit/358186a82887ed3907537bc45bd37937b4a6a09e> moves much of the generic explanatory text from Security Considerations into the Introduction, as per the SecDir review. 

* <https://github.com/mnot/I-D/commit/ca1eaaec5129f7ce82df8a749c11eb692de1059c> notes what happens when legacy systems get DNS queries leaked to them, as per the SecDir review.

* I didn't yet do anything to address this feedback in the SecDir review:

> Then, the security section also does not discuss how malicious name resolvers could be deployed in order to attack the TOR network. For example, if TOR security relies on DNS servers “black holing” misrouted request to resolve “.onion” names, what happens if malicious servers replace the suggested black-holing with some malicious tampering?

Christian, how would that work? I don't see how this kind of attack (by having a malicious server leverage clients who erroneously forward DNS requests for .onion) is going to be qualitatively different from any other attack on the Tor network; indeed, it doesn't seem like a very effective way to attack the network itself. Now, it may be that you can trick some users into thinking they're on Tor when they're not, in the right circumstances, but that's not an attack on the network. 

Can you give some more detail here (or ideally some suggested text)?

Cheers,

> On 30 Aug 2015, at 7:16 am, joel jaeggli <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Aug 2015 09:48:23 +0100

Hi Mark,

I thought there was also to be a change to say that .onion names would
in future need to continue to adhere to the DNS name syntax (lengths
mainly) just so that we don't get more ickkiness when/if .onion names
are handled by code expecting DNS names?

That wasn't from the secdir review but came up in the general IETF
list discussion in the last call.

S.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 31 Aug 2015 09:59:11 -0700

On Monday, August 31, 2015 12:58 AM, Mark Nottingham wrote:
 
> * <https://github.com/mnot/I-
> D/commit/358186a82887ed3907537bc45bd37937b4a6a09e> moves much of
> the generic explanatory text from Security Considerations into the
> Introduction, as per the SecDir review.

Good edit, thanks.
 
> * <https://github.com/mnot/I-
> D/commit/ca1eaaec5129f7ce82df8a749c11eb692de1059c> notes what
> happens when legacy systems get DNS queries leaked to them, as per the
> SecDir review.

The summary being, "if a legacy client mistakenly sends a DNS query for a
.onion name to a DNS resolver, the TOR security checks will prevent server
impersonation, but the client will have disclosed the intent to use the TOR
network to reach a specific service." The way I understand it, there are
parts of the world where disclosing such activity is plus plus not good,
correct? A mitigation for such leaks would be having the client's DNS
software act as a backstop and drop any request to a .onion name, without
relaying them.

> Christian, how would that work? I don't see how this kind of attack (by
having
> a malicious server leverage clients who erroneously forward DNS requests
for
> .onion) is going to be qualitatively different from any other attack on
the Tor
> network; indeed, it doesn't seem like a very effective way to attack the
> network itself. Now, it may be that you can trick some users into thinking
> they're on Tor when they're not, in the right circumstances, but that's
not an
> attack on the network.

How about:

A legacy client may inadvertently attempt to resolve a ".onion" name through
the DNS. This causes a disclosure that the client is using TOR to reach a
specific service. Malicious resolvers could be engineered to capture and
record such leaks, which might have very adverse consequences for the
well-being of the TOR user. This issue is mitigated if the client's TOR
software is updated to not leak such queries, or if the client's DNS
software is updated to drop any request to the ".onion" TLD.

-- Christian Huitema

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Sep 2015 10:47:39 +1000

> software is updated to drop any request to the ".onion" TLD.

Is that just a drop-in replacement for this?

"""
If client software attempts to resolve a .onion name, it can leak the identity
of the service that the user is attempting to access to DNS resolvers,
authoritative DNS servers, and observers on the intervening network. This risk
is mitigated when the recommendations in {{onion}} are followed, but are still
present when using systems that are not updated.
"""

Cheers,

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 31 Aug 2015 21:39:22 -0700

On Monday, August 31, 2015 5:48 PM, Mark Nottingham wrote
> present when using systems that are not updated.

You challenged me to produce some text, so I did... But I should have taken
a closer look at your change. We are definitely expressing the same idea. My
text is perhaps a bit more explicit, but it lacks the pointer to the
specific section in which the recommendations are made. Your text maybe
lacks the motivating part that fixing DNS software is part of "defense in
depth."

-- Christian Huitema