[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 [127.0.0.1]) 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-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, 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 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 192.0.2.1 | | <- ISP Network | 192.0.2.100 CPE/DNS Proxy 10.0.0.1 | | <- Home network | 10.0.0.100 Users device We have the ISP's resolver with a public address of 192.0.2.1. The user has some sort of CPE with an external address of 192.0.2.100 and an internal address of 10.0.0.1. The user's device has an IP of 10.0.0.100. When the user's device does DHCP, it gets the address 10.0.0.1 for its resolver, presumably because the CPE intends to proxy or cache DNS, otherwise it could just serve the ISP's resolver address (192.0.2.1) 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. OPPORTUNISTIC MODE 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 timeout. 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? -Ekr [0] Modulo cdisco-style steering where the address is matched up against a trusted list.
- [Add] Private IPs, DDR, and PR#11 Eric Rescorla
- Re: [Add] Private IPs, DDR, and PR#11 Michael Richardson
- Re: [Add] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 Tommy Jensen
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 Deen, Glenn (NBCUniversal)
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 STARK, BARBARA H
- Re: [Add] Private IPs, DDR, and PR#11 Eric Rescorla
- Re: [Add] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] Private IPs, DDR, and PR#11 Andrew Campling
- Re: [Add] Private IPs, DDR, and PR#11 Eric Rescorla
- Re: [Add] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] [EXTERNAL] Re: Private IPs, DDR, and PR… Tommy Jensen
- Re: [Add] Private IPs, DDR, and PR#11 Eric Rescorla