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

[Ben Schwartz <[e-mail]>]

On Tue, Oct 29, 2019 at 3:07 PM Ted Hardie <[e-mail]> wrote:

> On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz <[e-mail]> 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?
>

I'm not very familiar with these terms, but I think I mean usage 2: "trust
anchor assertion".

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 agree: validation failure should generally be fatal.  (I expect we'll
need fallback behavior for some scenarios, but not validation failures.)

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

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!

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.

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.

 regards,
>
> Ted
>
> On Tue, Oct 29, 2019 at 12:01 PM Ted Hardie <[e-mail]> wrote:
>>
>>> Hi Paul,
>>>
>>> On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>
>>> _______________________________________________
>>> dns-privacy mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>