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

Ted Lemon <mellon@fugue.com> Tue, 27 November 2018 05:28 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 DDCEB130E6E for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 21:28:42 -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 HuDBgtok-pog for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 21:28:40 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 0FB55129533 for <dnsop@ietf.org>; Mon, 26 Nov 2018 21:28:39 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id l11so20509418qtp.0 for <dnsop@ietf.org>; Mon, 26 Nov 2018 21:28:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KVPNjg8aMMH23/bGs90Jeifg8rcGx8g9/fTBTlIKgcA=; b=kmVjnV3s83E5kX7avPy95uS8hVoLX7tOm9UWQ+qP2zZt0xabzKpR+yZ5JHQH+EIUZ9 YNpCwNlQeohb5SlTOQhG+ELN52GzDsd2QrpCUh/BqXtKJppVwilndXMlLYIW++9wbw+B EGgOn8hf3xlEbnTwV/RJQh6mdpVXSAJI0cgmq9GhbTgVMdtYlFY4Ey0sjFb1qmtMsLhH tqvwiUSTJ7McUFjd4q37YU6T9UIMFmMLVko6aJfr5jC+HG9XGZ/FIrA2B9vk5+qzfMqq s3jDid/kUrGFNyMpATUcvvKSygK2Bt+aYUU0P80mkW2fb63AI48J2PKEdkO7nvicwigv Hejg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KVPNjg8aMMH23/bGs90Jeifg8rcGx8g9/fTBTlIKgcA=; b=cwfMDzqUkrrO9hdkA20ftiSm3tR1DkIOAyMBrIO6+2UnTdZqglRZvrHZPSGxO6Dvue gBUKd7Bs2qS+7pf9oPgBKJoiAu96HdhkZ7NpHPp1DyOxNVTvG36Cx8ZDTjQtpk2yNKRq n3NBQHhtc5Sk1xN50a0BRHy84d/zBOzJcJCof1T0dPJ/ZZmjwI+UpKu/gbrBP3Netijp RbWXz1nD5fz35/KTcL30yxjdiPGPCiKpAZYd1vETWX7gHyB5IpCB5ez8opmUb176/8nT On6VnlFUnBRkIT1jB/P+8ZS8N807hyYoToLGdXu5w8B93cV+jaSrkP059rJhn8WGmNuC Xaag==
X-Gm-Message-State: AGRZ1gIRmkh3fyA8TJNUHrFWJrQLoSOO9OGckhEsckIPYMFXEjeGmxNv DNvlq9oHKK6uE//ihxtsaAd8XHiOX7Gy6g==
X-Google-Smtp-Source: AJdET5dHXEa1d4RulaXk/jbrDPv1VAn/wEcZaPzC3qSvzF1dS2cWDSt28LO9JpzJr55xchqjHTgPKw==
X-Received: by 2002:ac8:4258:: with SMTP id r24mr29899001qtm.213.1543296518810; Mon, 26 Nov 2018 21:28:38 -0800 (PST)
Received: from [10.0.100.12] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id j89sm2090616qkh.34.2018.11.26.21.28.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 21:28:38 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <033DE6CA-B75E-4B06-A39E-323DCBBBC7A5@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_74BF9564-4661-452C-BD0E-6E0457FD5EEE"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.42\))
Date: Tue, 27 Nov 2018 00:28:35 -0500
In-Reply-To: <B00FCC13-587A-4E33-8BC9-D708EB6B4399@nohats.ca>
Cc: dnsop@ietf.org
To: Paul Wouters <paul@nohats.ca>
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>
X-Mailer: Apple Mail (2.3445.100.42)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk>
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 05:28:43 -0000

On Nov 26, 2018, at 7:59 PM, Paul Wouters <paul@nohats.ca>; wrote:
> This discussion would be better if people took warren’s example and then read the draft before commenting.

I don't think that the answer changes much as a result of this, but it does change a little.  You've obviously put a lot of thought into how to put this particular square peg into a round hole.   It might be worth backing off a bit and looking at the use cases that I think you care about.   Here are six, roughly in order of how bad an idea they are, worst idea last:

Split DNS, no DNSSEC
Split DNS, DNSSEC, no trust anchor required because validation works on both sides of the split
Split DNS, DNSSEC, trust anchor required because the hidden zone provably doesn't exist
Split DNS, DNSSEC, trust anchor required because the hidden zone is under or at an unsigned delegation
Split DNS, DNSSEC, trust anchor required because the hidden zone has a secure delegation that won't validate
I want to attack you, and you want to let me

I am going to claim that case [1] is the use case that you really care about.   If you could just address case [1], you'd be nearly done.   Case [2] is a use case you care about if you are a DNSSEC fan.   Let me know if you need me to explain how to do it, but I assume you already know how.   Neither case [1] nor case [2] require the client to get trust anchors from the VPN provider.

A third vaguely plausible use case is that the service provider has a hidden domain that isn't correctly delegated, like .corp.   I think you can make an argument that this is a valid use case, and it does require that a trust anchor be installed.

The mitigation strategy for this would be to check to see that the existence of the zone is securely denied.   If so, and this is the case for example for .corp, then we can use the trust anchor without worrying that some legitimate public zone will be shadowed.   However, we still have the problem that two different versions of .corp could be configured at once.   Maybe not the scariest problem in the world, but okay, let's say this is a valid use case, and you can specify precisely how to allow it.   Probably check every time it's used to make sure its existence is still denied.   I think this use case makes sense for fake TLDs, and in no other case, so validating it is easy.

In cases four and five, you care enough to set up DNSSEC, but either can't be arsed to do it right, or don't have control over the delegation point and so can't do it right.   In the former case, I would argue that we should just say too bad.   In the latter case, we have just protected the end user from being attacked by saying too bad.

So I would argue that in both cases four and five, it should be impossible to install a trust anchor.   This is easy to do: when you are online, check to see if there's a secure path to an unsigned delegation above the zone.   If there is, then you can't use any trust anchor presented for that zone.   If you can't check, then you can't use the trust anchor either.

Secondly, check to see if there is a secure delegation.   If there is, you can't use the trust anchor.   If you can't check, you can't use the trust anchor.

I'm glossing over the fact that there are two steps to the process: installing the whitelist, and installing the trust anchor. I think it would be fine to do the checks when installing the whitelist, and then validate them every so often, maybe at least once a day.   There may be use cases where this prevents goodness from happening, but I think that we should let the field tell us before figuring out how to solve that problem.

One thing that the document says that absolutely must be taken out: there should be no way for a VPN to do something that presents me with a security dialog where I can decide whether not to allow it to whitelist a trust anchor. That's not a valid use case.   This is case six.

I think that the use case you want to address here is that an enterprise provisioning system needs to install a whitelist. This is not a user action.   The user should never be asked to do this, and should not even be able to do this unless they are smart enough to know that they need to do it and know how to do it without any prompting.   So the document should be quite explicit about that, and not recommend a UI flow that enables a social engineering attack.