Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
Ben Schwartz <bemasc@google.com> Wed, 30 October 2019 00:45 UTC
Return-Path: <bemasc@google.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 CF93C120059 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 17:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fwm6qUektyww for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 17:44:57 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 9D3FC120052 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 17:44:57 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id c11so489987iom.10 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 17:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n49kuHgv/AocMBNmPmlFVN/XRBoDVBiXrEPbsnsseSo=; b=Vgap+pdmxDnS0LECDOrq5ZPEDpcn6ULFZb+Qk4jpwEG46N4Qhea7686WGrJuWcCo01 gDrBZirpe02G/5qMJr4N4o2maeikIIO9XYRzCqACMOfhdLmjvUtrKV6RVuR7OqZQHqHh //ar2aKEdoSrRKvYjIUIlPEWFmjuj6NKpzLZVhD9yFh/NljdrOrfCZ4xLq/UNtOCXv6S jJOYGzXr841r7f+7+CWfko886mVbMPc8HCKf/jUvjTn11hQHSa9fdtVba7iTOjVTrYfZ 7gk44OMYDneN00GlXOYvJzc4bYC7F24XbFC8wMsFvYAxf2KpB4FBhghIJOQH2NZWmDXC qwcw==
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=n49kuHgv/AocMBNmPmlFVN/XRBoDVBiXrEPbsnsseSo=; b=rJcMjls942i1qLXW9HpnXJElTTDgftvJF6NrH+mpQfCeDEZlFfhcxQd5+grwHI8POA nLj6Sxhz6JyUlIEvPwzqIkrKqyPSqaqQImyoe2m3BWtHGteM5Pgz7ELnUSHOGby8/thu U5Pz5TPasqtbLHWVYMSZxQuTweMrTY8ps7CR8NyCXEEqgne47VQUuLnv4q8o5TWpon3P oPeas/vApMBNpllNg4I29I5kjIFloQJsoczU9ShicRgf8FiLaDg81/XTISI8Ne0gqipE snL6zm845NY6mlugyDUeefczoF1+1aZOdCwy5JA5RN1b/eR7HLTd0nj6lrCrD7G5qsHx /XgA==
X-Gm-Message-State: APjAAAXQ63SzauoyPL8J5VTp0T5txmB27E3es8zbkh03P0iaefY3Eao4 prBwg0H2DRRLS1bCcamHTTuV+icDK3sQUFr5xTxwLg==
X-Google-Smtp-Source: APXvYqyjklpcUFkf61Rld9aXKX36H0Acf9s/zABxa7HKgD4nCfLlb61Nhd7FdbRYm+vrTtRn/DOgMbKL3GSYOvtZIjE=
X-Received: by 2002:a5d:9a0c:: with SMTP id s12mr5045394iol.41.1572396296516; Tue, 29 Oct 2019 17:44:56 -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> <CA+9kkMA9=m67w=yPR4=cNmHvMH29ogzBVzA8GZU_HCBkVNUxOg@mail.gmail.com> <CABcZeBMyrW=D+dyoT3FUvfe+9hM7ZCndv=tZ9B2F170U0Z7obw@mail.gmail.com>
In-Reply-To: <CABcZeBMyrW=D+dyoT3FUvfe+9hM7ZCndv=tZ9B2F170U0Z7obw@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 29 Oct 2019 20:44:44 -0400
Message-ID: <CAHbrMsAgR-Andoxs5WRMp2jE3Gf_1EWWpsrAm3eFc-vGhb5A3w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000bd11b30596160aa2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/MH1UwEp7tT1aRpqNhy4MnL8cBJ0>
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: Wed, 30 Oct 2019 00:45:02 -0000
On Tue, Oct 29, 2019 at 8:02 PM Eric Rescorla <ekr@rtfm.com> wrote: > > > On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie <ted.ietf@gmail.com> wrote: > >> 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. >> > I was thinking of the proposals to encode the TLSA data (and probably some other NS-related info) in a "creatively repurposed" DS record (e.g. here <https://mailarchive.ietf.org/arch/msg/dns-privacy/G2BwaCvc7_G-NLkf1S51G4DGb6Q>). That would allow a signed parent zone to make verifiable claims about the child zone's configuration, even if the child is unsigned (i.e. has no other DS records). This is by no means a complete or solid proposal: even the people who've proposed it seem to have some concerns. 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? >> > > Ben, > > Is what you're saying here that .com provides the NS record for > example.com and that may not itself be example.com, but instead > ns.server.invalid, and therefore if you can't trust .com then it doesn't > matter if ns.server.invalid has a WebPKI cert? > My understanding is that one has no choice but to trust the parent zone, even with DNSSEC. I was more thinking of an on-path adversary who can intercept the NS query and reply with any response of their choosing. Thus, instead of "ns.example.com.", I get "ns.attacker.example.", which (as you said) will happily prove that it is ns.attacker.example. To put it another way: a recursive resolver has no way to distinguish between an unsigned parent and an on-path adversary. (I'm assuming that communication with the parent zone authoritative is over cleartext DNS.) > -Ekr > > >> 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 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