IETF Logo Mail Archive

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

Tommy Pauly <tpauly@apple.com> Fri, 13 May 2022 23:24 UTC

Return-Path: <tpauly@apple.com>
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 46D23C19E879 for <add@ietfa.amsl.com>; Fri, 13 May 2022 16:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.675
X-Spam-Level:
X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.575, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 ngD2HymKlDoR for <add@ietfa.amsl.com>; Fri, 13 May 2022 16:24:53 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 386D7C19E87E for <add@ietf.org>; Fri, 13 May 2022 16:24:53 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 24DNOHMj056034; Fri, 13 May 2022 16:24:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=j9PFufK5AAX8frI3VivkjsmHrxnNAhkxFDE9cFTB288=; b=pRjvC3eXOiMcCIP8toyg/ZnWXJSSNspu3pNA5fCvKCVyYZjklikPo1QuciOBILPJwz5E YbWsdOyEpChkWYKx4BDjg8ijaE9qMZ2V0HQHGseXjh77/teMeOpB4EwtOfalvvPlw2/x hH8NYhBoWlLrCoa5Lr6dfP5Cwy+jnUXk7EpOHh5qaDhlWMKAmlIb9noBOAj8nITAP3VR hfQr+KASfS3qyr2TDDY+fMaSehJPN4X9I8yQfyM32qsASWqQa9sTeX0zmmFYk2aNB9pA lGnuDgtjmLpqD9Ok34y+3b67UPYf7J3YjdkccOn9ErIrWgqzdFnoyiKBglJMSDFQ2Fdh 9g==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3fwqe4r59g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 May 2022 16:24:51 -0700
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RBU00HZGH1EC600@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 13 May 2022 16:24:50 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RBU00W00GRLFM00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 13 May 2022 16:24:50 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 356f691afe621a9de1153e2bc14f15f8
X-Va-E-CD: 3debd0d4cce3975f64e9537e9a6d188e
X-Va-R-CD: 1a2e00f3be5cd8c96c2d482389b3a493
X-Va-CD: 0
X-Va-ID: 07197f20-177b-4167-a227-8d6bf8826e87
X-V-A:
X-V-T-CD: 356f691afe621a9de1153e2bc14f15f8
X-V-E-CD: 3debd0d4cce3975f64e9537e9a6d188e
X-V-R-CD: 1a2e00f3be5cd8c96c2d482389b3a493
X-V-CD: 0
X-V-ID: 8a6e1c20-834c-4460-b3dd-00d15e99e222
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-05-13_08:2022-05-13, 2022-05-13 signatures=0
Received: from smtpclient.apple (unknown [17.11.13.37]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RBU00OEKH1E2000@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 13 May 2022 16:24:50 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.100.1\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <6091dcb9-0d91-6666-2c3f-ae8da960242b@lear.ch>
Date: Fri, 13 May 2022 16:24:49 -0700
Cc: Paul Wouters <paul@nohats.ca>, bemasc@google.com, ADD Mailing list <add@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <4184DE80-6C80-463F-9045-66100F5AFDAF@apple.com>
References: <BYAPR11MB3111FD2D0FF61231304A5F3DEAC29@BYAPR11MB3111.namprd11.prod.outlook.com> <CAHbrMsAcpHFon+JS9jsLdqANt+1FmkA_VDAwW4PSUDMJwtbavA@mail.gmail.com> <14b56185-4fe3-8e4b-adcf-22ddb624329@nohats.ca> <6091dcb9-0d91-6666-2c3f-ae8da960242b@lear.ch>
To: Eliot Lear <lear@lear.ch>
X-Mailer: Apple Mail (2.3696.100.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-05-13_08:2022-05-13, 2022-05-13 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/2YofWoFvPW3SfUQt_IqBe5eTKDU>
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 23:24:55 -0000

I generally agree with this sentiment. I think this document needs refinement and a lot of discussion of the mechanisms, but this is a valuable problem to solve. I think this document represents one starting point, and as long as we’re willing to evolve the mechanisms based on the working group discussion, I support adoption.

Thanks,
Tommy

> On May 13, 2022, at 1:19 AM, Eliot Lear <lear@lear.ch> wrote:
> 
> 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
> 
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>-- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add

v2.23.0 | Report a Bug | By Email