[dns-privacy] Threat Model

Eric Rescorla <ekr@rtfm.com> Fri, 01 November 2019 18:10 UTC

Return-Path: <ekr@rtfm.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 192EF120ED6 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 11:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 u__whSVtHjWj for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 11:10:36 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 77DE7120C79 for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 11:10:36 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id b20so7857074lfp.4 for <dns-privacy@ietf.org>; Fri, 01 Nov 2019 11:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Hn/eTv8daUIAqdd+w89osaDURGK1qwzjTC+sZZ5FRjk=; b=BzvZgcJyqKt4gJ5Bhim/Qh5OD2WljTx6WqKAbFKMHUbb0uxJVsC7hRUa4NQ8bGaOzx nhz6NjWdu5KMZazh7x7bxMRnz4N803jfFnnZ/pQKB9DZwVGVl0AS7MeABfiN3Di7avv7 n2NRNrjyY+VJqkNi0k3JfO5Rpc9bcwnhU3Y2EZvJW23DILy8H6UCYdK2bfizcZwpkCoL IAIzPl7PqxUzqkY0pcuHm2cRwEALdNsOJ6AlRnTuxwvj9Y9Ajpn7fwdtlI5/JGeB4hcE ygTv7rKyb//xjYKvodwuQCfputOqcnDGZU2ny5GlJJUsJ2Ldt81cMVe5dyrg+fGjrGuc c9ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hn/eTv8daUIAqdd+w89osaDURGK1qwzjTC+sZZ5FRjk=; b=S5RvJoUpXx0FW44mvS9hfXDZMdOv5zCtdS0kfJ7WotowvOAVUykouuRzyif3qthAQE khFqsTnlonFa58qmKYabfKeTWF2b4t5EIXNb+yVtTFlv7jrwDcjfSuQJ6l//vSwo/rBk CIVZZrlxHF0/oI1FD6ATHEldsAGB/OB9nJjxUA4imfY/ut+7NKm1e/HLP0QwMg5LzKIs JUdHNMVgNDHX7C7W0wKNq/CRlt+cdnZnN3EFDv2TrylYRGo1p5DTVyra9MEgKG2tu+Co S442+xCvUm9S5wQZT11DZukqPEmWl2AZusMMP8M9pBUNbZOrwhDpVtsvJK1oNNnEfOVw xncw==
X-Gm-Message-State: APjAAAXP54w4HjfJsc1x7Dr7GB11JDR8bMd8WEIxXkQkuvwx5SRdb86a Zf/Ei3PioxiDf+b+byxkuUVjK+tTeWkVOOGj3/tKpQud/lc=
X-Google-Smtp-Source: APXvYqz6ehUc0OW4b/aT9tNzGPhUK0avumFY0CfFtWHuRxKOZbe8wdlZugh4jOJ1IV2lu/2/yTMW+jSZhrgc+Ib6nsg=
X-Received: by 2002:ac2:4a72:: with SMTP id q18mr8347128lfp.184.1572631834153; Fri, 01 Nov 2019 11:10:34 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 01 Nov 2019 11:09:56 -0700
Message-ID: <CABcZeBMQEJ=LE8ATQYnJj59srsK47hf4HT3BMMg3X2crVfSUXQ@mail.gmail.com>
To: dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d66b4b05964ce19c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/bQ73QD9gl2E85nQArdwqeYXOrrg>
Subject: [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 18:10:41 -0000

It seemed like it might be a good idea to take a step back and talk
about threat model to see if we're all on the same page.

The set of threats I am concerned with is primarily about an on-path
active attacker who learns the query stream (i.e., the domains being
queried) coming out of the recursive resolver. It's of course mostly
inevitable that the attacker learns which authoritative servers are
being queried, but I think we can all agree there's still plenty of
information to leak here [0].


In the current DNS, such an attacker can of course just perform a
passive attack by listening to the DNS query traffic. It's possible to
straightforwardly exclude this attack by opportunistically attempting
DoT [1] to the authoritative. However, an active attacker can mount a
downgrade attack on the negotiation, forcing you back to
cleartext. So, unless you have a secure way of:

(1) knowing the expected name of the authoritative for a given query
    and that it supports DoT
(2) verifying that the server you are connecting to actually has
    that name

Then the attacker can just mount a MITM attack on your connections and
collect this data by proxying the traffic to the true authoritative.

Do people agree with this assessment of the situation? Is this form
of attack something they agree should be in scope?

-Ekr

[0] There are of course also integrity issues here, but (1) those
are addressed by DNSSEC and (2) if you solved the active attack
problem, that would provide some measure of integrity for the data.

[1] Or any secure transport such as DoH, DoQ, tcpcrypt, etc.
but given the focus of this group, I'll just say DoT.