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

Paul Wouters <paul.wouters@aiven.io> Tue, 12 October 2021 21:35 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ADF3A0A88 for <add@ietfa.amsl.com>; Tue, 12 Oct 2021 14:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvB2nf1cccEw for <add@ietfa.amsl.com>; Tue, 12 Oct 2021 14:35:45 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438503A0A86 for <add@ietf.org>; Tue, 12 Oct 2021 14:35:45 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id r18so1462389edv.12 for <add@ietf.org>; Tue, 12 Oct 2021 14:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=HQURr7E8I36c1J7KYuSdG/75iWAMoHrOzPHj0EDJEcM=; b=PFp4JzAkQAvkYmLCbVlirQpPk9WXCQ8zbCznGkMK1C8PERX4ZPqTWEl8ZfmOaH0bfE Zhi9PTOlrZd+5DGMbUNZ3Dd+lMVWZtqQn1d0jscs8tcNKsbTlEHj6K1AGV3KVsdUrKfI ADdf93x2U2+5L5/UsYW6niMHYMeCOraG0HuxI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=HQURr7E8I36c1J7KYuSdG/75iWAMoHrOzPHj0EDJEcM=; b=vz6JHyKjKevziFAvHMkZGo0IfQz8b/HTB1pvJZYsgFcCgVBn4YZlNN81DtQnA2HBef 4JN1J/ztA1UU23Nio3Ad2G6ETZQLvK8f/9T1nWSERn6w5M9is1ifrD6zxXtuHA+HhNX0 DDUST71QJpSeHOBpAM+1nYMTZk8LX0SQmK4VLhOT8oNtn5VKw204ViS2aHXhuAl8JZHT LbTKELNLXeEXC8jm8B6Sr1+Txru81GuIzER1C8jN4r6Iro0ZlzyWiOG9zaGOIzdscXiE zcY1xLX5C2Xs433C4HSnKWOiA+4xcPGEYQ9PBOIS+Nf6npvvA6BH3JXdAMVdJ90cSsEy 7z0A==
X-Gm-Message-State: AOAM531N5cMUYu4HmD3xfQI/NaJDC2iVGJrPYu7ndLgFdlh0f4nvjcMy ohqoR1MjoyoJn5vXsywdwZChm3YUaSBB8w==
X-Google-Smtp-Source: ABdhPJxp9pkJZlpVLN1Vf1hmfA4KNyoQxaiIrnd1XKIWPltsueivs3rQpMavLW2SD4BtNfHDjvmapQ==
X-Received: by 2002:a17:906:3d32:: with SMTP id l18mr15277524ejf.393.1634074543109; Tue, 12 Oct 2021 14:35:43 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id v13sm5511312ejh.62.2021.10.12.14.35.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 14:35:42 -0700 (PDT)
Date: Tue, 12 Oct 2021 17:35:36 -0400 (EDT)
From: Paul Wouters <paul.wouters@aiven.io>
To: "Deen, Glenn" <Glenn_Deen=40comcast.com@dmarc.ietf.org>
cc: "add@ietf.org" <add@ietf.org>
In-Reply-To: <2B5040C6-5A70-4DE6-ADF1-056D5CB0B524@comcast.com>
Message-ID: <338d8ed-6712-227b-e4d-6e4d603be5c4@nohats.ca>
References: <2B5040C6-5A70-4DE6-ADF1-056D5CB0B524@comcast.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="12647681-669332162-1634074542=:988893"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/IPYkaA36mgWy20ViBVgLH5AL0GQ>
Subject: [Add] draft-reddy-add-enterprise-split-dns, was Re: ADD Calls for WF Adoption
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2021 21:35:51 -0000

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.

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 ?

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?

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

 	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.

 	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.

 	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.

    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.

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