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

[tirumal reddy <[e-mail]>]

Hi Paul,


Thanks for the review. The split-horizon DNS configuration is not specific
to Enterprise networks and is applicable to other types of networks
offering private domains.  The draft does not make any assumptions whether
the network is Enterprise or not based on the WiFi authentication mechanism.


Please see inline

On Wed, 13 Oct 2021 at 03:06, Paul Wouters <paul.wouters=
[e-mail]> wrote:

> On Tue, 12 Oct 2021, Deen, Glenn wrote:
>
> > I wanted to bring to the ADD Group’s attention that 2 documents have
> entered into CALL for WG Adoption in the last couple of days:
> >
> >  1. Draft-reddy-add-enterprise-split-dns
> https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
>
> [ I will review the second document soon ]
>
>
> I still have issues with the split dns document unfortunately. I still
> feel that it is designed the standard use case to work, without enough
> consideration for networks that are not strong enterprise IT based, or the
> malicious use of this feature.
>
> The core problem is and has always remained the security of any of the
> ADD documents. There is a battle between "trust the network for DNS"
> vs "never trust the network for DNS". This disagreement of views is
> not going away. At best, it can be clearly demarcated by Enterprise
> requirements. But those tend to come from Enterprise Provisioning. While
> I see value at standardizing that, I don't feel ADD is the right way
> of doing this based on the current documents.
>

As I have mentioned previously, the proposed mechanism in the draft is not
specific to Enterprise networks.


>
> This document can say that this is for "enterprise" networks, but an
> enduser does not know when it is connecting to an enterprise network or
> not. Even if it does, it is unclear why the user should trust a list of
> domains to "give away" to the local resolver. Should a Google Wifi at a
> Starbucks be able to redirect gmail.com ? Should "coffee.com" be able
> to be redirected by a Starbucks Wifi? Or by Java House Inc ? Who even
> is coffee.com? Can humans even made these kind of decisions? And if
> humans can't, do we think we can teach algorithms this ?
>

The network-designated resolver must prove authority over the domains as
discussed in
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-06#section-4.1,
otherwise, the client will not use the network-designated resolver to
resolve the domains in the "dnsZones" key. Most importantly, the mechanism
proposed in the draft does not require any end-user intervention to
determine authority over the domains.


>
> These problems are similar to IKEv2 split DNS (RFC 8598, of which I am a
> co-author) but in that case, there is an explicitly configured trust
> relationship (the VPN profile on the mobile device). Even then, the
> list of domains that could be redirected was _greatly_ restricted due
> to browser vendors being afraid of non-enterprise VPNs (eg public VPN
> services) being able to override DNS/DNSSEC/TLSA records, overriding
> the WebPKI. This document has all of the same problems, and it is
> unclear to me whether the listed RFCs for obtaining various bits of
> information - via the public internet - is going to securely convey
> that information.
>
> It seems a PvD ID is expressed as an FQDN, but before one client can
> decide to redirect a domain to an internal DNS server, it has to DNS
> lookup the PvD ID FQDN. Therefor it follows this cannot be in the same
> domain. So nohats.ca cannot put their pvd at pvd.nohats.ca. Then how
> can one do a trusted PvD lookup? Maybe I missed this in some of the
> other drafts and RFCs listed in this draft?
>

Retrieving the additional PvD information using an HTTPS server is
discussed in  https://datatracker.ietf.org/doc/html/rfc8801#section-4.1.


>
> It also seems a redirected domain cannot provide an alternative DNSSEC
> trust anchor via PvD ? This would prevent split DNS domains from
> effectively using DNSSEC in the split non-world view, OR the internal
> zones and worldview zones are required to use the same DNSSEC KSK/DS
> as to not break DNSSEC validation on the client. I believe that if you
> want to securely redirect DNSSEC protected queries to an alternative
> DNS server, the solution should be able to support DNSSEC protected
> queries from the split network.
>
> Section 4.1:
>
>         To comply with [RFC2826] the split-horizon DNS zone must either not
>         exist in the global DNS hierarchy or must be authoritatively
>         delegated to the split-horizon DNS server to answer.
>
> I am unsure how this "authoritatively delegated to the split-horizon DNS
> server" works? Unless it means "single public reachable DNS server with
> bind views". I don't think these two methods would cover most of the
> split DNS zones currently deployed. I think RFC2826's advise in practise
> is a ship that sailed a long time ago. This is again an important issue,
> because it is the base of trust going forward. The client will receives
> answers it has to trust, but I don't see the full verifiable linked chain
> clearly. I am not sure if that is due to the document text or my
> understanding of it.
>
>         The client sends an NS query for the domain in DnsZones.  This
>         query MUST only be sent over encrypted DNS session to a public
>         resolver that is configured independently or to a network-
>         designated resolver whose response will be validated using DNSSEC
>         as described in [RFC6698].
>
> I have strong objections to treating DNSSEC validation and "outsourced
> DNS validation over secure transport" as equivalent. Transport security
> is not data origin protection.


Good point, we will update the draft to clarify that a DNSSEC validating
client will apply the same validation policy to the NS query as it does to
other queries.


This statement has the underlying claim
> that the outsourced DNS query to a public DNS server over TLS is
> equivalent to a DNSSEC protected query (over TLS or not). It is not
> equivalent. I have concerns about TRR and ADD type DNS resolvers getting
> mandated by nation states as internet entry points, and ADD really helps
> building such a censorship infrastructure.


The client would use the proposed mechanism only if it is configured to use
a DNS resolver not signalled by the network (e.g., the endpoint is
configured to use VPN or a public resolver).  If the client is using
DNR/DDR to discover and use the network-designated resolvers, it does not
have to use this draft and the split-horizon domains will be resolved by
the network-designated DNS server.


> One MUST be able to require
> DNSSEC to ensure domain owners keep control of their domain and not lose
> it to a nation state with bad intensions.


If the client is using a public resolver, it is anyway receiving all the
queries from the endpoint including the queries for private domains and the
bad public resolver can do a lot more damage than lying about the
non-existence of a domain.


>
>         The client checks that the NS RRset matches any one of the ADN of
>         the discovered network-designated encrypted DNS resolvers.
>
> Which NS RRset is it supposed to check? The RRset at the parent
> (unsigned!) or at the child (validatable). Current practise already
> sees so many mismatches between these two (called lame delegations)
> that I think this cannot be used by the ADD client to determine
> applicability unless there is a Section of test clarifying what it
> should do with respect to different NS RRsets.
>

The client will have to check the NS RRset at the child and not at the
parent level. We will update the draft for better clarity.


>
>         If the match succeeds, the client can then establish a secure
>         connection to that network-designated resolver and validates
>         its certificate.
>
> I guess it cannot build a secure connection _until_ it has validated
> its certificate? There are subtle implications here, as in the
> connection cannot be blindly used, it must first go from unvalidated
> to validated before it is available.
>

Sure, we will fix the above line as follows:

If the match succeeds, the client establishes a TLS connection to that
network-designated resolver and validates the server certificate exchanged
during the TLS handshake.


>
>         As an exception to this rule, the client need not perform the
>         above validation for domains reserved for special use [RFC6761]
>         or [RFC6762] such as ".home.arpa" or ".local".
>
> What about those split DNS worlds that use .local locally. There are
> many. Should all of them skip validation? That is a security issue
> that should be addressed in a better way.
>

I don't get the above comment, please elaborate on the need to perform the
validation for .local domains.


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


Cheers,

-Tiru


>
> I think this document is using "enterprise deployment" in too easy a
> way. WPA2 Enterprise is deployed by coffee shops, so the protocol
> specifications says nothing about the how the protocol will be used.
> So to me, this protocol is "Access Point split DNS", and I have to
> figure out if the access point is trusted or not. It seems that the
> validation of this depends strongly on being able to reach public DNS
> servers, which is often not the case. For example ISP redirectin of
> 8.8.8.8 to their own servers, country level blocking of public DNS
> for censorship reasons, etc.
>
> I am still not convinced that any client (browser) should ever enable
> any of this (ADD) for their own security. In fact, I would almost argue
> that setting up an IKEv2 VPN _just_ for configuring DNS using RFC 8598
> would be a better solution. It would require an explicit trust
> relationship between client and network, installed with consent of and by
> the enduser, and would be limited to the security considerations of RFC
> 8598. And it would support internal zones with their own DNSSEC keys
> different from the public zones. Of course, I don't want to securely
> provision my phone or laptop for all the coffeeshops brands in the world,
> so we need something better. But so far, I don't think this draft is
> providing me with a strong alternative solution for reconfiguring part
> of my DNS.
>
> Paul
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>