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

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Sep 2015 18:25:19 +1000

Applied in <https://github.com/mnot/I-D/commit/61535215c7b2fcf864faf08ada7b6117bf9a88d9>.

Thanks,

> On 1 Sep 2015, at 2:39 pm, Christian Huitema <[email-masked]> wrote:
> 
> On Monday, August 31, 2015 5:48 PM, Mark Nottingham wrote
>> 
>> On 1 Sep 2015, at 2:59 am, Christian Huitema <[email-masked]> wrote:
>>> 
>>> 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.
>> 
>> 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.
>> """
> 
> 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
> 
> 
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Sep 2015 18:35:55 +1000

Hey Stephen,

On 31 Aug 2015, at 6:48 pm, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 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.

See:
  https://github.com/mnot/I-D/commit/3b691672b94455f2038353ae03c04c3b1001193d

Note that I just stole that text out of RFC3986. If there's a better way to do it, I'm all ears.

Cheers,

> 
> S.
> 
> On 31/08/15 08:58, Mark Nottingham wrote:
>> 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:
>>> 
>>> 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: Stephen Farrell <[email-masked]>
Date: Tue, 1 Sep 2015 10:33:26 +0100

> Note that I just stole that text out of RFC3986. If there's a better way to do it, I'm all ears.

I think that's a fine change and reflects the list
discussion perfectly.

Ta,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 07:36:59 -0400

I still have the outstanding question on security properties that may be buried in this thread.

Thanks,
Kathleen 

Sent from my iPhone

> On Sep 1, 2015, at 5:33 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 Sep 2015 06:58:42 -0700

> I still have the outstanding question on security properties that may be buried

The question was, how could malicious DNS agents trick TOR clients into disclosing their presence. The recent exchange with Mark was about such agents passively listening for clients' mistakes. Is there a way to actively trigger such mistakes?

Such attacks would require actively sending information to clients, such as "if you have a request for example.onion, send it to me." The way to do that in the DNS is through NS records. Malicious agents could send an NS record for ".onion" as additional record in a response, asking resolvers to send them such traffic. This might trick legacy clients. Maybe.

-- Christian Huitema

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 10:07:41 -0400

> Such attacks would require actively sending information to clients, such as "if you have a request for example.onion, send it to me." The way to do that in the DNS is through NS records. Malicious…

My outstanding question is in my message from Aug 30th on Section 2
text that I think needs further clarification since the first bullet
makes a broad statement without naming the security properties people
are supposed to recognize.  Here is the snippet from that message
(similar to a point made by Alvaro as well):

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

It would be good to clarify this text to list the properties and to
see how the first bullet relates to the subsequent bullets.
-- 

Best regards,
Kathleen

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 Sep 2015 10:25:07 -0700

On Tuesday, September 1, 2015 6:59 AM, Christian Huitema wrote:
> > I still have the outstanding question on security properties that may be
> buried
> > in this thread.
> 
> The question was, how could malicious DNS agents trick TOR clients into
> disclosing their presence. The recent exchange with Mark was about such
> agents passively listening for clients' mistakes. Is there a way to
actively
> trigger such mistakes?
> 
> Such attacks would require actively sending information to clients, such
as "if
> you have a request for example.onion, send it to me." The way to do that
in
> the DNS is through NS records. Malicious agents could send an NS record
for
> ".onion" as additional record in a response, asking resolvers to send them
such
> traffic. This might trick legacy clients. Maybe.

Thinking about this a bit more -- this is the general problem of cache
poisoning. The additional section could also include A or AAAA records for
.onion domains. This could fool a caching resolver -- receive a request for
a name, check first if there is an exact match in the cache, and only
attempt to forward the request if there is no hit in the cache. The checks
in the draft are only considering request forwarding, not cache operation.

What about adding this text to cover the malicious server attack -- coming
after the paragraph on leaks by the legacy clients:
Malicious DNS agents could insert records for ".onion" names in the
additional section of DNS responses, with the intent of poisoning the cache
of DNS resolvers. These resolvers could then be tricked into serving the
record from their cache, bypassing the checks described in section 2. To
mitigate such attacks, it is important that caching resolvers prevent the
insertion in their caches of records for ".onion" names.
<<<
You may actually want to add part of that text in section 2.

-- Christian Huitema

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Sep 2015 09:55:29 +1000

See:
  https://github.com/mnot/I-D/commit/f9975381389d556709cfe77a520eae73ace0659c
  https://github.com/mnot/I-D/commit/cb43f69aa37f94baeb78aa3eca368dd712a06154
Do they suffice?

The references were flipped to normative here:
  https://github.com/mnot/I-D/commit/8486c73357b0421c013a6e99e90374c54190ce36

With all changes to date incorporated:
  http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt
  http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.html

Cheers,

> On 2 Sep 2015, at 12:07 am, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Sep 2015 11:44:42 +1000

Diff URL for the curious:
  http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dnsop-onion-tld-00.txt&url2=http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt

Cheers,

> On 2 Sep 2015, at 9:55 am, Mark Nottingham <[email-masked]> wrote:
> 
> See:

---

From: Alec Muffett <[email-masked]>
Date: Wed, 2 Sep 2015 11:36:26 +0000

Hello All!

Back from some manner of brief holiday, and I’ll try and pick up some loose ends without treading on Mark’s epic work.

>> The goal of leak-reduction is to reduce leaks, rather
>> than to assure security.
> 
> Are there privacy considerations with leak reduction?

Either leaks exist (likely) or they do not. It’s hard to conceive of where a reduction in efficacy of leak-prevention would benefit privacy, so onion-leak-reduction would seem to be one of those things that can be classified as "net win at scale” and the need for it should reduce with time.

>> 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.
> 
> 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 Mark’s revisions nail this with the “legacy client” paragraph.  :-)

I will skim the rest of the mails and try to consolidate the next response, if any is required.

    -a

---

From: Alec Muffett <[email-masked]>
Date: Wed, 2 Sep 2015 11:51:32 +0000

Ah, apologies, I see that I have just been unclear:

> On Sep 2, 2015, at 12:36 PM, Alec Muffett <[email-masked]> wrote:
> 

…nails the “blackholing DNS” matter with the “legacy client” paragraph.  :-)

I am quite confident that Mark’s latest diff:

http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dnsop-onion-tld-00.txt&url2=http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt <http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dnsop-onion-tld-00.txt&url2=http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt>

…covers the “human factors” element quite well.

The primary risks to users of Onion names are:

* prefix collision phishing such as facebookXXX.onion versus facebookYYY.onion
** best mitigation: SSL, hence this draft
** documented

   Users must take special precautions to ensure that the .onion name
   they are communicating with is the intended one, as attackers may be
   able to find keys which produce service names that are visually or
   semantically similar to the desired service.  This risk is magnified
   because .onion names are typically not human-meaningful.  It can be
   mitigated by generating human meaningful .onion names (at
   considerable computing expense), or through users using bookmarks and
   other trusted stores when following links.

* tld proxy-phishing facebookXXX.onion (real) versus facebookXXX.onion.tld (proxy)
** best mitigation: again, SSL, hence this draft
** documented

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

* leakage (risk to user)
** best mitigation: use current software. DNS NXDOMAIN will help reduce risk.
** documented

   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.

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Alec Muffett <[email-masked]>
Date: Wed, 2 Sep 2015 13:06:45 +0000

nit: “ well-being of the TOR user”

Tor is no longer an acrorym / not capitalised throughout.

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 2 Sep 2015 13:47:48 +0000

On 9/2/15, 7:51 AM, "iesg on behalf of Alec Muffett" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Alec:

Hi!

There is more there, but as an average Internet user (not a Tor user) I still don’t know what to look out for if presented with a .onion name (or something that looks like it).  I suspect that most average users will just click on something w/out realizing (ever!) it is a .onion name, and not a “plain old link” to some other page.

However, the more I read this thread the more I am convinced not much can be said/done.  Just like the facebookXXX.onion versus facebookYYY.onion case, average users don’t pay enough attention to distinguish between facebook.com and faceboook.com, much less would they know that .onion (or any other name for that matter) is special.  As you already wrote in the latest version, we can just hope that the appropriate sw is updated to prevent the average user from doing something they don’t even understand that may result in some leakage of information.

Thanks for addressing this point.

Alvaro.

---

From: Alec Muffett <[email-masked]>
Date: Wed, 2 Sep 2015 15:09:11 +0000

Hi Alvaro!

> On Sep 2, 2015, at 2:47 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> There is more there, but as an average Internet user (not a Tor user) I still don’t know what to look out for if presented with a .onion name (or something that looks like it).

That’s a really good point - is this document fit for the purposes of people who click on a link, expect it to work, and are surprised when it does not?

An example of this - where I was the author, and so I took steps to explain what would not happen - is on this page:

https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237 <https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237>

For people who don’t want to load that page, the relevant part is:

>> …To make their experience more consistent with our goals of accessibility and security, we have begun an experiment which makes Facebook available directly over Tor network at the following URL:
>> https://facebookcorewwwi.onion/ <https://facebookcorewwwi.onion/>
>> [ NOTE: link will only work in Tor-enabled browsers ]

…and there’s the thing: someone who is not using Tor will click on a link and nothing will happen, exactly as (for instance) I visit a coffee shop or my workplace and click on the bookmarked “http://router.local/ <http://router.local/>“ link which (when I am at home) would give me access to my DSL router’s control panel.

>  I suspect that most average users will just click on something w/out realizing (ever!) it is a .onion name, and not a “plain old link” to some other page.

Quite.  I believe that that is, in fact, rather the design goal.  Interoperability.

The onion network space consists of software, exactly like any other software (LAMP stacks, Wordpress, Facebook, etc) which is just accessed via a different address space, the latter being similarly to some VPN software.

Equally, my aforementioned router.local link *will* work when my VPN into my home network is working properly.

Similarly (again) - in my browser bar there are any number of links - or, for that matter, SSH connections - on the Facebook-internal corporate network which are not accessible from (say) my local Starbucks, again unless I have my corporate VPN software enabled - at which point everything magically suddenly "just works".

(aside) This is why I have always felt that using a scheme-change “onion://“ would not have been a good design choice for Tor Onion Names; my work life would be significantly more complex if I had to swap schemes when accessing a site over a VPN, a-la htvpntp://non-dns-name.internal/foo.txt

> However, the more I read this thread the more I am convinced not much can be said/done.  Just like the facebookXXX.onion versus facebookYYY.onion case, average users don’t pay enough attention to d…

Yes indeed, and I believe that the Ballot-144-enabled adoption of EV Certificates, with their big friendly green labels, will do a lot to reduce unwanted intermediary risk in Onion space.

Also, in passing, I do wish to point out, those “fooXXX.onion.tld” proxies which I have elsewhere presented as an unwanted risk, also do have a wanted and important role to play in making the world more open and connected; the (independent, non-Tor) Tor2web project was co-founded by the late Aaron Swartz (of whom some of you may have heard / seen documentaries?) in order to allow sites to publish via Tor to maintain anonymity, and Tor2web serves as yet one more bridge for the larger non-Tor world to access Tor/Onion resources.

More details on Tor2web are at https://en.wikipedia.org/wiki/Tor2web <https://en.wikipedia.org/wiki/Tor2web> - but to recap: there is a separate, parallel space of information out there, one that has been available for about a decade, and in order to bring greater trust to it and ensure that it is on a sound footing requires it to be slotted into the bigger picture of the internet and web.

Hence this draft.  It is what we are trying to do. :-)

   - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 2 Sep 2015 11:16:07 -0400

Thanks to you and Mark for addressing the outstanding questions from
the SecDir review and the one on "security properties".  What threw me
off is that what is described as security properties, I would call
security controls.  I'm not asking for a fix, but properties would be
more like confidentiality, integrity, etc., which the names themselves
do not provide.  The controls and usage provide additional protection.

Thanks,
Kathleen

-- 

Best regards,
Kathleen