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

[tirumal reddy <[e-mail]>]

Hi Eric,

Please see inline

On Sat, 16 Oct 2021 at 04:31, Eric Rescorla <[e-mail]> wrote:

> I'm actually trying to work through the logic of this. As I understand
> it, suppose that I control example.com and I want to have it be split,
> I would do two things:
>
> * Publish something like the following in the dnsZones key.
>
>   { "identifier": "ns1.example.org", "dnsZones" : ["example.com"]}
>
> * Publish an NS record for "example.com" pointing to "ns1.example.org"
>
> Note that the text doesn't seem to say that the "identifier" field
> reflects the server, so I'm kind of guessing here.
>

The "identifier" field should match the PVD FQDN conveyed to the endpoint
in the PVD RA option (see
https://datatracker.ietf.org/doc/html/rfc8801#section-3.1). The client
establishes HTTPS connection to the PVD FQDN to retrieve PVD additional
information including dnsZones and prefixes.

The client will learn the network-designated resolver "ns1.example.o
<http://ns1.example.com>rg" using the RA option defined in
draft-ietf-add-dnr.



>
>
> A client which is conformant to this draft:
>
> 1. Looks up the NS record for example.com using a public
>    resolver (step 1)
> 2. Sees that it matches "ns1.example.org" (step 2A)
> 3. Connects to ns1.example.org 2(B). If that succeeds, then it
>    uses ns1.example.org to resolve example.com.
>
> Do I have this right?
>

Yes.


>
>
> Assuming this is so, how does the client learn the IP address for
> ns1.example.org? Ordinarily this would be a glue record when it
> retrieved the NS records. Is that what happens here?
>

The client will learn the IP addresses of ns1.example.org using the RA
option defined in draft-ietf-add-dnr.

-Tiru


> I've got some more questions, but I'll stop now and get back to
> them once I understand if this is right.
>

> -Ekr
>
>
>
>
> On Fri, Oct 15, 2021 at 3:21 PM Tommy Pauly <tpauly=
> [e-mail]> wrote:
>
>> 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).
>> 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
>>
>>
>> --
>> Add mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/add
>>
>