Re: [Add] draft-reddy-add-enterprise-split-dns, was Re: ADD Calls for WF Adoption

[Paul Wouters <[e-mail]>]

On Oct 18, 2021, at 02:42, tirumal reddy <[e-mail]> wrote:
> 
> 
> The "Enterprise" terminology was left over text from previous versions of the draft addressing only enterprise specific deployments. Based on the discussions and feedback from the WG, the draft has been updated to make it applicable to any type of private networks offering split-horizon DNS configuration.
> 
> We will remove the text from the Terminology section.

Okay.


>  Can you please give me (or better yet, in the document) and complete
>> example of the queries and responses sent? Because I still feel there
>> is a chicken and egg problem here. The location of PvD related to the
>> domain names in particular is what I don't understand.
> 
> You may want to look into the example given in the last paragraph of Section 4.1. In that example, the PVD FQDN can be "internal.corp1.example.com".

But this is the problem I don’t understand. If my internal network is corp.example.com, I can’t have my pvd fqdn within corp.example.com because the internal zone is not in the public dns, and your draft says to find the pvd in public dns. So there is no straight mapping of domains and then we are back at the security issue of one domain (pvd) vouching for another domain with no verifiable authorization of such a domain.

>  
>> 
>> What is the relationship between PvD-ID as FQDN and the domain names
>> (plural!) that I'm asking authentication of? Can I send a PVD-ID H-flag
>> pointing to pvd.nohats.ca? That would list "gmail.com" ?
> 
> The PVD FQDN conveyed in the PVD RA option and domain names in DNSZones could be hosted by the same entity. The HTTPS connection to the PVD FQDN would use PKIX validation to check if the PVD FQDN matches the DNS-ID in the server certificate (discussed in Section 4.1 of RFC8801) and match the "identifier" field in the PvD Additional Information JSON object. 

Sorry, I don’t understand the security flow.
If I am the owner of example.com and I want a split dns for corp.example.com, which DNS records do I need, what dnsZones and what pvd fqdn?  Note that corp.example.org does not exist in the public dns.




> 
> If a network wants to block newyorktimes.com, it can simply block access to all well-known DoH/DoT servers and if the client has enabled a strict privacy profile, it will not have internet access. The user has two choices: either use a different network or switch-over to the network-designated resolver. 

A user has only a choice if it is presented with the domain list. Will that be part of the protocol ? If not, how do you prevent abuse (eg Hilton wifi blocking Priceline) using this method. That is irrespective of wether other blocking methods exist.


> The presence of draft-reddy-add-enterprise-split-dns does not make it easier to block a domain. Domain blocks have to block resolution of the domain, by any means.  Which would include blocking DNS over Twitter, https://twitter.com/1111resolver, and DoH/DoT/DoQ and blocking https://mxtoolbox.com/SuperTool.aspx, and, and .... really, everything.
> 

If a user connects and automatically processed dnsZones then I think it does. Perhaps I will understand if you show me the full process for corp.example.org.



>> 
>> >      We are saying the same thing. Imagine Badcountry says "configure TRR to
>> IP a.b.c.d" or else. And now this whole protocol is triggered with their
>> potential impact with the (wrong) assumption that this is something the
>> user opted in to but are actually forced in to. Our goal should be to
>> make this as least attrictive to censors as possible.
> 
> If the BadCountry wants, it can mandate endpoints to install BadCountry root CA, spyware, malware etc. Please explain how this draft will help an attacker to configure a TRR. 
> 
> Most importantly, if BadCountry manages to configure its TRR in the endpoint, why is this draft required to enforce censoring ?

Currently, the network cannot tell me to send queries for certain domains to special servers. This draft changes that and I still do not understand the security mechanism that defends against this feature being abused.

>> 
>> > I see no capability in the
>> protocol for this, so using this protocol always causes a downgrade from
>> DNSSEC to non-DNSSEC.
> 
> DNSSEC validation will fail anyway if the endpoint decides to use the network-designated resolver. How is it working for BYOD devices today without MDM or configuration profile ?

the IKEv2 protocol can convey DNSKEY records to use on the private view. It’s part of the IKEv2 split DNS RFC.

>  So all offices of "nohats.ca" worldwide have to use the same single "discovered
>> network-designated encrypted DNS resolvers"? Because they will all get
>> the same answer from public DNS ? This would be hard to impossible to
>> manage for global companies with different IT departments in each
>> country or city.
> 
> Good point, the problem can be addressed if the discovered network-designated encrypted DNS resolver is a sub-domain of the NS RRset and if the server certificate includes both the domains. 

That still requires worldwide offices to work together on LAN deployment parameters. That’s not easy or foolproof, and could possibly lead to DNS resolution failures.



>> How does it validate the TLS certificate ? I don't think TLSA because
>> again that would be available only on 1 version in the world view, but
>> ns.toronto.nohats.ca might not exist in the worldview if
>> toronto.nohats.ca is the split dns name to begin with ? And the network
>> is likely on private IP space and we can't look up things there? That
>> leaves webpki but how are those going to validate private IP or
>> non-public names ?
> 
> PKIX authentication will be used by the client to authenticate the network-designated resolver. 

How will you get PKIX certificates for non-public DNS names to comply with ACME requests and CT requirements ?

>  
>> I believe it was Microsoft who recommended companies use ".local" or
>> ".corp" for their internal domain name. This document saying to skip
>> validation on those means these names cannot be securely used for split
>> DNS.
> 
> Browsers configured to use a TRR do not use DoH for ".local" domains by default (see https://wiki.mozilla.org/Trusted_Recursive_Resolver).  What is the need to perform validation for ".local" domains and how do you propose to perform validation for ".local" domains ?

So what about .corp or .internal or .lan ? It’s the same problem. 

>  
>> 
>> >           For example, if in a network the private domain names are defined
>> >           under "internal.corp1.example.com".  The DnsZones PvD Key would
>> >           indicate that "*.internal.corp1.example.com" are private domain
>> >           names.  The client can trigger a NS query of
>> >           "internal.corp1.example.com" and the NS RRset returns that the
>> >           nameserver is "ns1.corp2.example.com".  The client would then connect
>> >           to the network-designated encrypted resolver whose name is
>> >           "ns1.corp2.example.com", authenticate it using server certificate
>> >           validation in TLS handshake, and use it for resolving the domains in
>> >           the subtree of "*.internal.corp1.example.com".
>> >
>> >       It is unclear to me where the PVD Key (PVD ID, aka FQDN) for this domain
>> >       should be "found" ? See my comment above? It cannot be on the internal
>> >       resolver, that has not been approved yet as valid. Should it be done on
>> >       the public one? But then all split zones need to coordinate (eg all
>> >       *.starbucks.com need to link their coffeeshops to the same public PVD
>> >       info?). I don't fully understand the bootstrap here, and cannot determine
>> >       its security.
>> 
>> You did not answer this question, which is my biggest question actually
>> as the mapping between PvD domain and dnsZones entry is what I don't
>> understand.

I still don’t have an answer that allows me to follow the authorization and authentication steps of this protocol.


>> 
>> >       Security Considerations section:
>> >
>> >           As an additional precaution, clients may want to preconfigure global
>> >           domains for TLDs and Second-Level Domains (SLDs) to prevent malicious
>> >           DNS redirections for well-known domains.
>> >
>> >       This seems like a really big deal. It kind of says this mechanism cannot
>> >       be fully trusted. Preconfiguration of "well-known domains" in internet
>> >       protocols is very damaging to the decentralized nature of the internet -
>> >       it creates first and second class citizens/domains. If the draft cannot
>> >       address this problem, I would be tempted to look for alternative solutions
>> >       that stand on their own protocol without hardcoded lists.
>> > 
>> > No, the mechanism discussed in Section 4.1 is required to determine if the network-designated encrypted resolver is authoritative over the domain in
>> > DnsZones. The well-known domains are only used as a first line of defense to detect if the network is lying.  
>> 
>> Either your method is secure, and this "additional precaution" is not
>> providing security and should be removed, or it does provide some
>> security, in which it is hiding a fundamental flaw in the security
>> properties of this protocol.
> 
> The additional precaution is only added to speed-up the process of identifying if the network is lying. 
> We will update the draft to say the "additional precaution" is optional and even if the well-known domain check fails to identify the network is lying, the mechanism discussed in Section 4.1 is mandatory to identify if the network is lying.


Once the core protocol is clear, we can revisit the security considerations section. But this document makes core changes to security models by carving into the public DNS, and it requires careful consideration and mitigation in the protocol that’s more than a security consideration section.

Paul