Re: [dns-privacy] Threat Model

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 01 November 2019 23:27 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40BA1208D2 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 16:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkXcdKe2AvIq for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 16:27:56 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EB71208CB for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 16:27:56 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id l202so9579293oig.1 for <dns-privacy@ietf.org>; Fri, 01 Nov 2019 16:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=I6Cnqpacsus/+GAnE8Hk5ZGbTjMxniwyEFuZdCUY5j8=; b=p8CE7BVPPRH7DSyoQQuFmnOFQ1zmXx8mgBnxcTH285btvyCqehFNoi5M3Yk8U20BMC 5pn51xgINcArmHT/KXKCpEAlOOMuS3jjbkLi9Z1OL/KzcKLIFd1A17QT6H9I5lRAGtJB 1DXtrM740qg9x5GPUbFStyWeJ5Iy0D2YFRAbxLgPgFQwtB+jcir3lr47ZaPFIkhLrLNN YKMPrmKjOKVeSLOzxGUldybsHZ/9cpBEP6VnuS+MWKUZpjYdegvp4IYLVv/8PxWEbEC9 HMhMdNELY1+sUEYrFsLIvDk+jjzaM/00O6NbD7oa+Zxaq++UHP21Z6cUwhENSGkvZRGw OxUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=I6Cnqpacsus/+GAnE8Hk5ZGbTjMxniwyEFuZdCUY5j8=; b=iwfo/xjEEmqysjXXf9fB/uLxNIQJFc+j+ArC22s2Gm3WcXptXvTjE4yqEGVP9t9ndh i1t2bMhnZthvwCd7nNxBRVfhN6W9KCEabMX9wNojMc8JpV0cO5fzFU8g4YRRPcPbrIl1 bjcMtQDdS66br8Z9PXYHpKVHhKiaCHWEvC74MgXQvuss23L9GQuDZBBhaMkaMrLpDUvr /mJfV9T/HNcufj6zgab9o5ZSufyNhgERnhalKx5VrL/MM1P8Ba4k4FCgwigIGkpLh0kX al8oVtGwpSzffMtXb8sf8FPZBYVAr984bMigTvkz9eo4TdR8UPdH39uuPVYB+myOReGO vNwA==
X-Gm-Message-State: APjAAAWSVw6oGt6R7dcd6y2SfWDewNKqt5wxLwrEgRX1f7DAc2Xkgo6m 13ug3zhHRqNo26lcC7+pUBI=
X-Google-Smtp-Source: APXvYqyYVSkmADclLL+yGM7Xvd5Npscnp1036aaOok5C7P7lcJB6h6bNFnwDZss7d9gAyXB5Vx7iPw==
X-Received: by 2002:aca:4c14:: with SMTP id z20mr7117868oia.76.1572650875584; Fri, 01 Nov 2019 16:27:55 -0700 (PDT)
Received: from [100.68.218.131] (BOINGO-WIRE.ear1.Dallas1.Level3.net. [4.14.17.198]) by smtp.gmail.com with ESMTPSA id w33sm2627488otb.68.2019.11.01.16.27.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Nov 2019 16:27:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-4C63ACB4-8531-41A4-947D-32D4F7B411F9"
Content-Transfer-Encoding: 7bit
From: Brian Dickson <brian.peter.dickson@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 01 Nov 2019 18:27:53 -0500
Message-Id: <BAC36911-1DF0-439D-A3C9-493FFD282015@gmail.com>
References: <CA+9kkMCoAduVAgoekUQiJVpW+WRBNcPaKcnBBEvZWu1DKF2LjQ@mail.gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, dns-privacy@ietf.org
In-Reply-To: <CA+9kkMCoAduVAgoekUQiJVpW+WRBNcPaKcnBBEvZWu1DKF2LjQ@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: iPhone Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/J_65v6gsM3jV98JFvmztqeu6t0w>
Subject: Re: [dns-privacy] Threat Model
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 23:27:59 -0000


Sent from my iPhone

> On Nov 1, 2019, at 4:27 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> 
> (cutting a good bit)
> 
>> On Fri, Nov 1, 2019 at 12:54 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:
>> 
>> 
>> If the attacker does not have access to the timing data, IMHO the R2A queries expose no PII, since the query data cannot be associated with an originating client.
> 
> In the cases where EDNS Client Subnet is used, it does seem to associate the query with a pool of potential clients even when there is no timing data; depending on the size of that pool, this could easily represent a loss of privacy.

Yes, ECS adds a whole extra dimension to the problem space. The particular issue arises entirely due to the source of the need for ECS.

It is an additional argument against centralization, at least from the perspective of comparing no-ECS to ECS. I think this was already telegraphed by Mozilla’s TRR requiring encryption to auth for use of ECS.

The degree of information leakage is probably some function of the granularity of ECS prefixes and the number of active clients on each ECS subnet, on a per name basis.

>  
>> In this case, an on-path active attacker isn't actually a threat (!!).
>> 
> 
> Even without EDNS Client subnet, the active attacker now has access to new targeting data.  Let us say that the active attacker sits in front of vlogsite.example.  If the attacker sees a query for free-disputed-territory.vlogsite.example, the information that specific recursives are seeing that traffic may be of interest to one or more of the parties disputing the territory.

I think you mean the attacker sits in front of the nameserver for vlogsite.example?

Maybe, but that prerequisite location is relative to the recursive and authoritative. In some cases, that may be a tautology (recursive is inside a given region, where all traffic exiting is known to be monitored, and the authoritative is outside). There may not be a privacy solution available at all, or not legally permitted.

I don’t doubt the interest of the attacker. I question whether additional DNS protocol stuff to address that specific issue has value if the eventual data traffic isn’t equally protected from detection (eg SNI), or whether that particular problem might be addressed better with a non-DNS-only solution.

>  
> 
>> If this strategy is used, this creates an interesting side effect.  On a busy enough resolver, the regular cache refresh traffic may be significant enough to negatively impact timing attacks against encrypted C2R traffic in determing IP/QNAME matches, even if port 853 is blocked and all traffic is on port 53.
> 
> 
> This is similar to the logic this working group used to conclude that doing the client-to-recursive first was the right choice.  I don't think the fact that it is still true when port 853 is blocked refutes the advantages of encrypting recursive to authoritative traffic.
> 

Me neither. The point was more about the fact that an active attacker needs to reveal her existence, and the above assertion was that the attacker’s goal would not be guaranteed (and thus affecting the risk/reward math, possibly enough to discourage the attempt).

> 
>> This risk needs to be given context, specifically where are the client, the recursive, and authoritative, and whether an attacker is able to block port 853 to cause the downgrade?
>> The current passive attack does not require the attacker to expose her existence, while port blocking reveals the existence (if not the identity) of the attacker.
> 
> I think Eric's point is different from a standard downgrade by port blocking.  If the attacker is on path and there is no authentication of the authoritative server, then a back-to-back user agent can be used to eavesdrop on the query traffic.  Your recursive makes a TLS connection to the attacker and sends a query; the attacker reads it and retrieves the answer from the authoritative server in order to provide you a reply.    You get the right answer (and can even use DNSSEC to check it), but the query stream still leaked to the attacker.  This is an active attack (because the attacker terminates the TLS connection and starts a new outbound connection), but the result is equivalent to what a passive attacker would get from port 53 data.

Yes. So doing DoT without DNSSEC to protect against name tampering could allow an active attacker to MITM.

That point should be part of the operational recommendations: sign the name and addresses and ideally use TLSA.
(It also puts similar requirements on resolvers to validate the same data).

Regards,
Brian