[Add] Private IPs, DDR, and PR#11

Eric Rescorla <ekr@rtfm.com> Thu, 01 July 2021 22:18 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A56FF3A0B67 for <add@ietfa.amsl.com>; Thu, 1 Jul 2021 15:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 33_M3ETd4s90 for <add@ietfa.amsl.com>; Thu, 1 Jul 2021 15:18:12 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 1EB973A0B53 for <add@ietf.org>; Thu, 1 Jul 2021 15:18:12 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id g3so7955265ilj.7 for <add@ietf.org>; Thu, 01 Jul 2021 15:18:12 -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=JQw1KDSwoHga4Nlc2A9swlwchO/h8shbbkBDrCjRAQY=; b=uhu2bgprhSvPadvG/YF9HXWnf3oqiD8WolECP6DdAgBjdXaK/A1OvboetCG8XImh4l doXOEshN5SPNTa2NKlGEbrLx7MRuBT3FOkHRCWcKDu5YyLhSuiHKxSBKTclBi3LkWSg+ D4mjYtfIlFGzWRe7KUUoGKjr5HnEYPb9a2DeQDjVyUtXq2WRau8MF+lxxS+4QSgld+RV 5U1zXoWuagP5fGxCpDu04V3jlDfr+JtilO7mZsqroQtU+jpWSjlYUYZwVYfAtrCnn5ja 4fEEJjlhVLHYO5/iPbGKlzS+EcKaZA3u0mHpCFGsFVUbH4bVi2gKHs0K4hx8gM1+3kJt jfJg==
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=JQw1KDSwoHga4Nlc2A9swlwchO/h8shbbkBDrCjRAQY=; b=p4B9isinqAZ6mJqwkZBDfibQDrOB2QCc29JL5zwwq66mXWZpPs6IGVPL1826MCBtEd +ARCzRRSkU1Z1HRuviTf10QnG7WLbWnxFjKoyI1vToiNmvUN2pcNPXM5HMiPxoVK/4UV ooQh+jhiAiYvAdgTeB0o6x/wO3Vq9cxwYh2FV57bHnHqUUhpx16KSw9Zk9ua9oOLtxXt ilm99SgzYV+YTkylZOtHM1J+TbVx2HwBZ9+3vhUvHzI3GucP4brET9Py6OchwBf36H2O am/wB9jpjagARiAUpa6OU42aPp5CahPqLvbo5NRekAWn42jD0+PK9mZJrae/Nu0IqRA6 VFSA==
X-Gm-Message-State: AOAM531/zvk8LfCU40gfjvVrKPKQIlcNLkDsJp5vqrXi/XZ4yc8Pl5G6 ikdDhnxkZ4O28G1HbmEZgX9/BlsEFXgeceScnwSrd1tSOeKKCoKh
X-Google-Smtp-Source: ABdhPJw7YtUEbizwgZ1lv7c5wKb70Rb4DM+2is5wxBA8ThVr6sNgo6PaGuN1R/QDzbUX2rpgm8X91NAsYNwzZL6vNeE=
X-Received: by 2002:a05:6e02:47:: with SMTP id i7mr1178682ilr.35.1625177890261; Thu, 01 Jul 2021 15:18:10 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 01 Jul 2021 15:17:33 -0700
Message-ID: <CABcZeBOf2C9dSoYr2w6tEOLkpL_pBu5EhBh3HJWKf+iyAfafKg@mail.gmail.com>
To: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8a5b105c61736ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/NYik5dhJyTS7QeTJxVQACyCWOWo>
Subject: [Add] Private IPs, DDR, and PR#11
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2021 22:18:15 -0000

I've been spending some time thinking about PR#11 and trying
to figure out the threat model where it brings value. This
message is an attempt to get to a better understanding. As
should be clear, I'm a little confused, so if people want
to tell me why I'm wrong, that would be helpful.

First, let's start with what I take to be the network topology:

                   ISP Resolver
                        | <- ISP Network
                   CPE/DNS Proxy
                        | <- Home network
                    Users device

We have the ISP's resolver with a public address of  The
user has some sort of CPE with an external address of and
an internal address of The user's device has an IP of When the user's device does DHCP, it gets the address for its resolver, presumably because the CPE intends to proxy
or cache DNS, otherwise it could just serve the ISP's resolver address
( in DHCP.

The general assumption for the DDR threat model so far is that:

1. The user's device gets the address of its resolver securely
(presumably because DHCP is secure in some way). If that's not true,
then I think we can agree that DDR does not provide much additional
security benefit because the attacker can just substitute their own
resolver [0].

2. Either the home network or the ISP network is insecure, otherwise
you don't need DoX.

So, first, its not entirely clear to me what the Opportunistic mode of
S 4.2 provides. In this scenario, presumably the client will be doing
TLS to the CPE (because otherwise the IP address would be the
resolver's public address), which means that we are concerned with the
attacker controlling the home network. So, in this scenario, we are
only getting value if you have a network in which:

1. The attacker can *see* traffic not destined for their IP address
   (otherwise there's not much point in encrypting).
2. The attacker cannot forge traffic from another IP address
   (otherwise they can just impersonate the CPE because there
   is no certificate).

Are there an appreciable number of networks with these properties? If
so, can we write down where that happens and put it in Security
Considerations? If not, we should consider removing this mode.

PR #11
The idea with PR#11 seems to be to bootstrap up from a local IP
address issued via DHCP to some other address. PR#11 doesn't do that
great a job of describing the setting, but I'm assuming the scenario
is that we want to start from a situation in which we have a CPE-based
proxy and move to a situation in which the user's device talks directly
to the ISP resolver. Otherwise, presumably, we could just make do
with the mode in S 4.2. Is this right or am I missing something?
And the reason we're not just vending the ISP's resolver directly
via DHCP is that the CPE isn't upgradeable or potentially under
the user's control and not the network's?

So, first, what threat model are we concerned with:

1. If it's control of the home network, then why can't the attacker
   block the _SVCB record between the user and the CPE stopping
   them from upgrading?

2. If it's control of the link to the ISP, then why can't the
   attacker just block the resolution of the _SCVB record between
   the CPE and the ISP's resolver? Maybe the CPE is using DoX,
   but we're trying to protect against *future* compromise
   of the user's network?

Can we get this documented before we start designing mechanisms?
That would also help understand the effectiveness of the 5 minute

Finally, assuming I've understood things correctly, reaching through
the CPE in this way seems like it has the potential to bypass any
CPE-specific filtering that the user has has installed. Suppose I have
some CPE that uses the ISP DNS but filters out certain names; if the
ISP posts a _SVCB record that directs me to their resolver, doesn't
that cause that filtering not to work?


[0] Modulo cdisco-style steering where the address is matched up
against a trusted list.