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