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

Paul Wouters <paul@nohats.ca> Mon, 05 April 2021 16:26 UTC

Return-Path: <paul@nohats.ca>
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 4A9A53A1EB6 for <add@ietfa.amsl.com>; Mon, 5 Apr 2021 09:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=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=nohats.ca
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 kdhBGxsfdRYm for <add@ietfa.amsl.com>; Mon, 5 Apr 2021 09:26:51 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01923A1EB2 for <add@ietf.org>; Mon, 5 Apr 2021 09:26:50 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FDbdZ6t25z5CN; Mon, 5 Apr 2021 18:26:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1617640002; bh=0aEastZEM7jWaitgC99S8dg/AqnADleETn1b+1JnfDg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nzyTxjQeU7pGXIgrZHRCRNKB8tG7SLUaZkTE+Slcz/gm0lltJ52kmcfpXxD1/Xl9/ K+thCMo9n34OnvuRaFFDFu9lZo4q2xl4a9spNvnsdpnNkY/3CliZknabLssMN5hcmF 0+joAOs6Hf3pooVytQOzN6j+K5CaO2uqX8cCrDXg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 53Lbq_HdR9fj; Mon, 5 Apr 2021 18:26:41 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 5 Apr 2021 18:26:41 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 05A886029A70; Mon, 5 Apr 2021 12:26:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F17299B04; Mon, 5 Apr 2021 12:26:39 -0400 (EDT)
Date: Mon, 05 Apr 2021 12:26:39 -0400
From: Paul Wouters <paul@nohats.ca>
To: tirumal reddy <kondtir@gmail.com>
cc: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Vittorio Bertola <vittorio.bertola@open-xchange.com>, ADD Mailing list <add@ietf.org>
In-Reply-To: <CAFpG3gc4bHMGMmvTxH_PNqEgPjDHH4ESp-vFunq7Ek0MPdUBCw@mail.gmail.com>
Message-ID: <2e2a54d-5470-eca6-2beb-181cd0df60ae@nohats.ca>
References: <E54C6029-946B-4094-A753-5DD5A881C901@nbcuni.com> <55ED5E7F-2595-4E6D-BBE2-36F38C9A99E1@nohats.ca> <CAFpG3gc4bHMGMmvTxH_PNqEgPjDHH4ESp-vFunq7Ek0MPdUBCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/ITm-CXfft7llghST_2HXTCCTuvU>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt
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: Mon, 05 Apr 2021 16:26:55 -0000

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!

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. That means any network can
   trigger the client into doing those kind of lookups to malicious
   target domains, eg for tracking purposes
- It assumes DNSSEC for the proof, meaning there is no solution for
   domains without DNSSEC. It's completely spoofable.
- 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.

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

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.

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

Paul