Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
Eric Rescorla <ekr@rtfm.com> Wed, 30 October 2019 01:32 UTC
Return-Path: <ekr@rtfm.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 E6AE31200F7 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 18:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 v5JmXGeUjGM3 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 18:32:52 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 D758C12003E for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 18:32:51 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id s4so716459ljj.10 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 18:32:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pkTlA7Wax9apHwU6010A6GhOUJE22qwic2q2HkEG/V8=; b=g5INfo4l2n9BkkIZ9cAju8oM8yEi3CLcYetFQRyG42DQKZB5kHB9D0eT3TCZoCd3QT BME+S4gD2KXyZLeTFvu95pnpXdoC9JUbiuaS35rukW2KTKkg45hMx1XqUtSAfFw+Nhje l6lhMKQBkn4lsnf8nfyDCTqODL8xZbdLA+nzdZkszZAJ2+UBTpGov8lmKG2jw5V0vj7y oaRfQppofd6sBQEVFrHFvV9Ryuracz8e4gfn1qXQdnyQgsHubUs8IxqHPGT1EnR3VDrr Heu3KAxRlb7JTX4kTTa3tZJHaY6siwk2WDgydHm5lLnry5D+CxzwmG0TeMQnC4Hz18EP HPng==
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=pkTlA7Wax9apHwU6010A6GhOUJE22qwic2q2HkEG/V8=; b=Q+rxxb3X6ECKruDPiUcwKrILWcTeo427BlzU66DD2i/V3JrVSadTl19pxA+60naxoF 2pXLaHdwLK88mHMpe0PjNh3Vc6oKiBVQuq4hDhcMn826J/MzvWSiYyU0T1aJl0cwPMg5 G6Lspmq6JmZdA9DHpitbWYdxQKv/P6UPqGnt9VVm8DmonBR0oiKKLnXCyblEI24rmlBM 47RC0OmdotZ5ro+wuaOeaOzb+8oheRhxrXkYPqoXbFdpFxiUeLwYL13MnzXq5bMcAl/k 5q+mBmH0OI7tDYaPCObJ3nyjEfbMeySXvmeNR/lqwDNCMYHUa+vDaFSx4KN1QlRcMYQ4 Ka8w==
X-Gm-Message-State: APjAAAWZC5kZoAJs+ZiYt0+iRm+8OkYLdNbAiBh9zZ2ED2SqDu5kG1HN 4B+v5aeueKazrEt/7QW0gvWHmywrP3Q8Gb4SzrlU+A==
X-Google-Smtp-Source: APXvYqz74BIzWxYZwLIMrwpa/s93gbUNFaT3LiH2HyIEdxUIfqgvvPsIkACmdIlqLZe1PL5VQzOl7A7lIEu5duGWuL0=
X-Received: by 2002:a2e:8947:: with SMTP id b7mr4456529ljk.29.1572399170146; Tue, 29 Oct 2019 18:32:50 -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> <CAHbrMsAgR-Andoxs5WRMp2jE3Gf_1EWWpsrAm3eFc-vGhb5A3w@mail.gmail.com> <CABcZeBNTJYQc_1kbK7cL3S8KcHfEzpNsZaeK=OeYopEpjLF9_Q@mail.gmail.com> <CAHbrMsBaGBx-gye+Y+4Ja_a9Dkvkt6kLva3fzyvrzuuzxECZuw@mail.gmail.com>
In-Reply-To: <CAHbrMsBaGBx-gye+Y+4Ja_a9Dkvkt6kLva3fzyvrzuuzxECZuw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 29 Oct 2019 18:32:13 -0700
Message-ID: <CABcZeBP64qr81ccw+cbYy6FuQkgArS=G9_itEt8A_UfN8SO7GA@mail.gmail.com>
To: Ben Schwartz <bemasc@google.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/alternative; boundary="000000000000fb65bb059616b5f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/erHIdQvkmkchqfJZwJjmMla7_jg>
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 01:32:55 -0000
On Tue, Oct 29, 2019 at 6:27 PM Ben Schwartz <bemasc@google.com> wrote: > > > On Tue, Oct 29, 2019 at 8:53 PM Eric Rescorla <ekr@rtfm.com> wrote: > >> >> >> On Tue, Oct 29, 2019 at 5:44 PM Ben Schwartz <bemasc@google.com> wrote: >> >>> >>> >>> 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.) >>> >> >> Yes, I totally agree with this. My assumption had just been that we >> should assume that we were incrementally deploying but that your target was >> all TLS. ISTM that it's going to be very hard to reason about the security >> properties here if each step in the recursive resolution process isn't >> protected. >> > > Yes, it's hard, but I think it's worthwhile, because the prospect of > getting the root to offer ADoT seems very distant to me. > Why? Do we have estimates of the load level here as compared to (say) Quad9 or 1.1.1.1? Since the root is signed, DNSSEC seems like the clearest path to secure > ADoT bootstrap in the foreseeable future. > Perhaps. -Ekr > > >> >> -Ekr >> >> >>> >>>> -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