Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

Ben Schwartz <bemasc@google.com> Wed, 30 October 2019 01:27 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 9F92E120119 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 18:27:32 -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 tzKgxy_ZsLc2 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 18:27:29 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 A6F0F12003E for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 18:27:29 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id 18so601948ion.6 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 18:27:29 -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=MEDx9evu2bxMQfK323XxwqVDSKcmmo3dKhtIRyVvlfk=; b=douxL38A3EvQbC1OLXJb1frRwDuTMUk+CDcvSeupEL5/CtSdZYda7hPGqjpC6wlLNi k844snJPJwGO5ehLuHpXPjpMOkR+OwBzcJbbFbBuoB1yit6zY8NgIvHQrgxjdO8FotcJ NROcAslOP90tD6XGhDcu6oIrVx+h1YYMenL+P8+nwzHOxBlxuGZ/AL+NbS5baejwfYt4 7gLA9wPUcsEET0G5g+k9l7+DQtYr5mR8k6611YrTbP6CRReIQqUhh+uen+eA+fn7nBlG qEG0eCHXLVj6+tZ/MRzT/C+wiVKiBEmLK0EfwFGEiSa8NOkSfieAHUcDTizcfYtJ7/c4 1Blg==
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=MEDx9evu2bxMQfK323XxwqVDSKcmmo3dKhtIRyVvlfk=; b=ZJkaESNIi8r4bh8X3ZFM7bFLOzndJWnKScX65y12bH4zm7Qg0ToFWKRHiHJRZXhvls 7oN0I85MgY8tAo1fupdrcz4s6iUbbSIGqY96RiRoApKIhTgaV9EJ7k0moSiJcmfifeUa UjjPVWVsav2drHeY4jz0izWqkEt+G7X0iVzHYhGSFnzskqh4plIKhy+2P2yoIG38h823 DgeCXo45EwcuyHEmxeVT1SJcSybdlsrV8HxNcYVH/4Ja+PqsCQVDLhsXuJbnnke42KFf 7Mu9U0BNYoV27DGrDfq16+EgmVBlaKosc9XR3pBQvfdsVGMAOCWbH0odKh/K8GCORbsC 3PrQ==
X-Gm-Message-State: APjAAAVVAJJmN5uXRA+R2YGBSMeziywa3S3Z91+2oipbSuogduG4FcpE VmQD7/naflAICjxxX2hm7bq1gSkYZK/pikFGhj9gfw==
X-Google-Smtp-Source: APXvYqyFFVAWQfmUaR85qjc4g2P8y2DNXRPtn1KGLZ+wFGgKiDzjvyvEIu4fk8cBOxQCm3cplcuD9ojrIKxNuqgPMR0=
X-Received: by 2002:a5d:9a0c:: with SMTP id s12mr5186051iol.41.1572398848558; Tue, 29 Oct 2019 18:27:28 -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>
In-Reply-To: <CABcZeBNTJYQc_1kbK7cL3S8KcHfEzpNsZaeK=OeYopEpjLF9_Q@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 29 Oct 2019 21:27:17 -0400
Message-ID: <CAHbrMsBaGBx-gye+Y+4Ja_a9Dkvkt6kLva3fzyvrzuuzxECZuw@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="000000000000da846d059616a2d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/JAW8bmV4CNFiI_zdpPYXYBAHx5k>
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:27:33 -0000

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.  Since the root is
signed, DNSSEC seems like the clearest path to secure ADoT bootstrap in the
foreseeable future.


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