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
>>>>>
>>>>