Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
Brian Dickson <brian.peter.dickson@gmail.com> Fri, 01 November 2019 15:46 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 E09F4120965 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:46:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BmMeB5GQu1em for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:46:03 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 E336D120954 for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 08:46:02 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id i13so3041847uaq.7 for <dns-privacy@ietf.org>; Fri, 01 Nov 2019 08:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k50l5i0kyi51RllL3hPLiMD0lFk2My3G+6IlmFbHM4Q=; b=eyfNnN88IANw+uEjvop7yl/lh1dLJEJVtHrG1NfmD7xYJSj2ZNU1Tk6bzok371yGPr 9Qf1+OfLnH+bs708d4el5xDzNuXsgVba3ulYnO4G06ZEB1SjYlCIODTY7pfkNCiHJfuy Kwe4Re39WmSLtQc5axpCj/QfB6R/nUzmmnDehSnwYJWm1QSAhOnOet6loJ6zr09oL1H8 TGpadA8WazSjAv4bhoVkBzUD0jRdNEGeafCDWRvqXSFL1xXmz9g7mHI25YSv/k6rMPvd gHN55YEyDabnnKzgvKYP2MJQvpdt3ACTwAK/uODxR3ONiaaZ/X0ocHk0+6soQ+oiZujw JuYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k50l5i0kyi51RllL3hPLiMD0lFk2My3G+6IlmFbHM4Q=; b=kUwEPtejfqyzAkCvH058wf2EJZo0dliwfQd75j8HYNtkkiVCDWr8eZInsbpbQ9l8ax ikHjC/dQOdI1G7bm2FUCMdqKWwSmVV9oov0XYWHNAPt/39wPh52XMPa5N+EY53/Gt43b 2dmpBbqLpz941+hnmJgfB3yfhMAVrW5cqJwv8FccVp4AAQghiu1DrJNZrsutp+X/OeS4 s//TnVhzofaOiTFcCQsbJxvDNDi/IimKQAijuy6KzLKFpnRD3S2PZNNhfuETEY+KFWJR KqvObDR6HlCRUuRZpsLTngoypxpyysRqWh6d5gaB9y1NR2nDonNgE00jS7TsbhLjgqVe F9ZA==
X-Gm-Message-State: APjAAAWfjj9U7YGM6yj2CYFhAwd3k9lskS+GoXvRqOt9zJ59zYWFbYt4 Xft2ydkJryIuNV4OaG1dUBnvVN6Q2TXca3bnRYQpaLY2
X-Google-Smtp-Source: APXvYqzCQUIBF6C+zUUFx0c9QiMSrf9zMHP651F9i8BtTZrogMeYxqm0lUv0TMpwT+ymYmxPDA0Z4j+txg87ISddq3I=
X-Received: by 2002:ab0:786:: with SMTP id c6mr6171417uaf.62.1572623161833; Fri, 01 Nov 2019 08:46:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com> <20191031211222.A6422DBC1C7@ary.qy> <CAH1iCiqYoXMZ0U3yt8AjUXyZVRdDnmHzSpHvYmg++ACZ-U6=zA@mail.gmail.com> <CABcZeBP-k23ZY=f6Lv5A+B+Z_4ar_9ea=G7O+KRriXNLUzKGqw@mail.gmail.com> <CAH1iCiq_HtErNkeq4hWQJnsDJPn1Zxv0uCLX+HK3QcsSzdxRww@mail.gmail.com> <CABcZeBOPWrqCcYWx+ei-O+QC_npfVhj1fG_kVFGFXhWkjyu28g@mail.gmail.com>
In-Reply-To: <CABcZeBOPWrqCcYWx+ei-O+QC_npfVhj1fG_kVFGFXhWkjyu28g@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 01 Nov 2019 10:45:29 -0500
Message-ID: <CAH1iCipnKn1yUKX0M1S1dxD8EVetGDF=0Gfo1hp2MgKwhvsqbQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: John Levine <johnl@taugh.com>, Ben Schwartz <bemasc@google.com>, dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ed3dc405964adcc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/UeBmnArdaZWalwe-jVGouwq7g_8>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
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 15:46:14 -0000
On Fri, Nov 1, 2019 at 10:34 AM Eric Rescorla <ekr@rtfm.com> wrote: > >> DNSSEC security is orthogonal to privacy, and is not a requirement FOR >> PRIVACY. >> > > I don't believe that that's correct in this case. The issue here is that > in order to provide confidentiality for the queries (in this case to the > authoritative) you need to authenticate the resolver. And that means > authentically learning the name of the resolver. So, for instance, if I go > the learn the NS for .com and the attacker gives me www.attacker.com, > then he can learn my queries. The name of the resolver can be authenticated > by DNSSEC or (less strongly) by having each query protected via secure > transport. > > Unfortunately (and I agree that this is unfortunate) the design for DNSSEC does not protect the NS record in the parent with a signature. The secure delegation does provide a signed DS, which means the child domain's DNSKEY can be validated, which protects the data on the child zone. However, the NS record used for the delegation, being unsigned, means the attacker can still MITM traffic towards the child zone. The validity of the child zone's NS records is signed, as would the corresponding A records if the NS *name* found in the child zone is also in a DNSSEC signed zone. (There is still the possibility of what amounts to "name chaining", e.g. if the NS name of the zone serving the child zone's NS name, is itself in a third zone, etc.) Protecting against this MITM requires not only DNSSEC on the child, but potentially DNSSEC on other related zones. It also requires that the resolver obtain the NS record and related A/AAAA records from the child, and then validate the certificate at the name of the NS, using CA validation or TLSA validation. TLSA validation avoids interoperability issues on CA trust, and avoids potential circular dependencies. TLSA validation only requires the use of the single DNS root of trust. So yes, DNSSEC is necessary, but compared to current resolver implementations (which don't always fetch the child NS data and validate it), is not yet sufficient. Brian
- [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] DPRIVE Interim: 10/29 Allison Mankin
- Re: [dns-privacy] DPRIVE Interim: 10/29 tjw ietf
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Rob Sayre
- Re: [dns-privacy] DPRIVE Interim: 10/29 Eric Vyncke (evyncke)
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- [dns-privacy] ADoT requirements for authenticatio… Paul Hoffman
- Re: [dns-privacy] ADoT requirements for authentic… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Hoffman
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Christian Huitema
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Watson Ladd
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ralf Weber
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] ADoT requirements for authentic… Tony Finch
- Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] ADoT deployment at the root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] ADoT deployment at the root Ted Hardie
- Re: [dns-privacy] ADoT deployment at the root Warren Kumari
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] ADoT deployment at the root John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Stephen Farrell
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Hollenbeck, Scott
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman