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

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 29 October 2019 19:20 UTC

Return-Path: <brian.peter.dickson@gmail.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 270BB1209FB for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 12:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 hGq2_LTNzJDR for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 12:20:13 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 A0C89120168 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 12:20:13 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id l38so4180033uad.4 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 12:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ChwOhIgt4YLuUM24KNJA50vp+wUyoO3Oi0qd9Vbzp+A=; b=hQMsQYraWACI5yc59iPhDn9wluzRlK7spaFKezJ5G0cEzzgUhNoc22rOyKPLLYRw1z YwFx95m4yYFYELn/5S7+ZlDKfStaAvI16/01dMKDdevSP1O2kK1Ja+qZo/wvA6R/1ZqE pI1S1PPph0sZMJb55d85Tld04IcdY3qK87ZoL/fkucW7lHhD/mUG77y5BbXgjGFIj4/U ulTqnV+izm63zBTA0lnYYjdPWJvXQ9fSPOuGIO97vejHUV576PJMlVEJ/rZTD6lWAVxl UzuoKce88Kcr6cbrZxtakzkmBuWZrhzN6NxwJy6anDx64Y/nlesrPTMYk5hNlY/SDw// qWAw==
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=ChwOhIgt4YLuUM24KNJA50vp+wUyoO3Oi0qd9Vbzp+A=; b=ARDOH0Wz+92lTRz/9eFE0J+IbwF/FDUhmbZ4BQ8uN/1n9FbMAFiNjItRslfsnDPsWv TmZM8WvPkEdk0er+8FVSxuLleejBTf/K8/aa4xjVRTfGAYDnhLGQKpUHXdgVm+RcT0DS X9lKIxXbyIyuaJMmjU+0OU/ySCtYZUo15AGB7ObhvTxOeeXfYgPlD1i7pYc0p2aYk+YX b8De++0YpA+bHbfbelva9ZdWPRKgTzhofeQaWDuRsCwrpvVq5NtxgfFZrQbUJREvUJY2 1NNXKiMFsCUSiPxjiaKQrGrHE5w5KsPdHMooDrn04rjsCKNEoKP1BKp2bOIAw/0IIZ/2 9Hog==
X-Gm-Message-State: APjAAAU9LZN8j5TnXd9XaNTf6xSVegAQT7s7YGH5wGKQABJ8kL5FfPgY 7K1buPXEbDp2fZl3av8kkxvGMPkT8TOyt2Tpxp0=
X-Google-Smtp-Source: APXvYqxab7xcEPHFsPhSjWa4BtmO1KApTvfoY8/hSe7qMWtwNr5ln9VaMpjt4/Dyd3mCPzulpJi86+sVypenA8KVgX4=
X-Received: by 2002:ab0:189a:: with SMTP id t26mr12475300uag.87.1572376812449; Tue, 29 Oct 2019 12:20:12 -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>
In-Reply-To: <CA+9kkMCVj3Lte1dooNthm0f6eBPFUGbxdQBGyjB62KD8wn+f-g@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 29 Oct 2019 12:20:00 -0700
Message-ID: <CAH1iCir-Xe08h4eEepb_Cm1JSDcyE2Croh9fCaN-UaUb5_tvhg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Ben Schwartz <bemasc@google.com>, Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005bf40a05961181f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/_Q6-47Vf7fWy8EIBkZcYKp4lEEQ>
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: Tue, 29 Oct 2019 19:20:17 -0000

On Tue, Oct 29, 2019 at 12:07 PM Ted Hardie <ted.ietf@gmail.com> wrote:

> On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz <bemasc@google.com> wrote:
>
>> FWIW, my expectation has been that ADoT would use TLSA-like
>> authentication, with no trust anchors other than DNSSEC (and nothing
>> resembling the WebPKI).
>>
>> Which certificate usage are you thinking of, in RFC 6698 terms?
>
> Generally, I think TLSA-like authentication rooted in DNSSEC validation is
> fine.  But I remain pretty much of the opinion that if you get a
> certificate via that method that is "wrong" for values of wrong like
> "presented the wrong IP address or name in the cert"  or "fails DNSSEC
> validation" then you should do more than log the error.
>
> I also would like to point out that there are cases where you might have
> an authoritative server responding to recursive resolvers where there is a
> root of trust between them but where DNSSEC may not be validated:  split
> DNS.  Imagine for a moment that enterprise.example has a hierarchy that
> includes FQDNs like hostname.campus..internal.enterprise.example .  Each
> campus has its own recursive resolver, but they all talk to nameservers
> like ns.internal.enterprise.example.  In cases like those, the desire of
> the enterprise to not show its internal structures may mean that they do
> not wish to use DNSSEC to secure anything in internal, but they likely have
> a shared root of trust between the recursive resolvers and the
> authoritative server.
>
>
I think that is a very important use case, and also a good one to
illustrate the differences between the PKI model and the DNSSEC model.

PKI requires CRL/OCSP to handle any key problems or certificate revocation
or anything...
DNSSEC revocation can be done via DNS very quickly/scalably, although it
does also mean temporary loss of service if the new keys aren't also
available simultaneously. (That points to good BCP documents on managing
stuff.)

Distributing a localized DNS trust anchor is fairly straightforward, and I
have used such trust anchors previously in those environments. They work
exactly like you would expect. (At least for unbound, that is.)

Scaling for campuses works very well when you delegate from the signed
parental zone, and distribute the parental zone's trust anchor. Same model
as root DNSSEC trust anchor, different starting point.

Brian


> Put another way, I think you may need to support authentication using PKI
> trust anchors as well.
>
>  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
>