Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

[tirumal reddy <[e-mail]>]

On Mon, 5 Apr 2021 at 21:56, Paul Wouters <[e-mail]> wrote:

> On Mon, 5 Apr 2021, tirumal reddy wrote:
>
> > My coffeeshop uses Enterprise WPA. What if they start using Enterprise
> Split DNS ? What is the expected UI for me to accept / decline this as
> enterprise network ? What if they announce Gmail.com is
> > their enterprise domain ?
> >
> >
> > If a network lies about the ownership of a domain, it can be detected
> using the mechanism discussed in
> https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-10
> .
>
> note, it is very strange for the Security Considerations to define part
> of the protocol designed. That part does not belong in the Security
> Considerations section. It's not a consideration, it is part of the
> protocol!
>

Yes, we plan to fix it in the next revision.


>
> It states:
>
>         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.
>
> This raises a few problems.
>
> - The client needs to resolve the VPN internal domain externally to
>    prove it is NXDOMAIN or not delegated.


No, 02 version of the draft does not rely on NXDOMAIN or NSEC3 response.


> That means any network can
>    trigger the client into doing those kind of lookups to malicious
>    target domains, eg for tracking purposes


The DNS client only performs a NS lookup to check the authority over the
domains. Further, the endpoint does not automatically resolve the domains
and download the content. Most importantly, the user may or may not visit
the domains in the DnsZones.

I don't see a privacy leakage problem or security issue because of
malicious domains.



> - It assumes DNSSEC for the proof, meaning there is no solution for
>    domains without DNSSEC. It's completely spoofable.
>

If the client uses an encrypted DNS connection to a pre-configured public
resolver, DNSSEC is not mandatory. DNSSEC is only required when the
network-designated resolver is used to detect spoofed responses.


> - Most truly split corporate domains setup dummy placesholders for
>    their internal zones. Or just create different views for their 2LD
>    (eg different example.com internally and externally) and so in that
>    case there is a public delegation and this scheme won't work.
>

No, it works for both private domains and global domains but with a
different version on its internal network.
Please explain why the proposed mechanism does not work for global domains ?


>
> > Any unknown or untrusted network can use Enterprise WPA but the scope is
> restricted to explicitly trusted networks by the user (see
> >
> https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-3
> ).
> >
> >
> > If the trust comes from enterprise MDM, why can’t the provisioning issue
> the domain list in a verified authenticated way, instead of adhoc untrusted
> network broadcasts ?
> >
> > MDM is not a possible option in several enterprise deployments.
>
> sure, but that is just re-stating my observation.
>
> > The document deems this problem solved by adding
> >
> > The scope of this document is restricted to unmanaged BYOD devices
> >    without a configuration profile.  The unmanaged BYOD devices use the
> >    credentials (user name and password) provided by the IT admin to
> >    mutually authenticate to the Enterprise WLAN Access Point
> >
> > And this is exactly the scenario where a coffeeshop that provides
> user/password is the distinguishable from a presumed trusted IT admin
> pre-arrangement with credentials.
> >
> >
> > No, the scope of the document is restricted to explicitly trusted
> networks.
> >
> > <snip>
> >
> >    The scope of this document is restricted to unmanaged BYOD devices
> >    without a configuration profile and split DNS configuration on
> >    explicitly trusted networks.  In this use case, the user has
> >    authorized the client to override local DNS settings for a specific
> >    network.
>
> As I explained, the coffeeshops will require that trust. Your protocol
> will be used as something to coerce the enduser who has no choice but
> to "trust" the network if they want access. It is just not going to work
> in the real world to make this artificial distinction.
>

Some Enterprise networks already block access to public resolvers (e.g.,
DNS servers performing filtering can categorize DoH servers in the “Proxy /
Anonymizer” content category, see
https://umbrella.cisco.com/blog/doh-dns-over-https-to-block-or-not-to-block)
and can possibly use a captive portal to notify the user to use the
network-designated resolver. If a coffee shop wants to force the endpoint
not to use public resolvers, it can use a DNS filtering server to block the
“Proxy / Anonymizer” category or if destination IP addresses of flows from
the endpoint are not in the DNS cache, it can block those flows.

The draft currently says the following:

The SplitDNSAllowed key value set to false is an internal security policy
expression by the operator of the network but is not a policy prescription
to the endpoints to disable use of DNS servers not provided by the network.
If SplitDNSAllowed is set to false, the client MUST NOT trust the
SplitDNSAllowed key in case of connecting to unknown or untrusted networks
(e.g., coffee shops or hotel networks).  Most importantly, the endpoint can
choose to use an alternate network to resolve the global domain names.


>
> Note, as this can only be confirmed by the client when DNSSEC is enabled
> on the public parent domain, presumbly there needs to be an internal
> DNSSEC trust anchor too. How will this trust anchor be conveyed? We
> went through a number of rounds with RFC 8598 for IPsec to prevent
> VPN providers from installing (malicious) DNSSEC trust anchors that
> could lead to TLSA records and other sensitive public key record types
> in DNS from being redefined or taken over. The outcome was that
> basically that list gets provisioned by the IPsec client setup.
>

In this scenario, I don't see the need to override the trusted certificates
for TLS or install Enterprise CA certificates.


>
> As written, I just cannot support this document. It circles around all
> security issues by stating the client trusts the server/network.
>

No, clients do not blindly trust explicitly trusted networks. If a network
lies about the ownership of a domain, it can reject the network entirely
(because the network lied about its authority over a domain).

-Tiru


>
> Paul
>