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

[Ted Hardie <[e-mail]>]

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?

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.

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