Re: [Add] WG Adoption Call draft-reddy-add-enterprise-split-dns

Eliot Lear <lear@lear.ch> Fri, 13 May 2022 08:20 UTC

Return-Path: <lear@lear.ch>
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 CE69BC14F73D for <add@ietfa.amsl.com>; Fri, 13 May 2022 01:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.944
X-Spam-Level:
X-Spam-Status: No, score=-3.944 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, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boiIERwpZ56A for <add@ietfa.amsl.com>; Fri, 13 May 2022 01:19:59 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB7AC157B34 for <add@ietf.org>; Fri, 13 May 2022 01:19:57 -0700 (PDT)
Received: from [IPV6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 24D8JmEH230524 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 13 May 2022 10:19:50 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1652429990; bh=LprGq3LCYsHVItpPdgU8SzEsRkzjeDnJ3Bxzkh7AYJU=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=SOMIJB9NEKTQr7rC8g4UeBGZpJ8V1ew4rxLZb8DA02+fMn/5yF+Uy2IVDTjozziZT Yagp1r3B7LSjszsJGOBapT3HaomZpPhZvHjGTzRmdYDt75CovfNG6uAOt29YMHVJre Fp3FQ9APdpSi2O/69G/dC5lZTaYss+r5SPQN106M=
Message-ID: <6091dcb9-0d91-6666-2c3f-ae8da960242b@lear.ch>
Date: Fri, 13 May 2022 10:19:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Paul Wouters <paul@nohats.ca>, bemasc@google.com
Cc: ADD Mailing list <add@ietf.org>
References: <BYAPR11MB3111FD2D0FF61231304A5F3DEAC29@BYAPR11MB3111.namprd11.prod.outlook.com> <CAHbrMsAcpHFon+JS9jsLdqANt+1FmkA_VDAwW4PSUDMJwtbavA@mail.gmail.com> <14b56185-4fe3-8e4b-adcf-22ddb624329@nohats.ca>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <14b56185-4fe3-8e4b-adcf-22ddb624329@nohats.ca>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------lI3i490WMRAjjCsmsCH9M7F1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/4fL3a1z53FgEw2R0toXAxv3Krtg>
Subject: Re: [Add] WG Adoption Call draft-reddy-add-enterprise-split-dns
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.34
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: Fri, 13 May 2022 08:20:03 -0000

Hi,

On 05.05.22 21:57, Paul Wouters wrote:
> The only real solution I see is one similar to the IKEv2 split-DNS case,
> one where there is basically an authenticated and authorized
> provisioning step that enables the user to join an "enterprise network"
> wich can demand all or a subnet of DNS traffic which the user is required
> to opt-in to. And even that is tricky when a user is kinda forced to
> accept to get any connectivity, say in a hotel or coffeeshop (or
> repressive regime) 

I think you are aiming at the fundamental problem, Paul: is there a way 
for the user to decide who to trust.  Ben's pointed out the UX problems 
with answering that question.  For enterprise assets that clearly has to 
be the enterprise.  The only question really is how to bootstrap trust 
in the enterprise.  Any draft trying to address split DNS has to assume 
that has happened.  That part can't be in scope here.

What this or any draft has to do is be a bit clearer in stating that and 
then show how that bootstrapping of trust is leveraged to address split 
DNS, either via resolver selection at a gross or fine level, or through 
other means.  Right now I think it is trying to demonstrate that through 
multiple mechanisms, and that is what is making things rather hard to 
follow.  That's because there is no one-size-fits-all solution because 
enterprises come in many shapes and forms.  To some, leaking a modest 
amount of NS records is okay.  The pollution argument you raise is only 
relevant in as much as domains outside the enterprise control would be 
polluted.  If that's not the case, then it's a matter for an enterprise, 
and nobody else's business.

So I support adoption of this draft, but I do think it needs a lot more 
work to be clearer on the bootstrapping that is occurring.

Eliot