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

[Kathleen Moriarty <[e-mail]>]

Hi Alec,

Thanks again for a quick and helpful response!

On Fri, Aug 28, 2015 at 11:17 AM, Alec Muffett <[e-mail]> wrote:
> 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.

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

OK, that makes sense.

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

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.

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


You're right, the why isn't necessary for the draft, this background
was helpful though.
>
>
> 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.

Are there privacy considerations with leak reduction?
>
>
> 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.
>

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.

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

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

That sounds good.

Thank you,
Kathleen

>
> Now: has anyone else any open questions regarding
> draft-ietf-dnsop-onion-tld-00, please?
>
>     - alec
>
>
> --
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
>



-- 

Best regards,
Kathleen