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

[Kathleen Moriarty <[e-mail]>]

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

On Wed, Sep 2, 2015 at 7:51 AM, Alec Muffett <[e-mail]> wrote:
>
> Ah, apologies, I see that I have just been unclear:
>
>
> On Sep 2, 2015, at 12:36 PM, Alec Muffett <[e-mail]> wrote:
>
> I think Mark’s revisions nail this with the “legacy client” paragraph.  :-)
>
>
> …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
>
> …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
>



-- 

Best regards,
Kathleen