Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
Ted Hardie <ted.ietf@gmail.com> Tue, 29 October 2019 22:54 UTC
Return-Path: <ted.ietf@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 6F367120112 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 15:54:57 -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 CoNkPbTW-Dnv for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 15:54:54 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 4844C12001E for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 15:54:54 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id h9so307179ioh.2 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 15:54:54 -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=eXGl+Ccrc1fJ8J9dDj+bPCaC36+qhDG8bgct0abibIE=; b=apfUYmyIk7qzxkxtzApJY9IO8fopuptah282Vx2+QZxG+eWQlUBxf3+XJY9Rx6bUZO 9n+CcQk1WbDLiDxbm4+oPkiKN7j8EXIjDU9Gxb9lM492Ev785ynO8GDNQEDNSqZQFXg2 uS9ZEZkg3d0q1NuR4CilXK3m0YE4jFzvZ5FkTyL9OMJIIliotkR90YwbtW5KjvFfpmRX Gusto/n+o92QMTDTITNkzhIF8FYEW+TYFaM+k+a233KtFl8PFcLiVc6CBcyOoNzXckK9 rr+h3lpZKv2VOSWmzUWV0sTW65V/02yEjmhJn6OiciAxyKgJNAB0gHBOfSL8PWZyZFMB ukgQ==
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=eXGl+Ccrc1fJ8J9dDj+bPCaC36+qhDG8bgct0abibIE=; b=PFhLFvAKm3nzn66MAD/x4R3AoMUhqW+G051iuNvYDwClHU1XjM4mM24ow8Z1sXMhjP qzsKjM4YDiEg1Pez+ZarF14qfso8ukvtq8kXxWs0FDpc3UUBPTEyR6BeB0Zs/rHv3ynT djG7F20XqyAzwHaOWHmnBWuNs0iQ0VlMCyr8bCoF8nF518l1+bC1S+12zCFdtUfu2eqy pcHbmlJcmDKxBGXfM5261WGNbsmrPO0U4Iu5JG7T3kjY73Px6MXGJ2vWk2xDPHnZm0Wh nHI2GXgrWObiyU+1hQDCNYjNa4Mxodf//hlGxQGnjF+6wadM8vsUmI2G8FaTOKNVHJRW p70g==
X-Gm-Message-State: APjAAAVx5XVeyY47fbOghrzoPmjjrd6A/lFwse434k/5JV+Glyakehnk oIWwd5UZHmbZllaMg4TcJjtD1HxY6ZmwEfeNBVs=
X-Google-Smtp-Source: APXvYqwEzq6cNhFEUI1gLVM8EDpAI9eafboWUaCGfJYZe6nPQyC41NhQpYsw4w6oARZ04MqSO310Gcj+q7FZ5jzVaXI=
X-Received: by 2002:a02:3943:: with SMTP id w3mr546034jae.57.1572389693241; Tue, 29 Oct 2019 15:54:53 -0700 (PDT)
MIME-Version: 1.0
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org> <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com> <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org> <CA+9kkMC5ynqK+8QO==5Pi_9edjTkJJ3yLHBHqJFOox8fi1_8HQ@mail.gmail.com> <CAHbrMsAAvadukzifKEj9eEWB91aDjmnu775F_YdtBaUHrHwDDQ@mail.gmail.com> <CA+9kkMCVj3Lte1dooNthm0f6eBPFUGbxdQBGyjB62KD8wn+f-g@mail.gmail.com> <CAHbrMsCU4b7yNwEfq1J0qsX3vbij+bLdXpanPMKaF+h6yqkXKw@mail.gmail.com>
In-Reply-To: <CAHbrMsCU4b7yNwEfq1J0qsX3vbij+bLdXpanPMKaF+h6yqkXKw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 29 Oct 2019 15:54:26 -0700
Message-ID: <CA+9kkMA9=m67w=yPR4=cNmHvMH29ogzBVzA8GZU_HCBkVNUxOg@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d48290596148155"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/8D7vyATpyH5N7tOOqgnkFj6f3vg>
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: Tue, 29 Oct 2019 22:54:57 -0000
Clipping away a bit where we appear to agree. On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz <bemasc@google.com> wrote: > This resembles the ongoing experiment <https://engineering.fb.com/security/dns-over-tls/> between Facebook and Cloudflare, where both parties have agreed to speak DoT by hardcoding the relevant parameters and special-casing the relevant authoritative servers. They didn't need an ADoT standard to make this possible, because the connection is a "closed system" based on an agreement between the two parties. In your corporate-internal scenario, the recursive and authoritative servers are even more closely tied, being operated and controlled by the same party, so a secure upgrade protocol is much less relevant than on the open internet. The admins can hardcode whatever authentication procedure they want. They can even use pre-shared keys! Agreed, they could also use pre-shared keys. But that means that we should not require in the standard that they use a specific method, but provide a method that works for the common case and allow for methods where other things are driven by specific deployment conditions. Leaving that aspect aside, if we suppose that enterprise.example is a signed parent zone, and internal.enterprise.example is an unsigned child zone, we can still potentially enable DNSSEC-rooted ADoT to ns.internal.enterprise.example, if we can find a way to put its TLSA data in the parent zone. I think this is worth attempting. I would really like to see a sketch of the design for that before it gets to be a foundation of the approach. I can picture both large flat zones and deep hierarchies where it could end up being a real tangle. But since that tangle is based on my headcanon of the design, it's liable to being very badly off. Put another way, I think you may need to support authentication using PKI > trust anchors as well. > Assuming PKI is used to validate the nameserver's name, I'm not sure it's sufficient, because this name is potentially attacker-controlled. If the parent zone is unsigned, I think opportunistic privacy is likely the best we can offer. I'm not sure what you mean by control the name here. To save me tilting at strawmen, would you mind elaborating? thanks, Ted regards, > > Ted > > On Tue, Oct 29, 2019 at 12:01 PM Ted Hardie <ted.ietf@gmail.com> wrote: >> >>> Hi Paul, >>> >>> On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman <paul.hoffman@icann.org> >>> wrote: >>> >>>> On 10/29/19 8:02 AM, Ted Hardie wrote: >>>> > To be sure I understand you correctly, in the second case, the >>>> connection would be made to some IP address (e.g. NASA's 198.116.4.181). >>>> The recursive resolver logs the details of the certificate, but it >>>> continues with the connection even if the CA NASA uses for the certificate >>>> is not known to the resolver? What does it do in the face of other >>>> certificate errors like expired certificates or certificates presenting a >>>> different name? >>>> >>>> It continues. This is exactly how opportunistic encryption is defined. >>>> >>>> >>> Just to be clear, it's my experience that accepting self-signed >>> certificates from peers does not equate to accepting certificate errors. >>> The situation in which you set up a connection to n.n.n.n and get a self >>> signed certificate saying "example.com" and when you set up a >>> connection to n.n.n.n expecting "example.com" and get a cert back for >>> "accident.example" are pretty distinguishable. I would expect some >>> configurations to accept the first without issue; I find accepting the >>> second deeply odd. >>> >>> >>>> > I have to say that I'm pretty surprised by the idea that TLS in this >>>> context should behave any differently than TLS in application layer >>>> contexts, and I'm a little concerned about having configuration options for >>>> this that amount to "ignore errors of types $FOO". >>>> >>>> TLS in application layers can specify that opportunistic encryption, >>>> yes? >>>> >>>> >>> I think you are using "opportunistic encryption" to mean something >>> different from what I mean by it. What I mean by it is "use it when you >>> can, even if you don't know in advance you can". Testing for DoT before >>> using a DNS resolver on UDP 53 and using it if you find it is >>> "opportunistic encryption", for example. >>> >>> >>>> > Accepting self-signed certificates is a known configuration, so I >>>> get that, but if someone has configured roots of trust, accepting other >>>> certificates outside the roots of trust in the configuration is pretty odd >>>> practice. >>>> >>>> Do you feel that there is a requirement that all recursive resolvers >>>> use the same set of trust anchors? >>> >>> >>> No. >>> >>> >>>> If not, and if you are against the use of opportunistic encryption in >>>> this case, >>> >>> >>> See above. I don't think I'm against opportunistic encryption. I think >>> I'm against starting to exchange traffic over a TLS connection with an >>> identifiable error. There are degrees there, obviously. Some folks would >>> say an expired but correct certificate should be logged but accepted, but a >>> flat out "wrong name presented" would likely get different treatment. >>> >>> who will decide what set of trust anchors all resolvers in all >>>> jurisdictions will use? >>>> >>>> >>> Everyone will decide who they accept? That's how the WebPKI works, for >>> all its shuffling glory, and with ACME/Let's Encrypt it has gotten very >>> easy to get a certificate that will often be accepted. >>> >>> Just my two cents, >>> >>> Ted >>> >>> --Paul Hoffman >>>> _______________________________________________ >>>> dns-privacy mailing list >>>> dns-privacy@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>> >>> _______________________________________________ >>> dns-privacy mailing list >>> dns-privacy@ietf.org >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> >>
- [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