Re: [IPsec] draft-pauly-ipsecme-split-dns

Tommy Pauly <tpauly@apple.com> Wed, 27 June 2018 19:36 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE5130E9A for <ipsec@ietfa.amsl.com>; Wed, 27 Jun 2018 12:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 aBazNpXSW7dM for <ipsec@ietfa.amsl.com>; Wed, 27 Jun 2018 12:36:48 -0700 (PDT)
Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 914C71292F1 for <ipsec@ietf.org>; Wed, 27 Jun 2018 12:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530128207; x=2394041807; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gk6GXd6EiKWzhF5IZnZGz8lEjY7rnvPC9q0WJ3VfQQs=; b=f+CsUgJGXGR74fH4gwqIg/IFzmrJcL+8+mzm8Lnwyp90tnSu+aGUehqtTxMExxKV 3dODnRU94CHc5uelU6hegrPPhcU+Nv6veRHuA69tcp5rtKSc9H0Hb0/Fg+G3z+V7 YEGuF9thb6y03KUU1PzvK+suWoXUYC/FG476/mVhGhCVof0WfsS6Jt0DrAh9JCY+ wW82lzBrEX04okHDJXbGg3ShyfivslIlyTffiegpDHbucgltWTgvM2u6VpL5CIAP VfyeIV1nZk8Uoespp8KSVz2e4m61mLGIrcxjQZumAXmX2W7di0oXym0rAPmv02g7 RdbpSITUDatEMg9e/m+D1A==;
X-AuditID: 11ab0216-c7fff70000002f11-15-5b33e74e4df4
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 12.41.12049.F47E33B5; Wed, 27 Jun 2018 12:36:47 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PAZ00CA3YHAGDA0@mr2-mtap-s02.rno.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAZ00L00YB7JI00@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT)
X-Va-A:
X-Va-T-CD: e31db92b8c8f5711a33b42a4393a80ac
X-Va-E-CD: 2413bb9ef5d3dba75e59f2eb99558cea
X-Va-R-CD: bdf41d4ac0defeb0bb05a5d9060bb309
X-Va-CD: 0
X-Va-ID: 80a722ce-8dbe-40aa-9d40-09ea748a3056
X-V-A:
X-V-T-CD: d46b7fe6d2e0e85d372e19a774c4b542
X-V-E-CD: 2413bb9ef5d3dba75e59f2eb99558cea
X-V-R-CD: bdf41d4ac0defeb0bb05a5d9060bb309
X-V-CD: 0
X-V-ID: 9f61749c-68c3-4b86-b331-48d44f13a131
Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAZ00K00YAAVW00@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-27_05:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1
Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAZ00IOQYHAFYB0@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <20180621002642.GI4218@localhost>
Date: Wed, 27 Jun 2018 12:36:45 -0700
Cc: IPsecME WG <ipsec@ietf.org>, "draft-ietf-ipsecme-split-dns.all@ietf.org" <draft-ietf-ipsecme-split-dns.all@ietf.org>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
Content-transfer-encoding: quoted-printable
Message-id: <33D81E4D-2F1C-42F2-BB65-62C985140A2E@apple.com>
References: <20180619183459.GC4218@localhost> <CABcZeBPh33RMWy=pWVSWPp9cDrzrRrVQXgw1BKPLy_W0_Wrdgg@mail.gmail.com> <20180619224651.GD4218@localhost> <CABcZeBObub+rYYURt9SSumYqqWGxDMqhOG64oA+979n=mduXMw@mail.gmail.com> <20180619230148.GE4218@localhost> <CABcZeBNmavpZvzNRZBdOTKQYZ=yW=y2poaoVtsOeESNyRrG15Q@mail.gmail.com> <alpine.LRH.2.21.1806200002340.18235@bofh.nohats.ca> <23338.46863.5452.257270@fireball.acr.fi> <20180620220624.GH4218@localhost> <23338.59850.426646.482306@fireball.acr.fi> <20180621002642.GI4218@localhost>
To: Nico Williams <nico@cryptonector.com>, Tero Kivinen <kivinen@iki.fi>, Eric Rescorla <ekr@rtfm.com>, Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.100.13.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR3PyoTdf/uXG0wanZ4hYbe/6xWRztd7ZY 8focu8X+LS+AvPPP2SxOXTvCZvH+1iUmB3aPl6fOMXosWfKTyePw14UsHtdO/mX1+D6PyWPy 4zbmALYoLpuU1JzMstQifbsErox737cxFazkqbiz7iNzA+Nlzi5GTg4JAROJ25tuMXcxcnEI CRxkknh2v5MJJMErICjxY/I9li5GDg5mAXWJKVNyIWrWMUk0d3xkg3C6mCRaXi1ngZjELvHn 1w4oW1ti/dF9bDD2tL2fGWHsSRcPQ8W5JBZsPc0KYetK/Dy5mB3CZpNYf2IJE4StJTFr5Vk2 GPvF8T3sMPbkPduhejklzn+ZCBXXkTh2aiELxHGdTBL3bm2GOihbYunbeYwg30gIBEvsf6sM UbOYSeLFlDnsIHFhAQmJzXsSQcqFBYwk3qz4AXYzm4CKxPFvG5hBbE4BPYklxxeC3cYioCrx +cRJdpA5zALbGCWe9h0HK2IGevLJuwuskFC0kZi2+T4TxLL5LBLr7h8Du05EoJ1RYvrPbywT GBVnIQX3LERwz0IyawEj8ypG4dzEzBzdzDwjI73EgoKcVL3k/NxNjKB0s5pJbAfjvdeGhxgF OBiVeHgDuoyjhVgTy4orcw8xSnOwKInzftwlFi0kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB cYaTtbv7CeZ/l7Ijy9s7j12v0NaujjjBurj1xsT1j9/aZ2ZYiWoty7vmEPNiuvi9cA+uxel6 TpnRtx8JbduVXi+8xWon8yszDk27Lcrt0qZ1U1e2qDVIxs/YIpvcuVvyi7E005mpysWK3U7X Vsyf5Cj9Y/8r60fZkoZsX/q+nXmmzxfwfl2HEktxRqKhFnNRcSIACkDaiBgDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/G9dJccDzRjeKogNtPTmTu46eZqI>
Subject: Re: [IPsec] draft-pauly-ipsecme-split-dns
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2018 19:36:51 -0000

It seems like the conversation here stalled out a bit.

From my perspective, the feeling in the working group is that the functionality described in the document for dealing with Split-DNS and DNSSEC is the best thing we can do given enterprise deployment models, as long as it is clear that client must validate TAs against configured local policy.

I think the text that Paul added recently does aim at clarifying this point. Are there specific nits or changes we want to see in the text there? I’d like to see this document be able to progress soon in a way that everyone is satisfied with.

Thanks,
Tommy

> On Jun 20, 2018, at 5:26 PM, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Thu, Jun 21, 2018 at 02:56:58AM +0300, Tero Kivinen wrote:
>> Nico Williams writes:
>>> On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote:
>>>> So I think the feature that we can use TLSA records in the split-dns
>>>> is very important. I agree that it would be VERY BAD for the client to
>>>> just accept whatever domains server sends, and it SHOULD always verify
>>>> it against its local configuration.
>>> 
>>> Agreed.
>>> 
>>> But I also think that a REQUIREMENT that the client support and check
>>> local policy as to which domains to accept TAs for is sufficient to
>>> address the concern.  Isn't it?
>> 
>> Yes and no.
>> 
>> Yes, I think that is best we can do.
>> 
>> [...]
> 
> Agreed.
> 
> Now, is the concern enough to reject this I-D?
> 
> Nico
> --