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

[Alec Muffett <[e-mail]>]

Hi Kathleen!


> On Aug 28, 2015, at 15:31, Kathleen Moriarty <[e-mail]> wrote:
> 
> 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.


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.


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


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

>> To: [e-mail] <[e-mail]>
>> 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.


>> Precisely the same website is served though another proxy at:
>> 
>> 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>
>> 
>> ...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?


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.


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


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?


>> Incorrect; the main reason for registration of ".onion" is CA/B-Forum Ballot
>> 144:
>> 
>> 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>
>> 
>> ...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.
> 
> OK, can you propose text to clarify this point?

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


>> Simple: it's not.  The goal of leak-reduction is to reduce leaks, rather
>> than to assure security.
> 
> OK, stating this would hep to make the security considerations section
> more complete.

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

>> 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.
> 
> I think a discussion on this in the security considerations could be
> helpful.

Excellent!

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

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