Re: [DNSOP] [Ext] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

Ted Lemon <mellon@fugue.com> Tue, 27 November 2018 17:30 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C83130DD2 for <dnsop@ietfa.amsl.com>; Tue, 27 Nov 2018 09:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 tcCs9Wr7Hm0Z for <dnsop@ietfa.amsl.com>; Tue, 27 Nov 2018 09:30:16 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 0B2AD1292AD for <dnsop@ietf.org>; Tue, 27 Nov 2018 09:30:16 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id d19so15062327qkg.5 for <dnsop@ietf.org>; Tue, 27 Nov 2018 09:30:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FKfVs9nPlzx3JHF8r+S3MgDvsyjgAmQQ35/kdN+hBwo=; b=1uslzOU9wsDSKHKapkm8Me03W75eVKFqmrYLw0HXZtzf939c8PuaPeMlk4LK4BtebD eojmHcKZxDrcfB8wkHik8loCYAQ7WRuR15VooEBwTuVcmX+WSG2X5MhvVibm/9/nOx51 GYEnUOx8PniR9HIjo38e1hIwRWjxkaIpxSguwRnGWF3rfSsTNUeroWfifpj+d3UhI5ub 2pLmJbycHppAWbatDKVJZNa0X/2ox66Y6UVEJ9Sm3m0QLi/8BdHGdeN6NaGIeh+J1k0c 6qo1Z4P6jzR5ZFSrhbFK6TWNn3/LMK7rAt+p73YuDnp29uHGJarEF/ipp8IRqnbLKEbV rzoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FKfVs9nPlzx3JHF8r+S3MgDvsyjgAmQQ35/kdN+hBwo=; b=XdimuF3YTXC/r3kmx8TzjNx77QJrR+ekhCMJFtr1NhTT8MGtOHsxLSMxRAy15/SdIU Bhkto74ZN2rNIvt/YU0LvScE+MgKUwccJmXeKWBcIUANk2+lw9MDQ+bJv8cTQKcdBEkf Jpe82XhdKt6CXEfZOPm121XJqI65ZAbeiuxWCdtJHOxq7uGycBbmZOnqZ4lmrE25KSlR oKj1gA1NkpOSHv7J0t6UDBkGHywr3NW4ap4XR4sBbiQqJRj4jxGYuqI18iDXlWlGgA+z 30CMh2Jf211G9EtbSnPZDE9d4vsyI7YqSWFclBsaU/EjsOzvj75o6adMyRAGsUYhicZu I2ow==
X-Gm-Message-State: AA+aEWbc+2xOZ4mznJfWGZ30pBLxx4tWuctOfe2rmS1xxG2G0EqRHaMp P5ui24VHcYyjp+Xcf+7bRlbIkRGUL1pHpyxlCg421BbJmZw=
X-Google-Smtp-Source: AFSGD/U7MqxiVIU7mDndt1X6BkPfT9AUy60WunXEoWNxrfbRek0GbaNQwrC6NZ/56bAD/34Z462Nz+1iTuo58cOOViE=
X-Received: by 2002:a37:e406:: with SMTP id y6mr30505541qkf.216.1543339814977; Tue, 27 Nov 2018 09:30:14 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com> <9DBE5370-BEA4-48CE-B9FB-356ED1CCC1E7@icann.org> <CAPt1N1m1NoJoBPWJ5L96WwjrF6QEzB93pRxZpaHJxoBMpxtVRw@mail.gmail.com> <B4F27495-AA1E-44B3-B0DE-C228E0EDC84C@icann.org> <B00FCC13-587A-4E33-8BC9-D708EB6B4399@nohats.ca> <033DE6CA-B75E-4B06-A39E-323DCBBBC7A5@fugue.com> <alpine.DEB.2.20.1811271453020.3596@grey.csi.cam.ac.uk> <CAPt1N1kk37y4jA_808HbLbR3ecU82-5L41xQbL3xkbP3BAPOiw@mail.gmail.com> <alpine.DEB.2.20.1811271516370.3596@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1811271516370.3596@grey.csi.cam.ac.uk>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 27 Nov 2018 12:29:38 -0500
Message-ID: <CAPt1N1kOHGE5BC9o7imf1fPL9-YwWqJp4cptmkkdzzrTKsHRCQ@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: dnsop WG <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="000000000000709f04057ba8cd02"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I>
Subject: Re: [DNSOP] [Ext] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 17:30:19 -0000

Yes, absolutely, although I think there are use cases that can be addressed
without special configuration on the laptop, so the document should
definitely explain how to set that up, or point to a document that does.

I'm assuming that the reason for including the TA option in the IKE
exchange is that it avoids having to keep something on the host up to date
if the trust anchor changes (maybe this was explicitly stated in the
document, but I didn't see it).   From that perspective, this makes sense
in the one use case that I think is valid for installing a trust anchor.
That case is when the VPN operator is using a bogus internal domain for
which they don't control the delegation.   In this use case, it makes sense
to have a whitelist for that bogus domain.   But the whitelist should be
validated by making sure that the bogus domain is the right sort of bogus
domain: a top-level domain for which there is a secure denial of existence
that is checked before the whitelist entry is installed, and that is
checked periodically after the whitelist has been installed.

Of course, arguably the owner of the device should be able to override even
this restriction, but I think that should be the default behavior, and
overriding the restriction should require the sort of managed machine
configuration you're talking about: it should be Really Hard and involve a
special arrangement, not something the end user can do by following the
instructions provided by the person who is doing a social engineering
attack on them.

But my suspicion is that it's not actually necessary to provide for this
use case: the people who are doing this are not likely to care about DNSSEC
on the VPN.   We could as easily address this use case by simply allowing a
whitelist for secure denial of existence on TLDs, and this would address
the problem of non-DNSSEC lookups, over the VPN, on .corp, for example.
 The whitelist entry would simply say "look, I know you see a secure denial
of existence here, but it's okay to do non-DNSSEC lookups in subdomains of
this particular zone, and these should not be rejected on the basis of the
denial of existence."   Once again, this really only makes sense for TLDs,
as far as I know, since for example if the delegation is for example.com,
presumably the VPN operator owns example.com and can set up a chain of
trust there.

On Tue, Nov 27, 2018 at 10:38 AM Tony Finch <dot@dotat.at> wrote:

> Ted Lemon <mellon@fugue.com> wrote:
> >
> > Because of the experience with homenet, I actually sort of disagree with
> > you about needing a general solution for this.   I think that the general
> > solution for this is not to do it.
>
> :-)
>
> I was thinking more of "generally within the corporate context" - homenet
> is (as you say) much more of a challenge. Within the corporate context I
> think the general solution is to make this part of the managed machine
> configuration (along with X.509 trust anchors, etc.), i.e. don't specify
> the "internal" configuration details in-band, but just give the client
> some kind of name for a collection of configuration settings it should
> already have.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Southeast Biscay: Southerly or southwesterly 4 or 5, occasionally 6 in
> north.
> Moderate or rough becoming rough or very rough. Mainly fair. Good.
>