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

[Tommy Pauly <[e-mail]>]

I agree with the sentiments being expressed on list that this document isn’t quite ready to adopt in this form.

There’s something here, but the problem being tackled here is larger than enterprise networks, and even split-DNS local network configurations. The use case for enterprise networks is a valid driver of the problem, but I don’t think we can solve it without addressing the problem of proving a relationship between a set of domains and a Provisioning Domain (where that domain can imply a set of DNS resolvers and even network paths that are correct to use). VPNs do solve this nicely today, but we are missing the mechanism to this in a trusted way without a VPN or managed configuration.

The core idea about identifying that a resolver is the “right one” was also one of the goals the work around our “adaptive DNS privacy” was centered around (https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery-01#section-3.2 <https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery-01#section-3.2>). In that, the client would have discovery using PvDs, and could confirm the designation of a resolver by the domain owner by looking at a web-fetched PvD file off of the apex domain for the zone. That was a different use case, but I think it shows that the space of solutions we can use to associate domains is broad.

Thanks,
Tommy

> On Oct 14, 2021, at 10:18 AM, Paul Wouters <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.
> 
>>      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.
> 
>> 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" ? 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?
> 
>>      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.
> 
>>              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.
> 
>>      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.
> 
>>      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.
> 
>>              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.
> 
>>              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 ?
> 
>>              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.
> 
>>          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.
> 
> 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
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add