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

[Brian Dickson <[e-mail]>]

On Tue, Oct 29, 2019 at 5:02 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie <[e-mail]> wrote:
>
>> Clipping away a bit where we appear to agree.
>>
>> On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz <[e-mail]> 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.
>>
>> 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?
>
> -Ekr
>
>
(Apologies in advance for "DNS-splaining" this, but I'd rather do that than
assume knowledge of some tid-bit.)

I am neither Ben nor Ted, but I think I may get the gist of the conundrum
that exists due the "unsigned delegation" (which was labeled "unsigned
child zone", but can even be the case if the child zone is signed but not
securely delegated.)

The term for the child zone or any of the child's descendants, if any are
signed, is an "island of security". That refers to a sub-tree of DNS which
contiguous and where every delegation in that tree is signed, and every
other record type is signed.

What the problem is concerned with, is that the unsigned delegation creates
a gap in the security coverage at the child, where the authoritative data
for the child zone is not DNSSEC signed, and therefore potentially
vulnerable to "cache poisoning" attacks.

And a successful cache poisoning turns an otherwise benign record into an
"attacker controlled" record.

The (literal) key to preventing this, is to put all of the relevant
components under a signed parent, where that signed parent is one such
"island of security".  That "island parent" would be DNSSEC signed, and the
secure entry to that zone (the zone's KSK hash) would be the "trust anchor"
for everything below it.

Here are some example "meat" of how this might look:
com has a secure delegation to example.com, with NS of ns.server.example.net
(out of bailiwick for example.com to avoid any short cuts).
com has the corresponding DS record for example.com, which matches the
DNSKEY at the apex of the example.com zone.
example.com is a signed zone.
internal.example.com is an unsigned delegation; it has the NS record
pointing to the appropriate server for internal.example.com.
example.com does NOT have a corresponding DS record since
internal.example.com is an insecure delegation.

HOWEVER, it is entirely possible that internal.example.com is the top of
the internal-only "island of security", and has DNSKEY records etc.
(Even if there is a level of totally unsigned DNS between the signed parent
and for example the signed grandchild, the installation of the trust anchor
of the grandchild creates the necessary element for DNSSEC validation of
anything in that grandchild's island of security.)

NB: The only missing component that makes internal.example.com an insecure
delegation, is the lack of the DS record in the parent zone at the zone cut.

Everything at/below internal.example.com can be DNSSEC signed and would be
possible to validate by any resolver that has the trust anchor for
internal.example.com configured.

At that point, assuming that all the resolvers referred to in the original
example have this trust anchor, everything DANE is available to use.

There are many different ways that the the certificates can have TLSA
records built for them.

Possible examples include:
Use of TLSA type 2 records that are identical for all certificates, where
the type 2 record corresponds to whatever CA (internal or otherwise, root
or intermediate) issued the certificates, at the owner name of the host of
each individual certificate.
Use of (signed) CNAME records that point to a single TLSA type 2 record ...
Use of TLSA type 3 (end entity) records that correspond to the actual
certificate itself (raw key, full certificate, or fingerprint), for each
issued certificate, at the owner name of the host in the certificate.

E.g. ns.internal.enterprise.example TLSA 2 x x { stuff }, and the cert for
ns.internal.enterprise.example has a cert chain that includes a cert
matching { stuff }.
The DNSSEC signature on this record validates based on the trust anchor for
"internal.example.com". This guarantees the validity of the TLSA record,
which can then be used to validate the certificate.

Note that the TLSA of type 2 or 3, does not automatically mean that the
certificate was NOT issued by a WebPKI CA. It only means that the WebPKI
validation does not depend on trusting the root CA that issued the
certificate.

Hopefully this is a clear enough description of what is meant, and
demonstrates a robust enough security model.

(The resolver SHOULD implement DNSSEC validation and TLSA certificate
validation, and if the authority server is using TLSA records, it MUST sign
the zones. The trust requires sharing the root trust anchor from the
authority server to the resolver. No sharing of private keys is required
outside of the DNSSEC signer, and the management of the TLS materials is
orthogonal to the validation model.)

The DANE model is very flexible, and as a result this general design
supports pretty much any imaginable scenario including this "split DNS" one.

Brian