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

Kathleen Moriarty <> Tue, 01 September 2015 14:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3E5FC1B3768; Tue, 1 Sep 2015 07:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_75=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PosElWxr5G-5; Tue, 1 Sep 2015 07:07:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEA011A0369; Tue, 1 Sep 2015 07:07:43 -0700 (PDT)
Received: by wiclp12 with SMTP id lp12so32202305wic.1; Tue, 01 Sep 2015 07:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eg++FvuKK4ocqMiuBkiqY4377Og/6zPXHGIn7fOR7Po=; b=ju7Qbwt7PB4N13wTvsv8n5muiQIFeqxDfyEC2Iouwp5E1VKPQMJF0iMiW6hOGr+HCr VspjwdVF51kt6quSILhVCn6UzsM+i/Ulij4u7f+1YQmkKyIG8x/00AScuxQpJyayuMc2 Iyw3duCi+Ywmx1mAXNd6uA8YOnQoah2f3Qjf5+Cs2pCYoIOwmiFSMSVw0Meop7vURVYh bKToZqyKH8UkOQwTtNs9Zc/YJwS8VngeUEr+EarmOEp2PSw6e2+OXbAQ0BDngWxtG/l8 jL2EMTdMwkT7svEaGHvsPBrGU4bPpgcZ4j5gvHBCW2RUuMYeNz9i5wxHZd6uTKLqgGUa c9/g==
MIME-Version: 1.0
X-Received: by with SMTP id o5mr3466401wiv.36.1441116461816; Tue, 01 Sep 2015 07:07:41 -0700 (PDT)
Received: by with HTTP; Tue, 1 Sep 2015 07:07:41 -0700 (PDT)
In-Reply-To: <00be01d0e4be$50fcac40$f2f604c0$>
References: <007601d0c2c3$7615b610$62412230$> <> <> <> <> <> <> <> <> <> <> <> <00be01d0e4be$50fcac40$f2f604c0$>
Date: Tue, 1 Sep 2015 10:07:41 -0400
Message-ID: <>
From: Kathleen Moriarty <>
To: Christian Huitema <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: secdir <>, Alec Muffett <>, joel jaeggli <>, Mark Nottingham <>,, Brad Hill <>, The IESG <>, Barry Leiba <>
Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Sep 2015 14:07:45 -0000

On Tue, Sep 1, 2015 at 9:58 AM, Christian Huitema <> wrote:
> On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty 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.
> -- Christian Huitema

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,