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

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Thu, 14 Oct 2021 at 22:48, Paul Wouters <[e-mail]> wrote:

> On Thu, 14 Oct 2021, tirumal reddy wrote:
>
> > 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.
>
> That is not the traditional way of defining an "enterprise network".
> Also, the document _does_ define it:
>
>     The term "enterprise network" in this document extends to a wide
>     variety of deployment scenarios.  For example, an "enterprise" can be
>     a Small Office, Home Office or Corporation.
>
> It is not at all obvious that we can encounter this protocol at
> coffeeshop and hotel wifis, which have a strongly different security
> context from corporate enterprises (small or home or large)
>
> I can ignore the "enterprise" in the draft name, but not the definition
> in the document with the security aspects of the protocol. So in that
> way, my raised issues still apply and have not been addressed.
>

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.


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


>
> > Retrieving the additional PvD information using an HTTPS server is
> discussed in  https://datatracker.ietf.org/doc/html/rfc8801#section-4.1.
>
> I read that part, but it does not explain it to me well enough to
> understand:
>
>     When the H-flag of the PvD Option is set, hosts MAY attempt to
>     retrieve the PvD Additional Information associated with a given PvD
>     by performing an HTTP-over-TLS [RFC2818] GET query to "https://<PvD-
>     ID>/.well-known/pvd".  Inversely, hosts MUST NOT do so whenever the
>     H-flag is not set.
>
> 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.


> Please clarify
> the relationship between the internet-reachable PvD domain name and the
> target list of domain names the network wants to take over. Then also
> tell me how that would work for 50000 starbucks wifi networks?
>

The additional PVD information can provide the local network information to
the endpoints (see the "prefixes" field discussed in RFC8801).  The PVD
FQDN can be a HTTPS server located in each Starbucks WiFi network to
provide additional PvD information specific to the attached 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.
>
> You did not answer this question.
>

RFC2826 does not preclude private networks from operating their own private
name spaces  and https://datatracker.ietf.org/doc/html/rfc6950#section-4
provides more details to complement RFC2826 that in a split horizon, an
authoritative server gives different responses to queries from the public
Internet than they do to internal resolvers.




> >               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.
>
> that would improve things, but still leave this authentication method
> between starbucks consumer and starbucks provider to whatever thid party
> DNS server the consumer has installed, and requires that this third
> party DNS is reachable. If it is not reachable (eg lets say DoH and DoT
> is blocked) then this requrement fails. What does a client then do? Use
> regular port 53 from the local network? Refuse to send the query and fail?
> If the latter, then I can censor newyorktimes.com simply by adding it to
> my dnsZones and blocking all known DoT/DoH servers. In other words, this
> part of the protcol implies to do something security related, but it
> does not actually seem to add security AND it potentially adds a denial of
> service vector.
>

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.

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.


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


>
> >       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.
>
> It is not the public resolver that is the issue here, but the local one.
> Say my company uses DNSSEC to protect "nohats.ca" and now I'm going to
> the office, and connect to the split-dns. I wouldn't want to degrade the
> security to non-dnssec just because I cannot get the split DNS trust
> anchor for "nohats.ca" within this office in Toronto (which on top of
> things might also be differet from the split DNS trust anchor in use by
> my office in Helsinki). How can I get DNSSEC to work for "nohats.ca" in
> the split view DNS at various offices ? 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 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.
>
> 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.


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


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


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

-Tiru


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