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

Ted Lemon <mellon@fugue.com> Tue, 27 November 2018 15:12 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 127341293FB for <dnsop@ietfa.amsl.com>; Tue, 27 Nov 2018 07:12:56 -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 Ehso2nDJH1Jg for <dnsop@ietfa.amsl.com>; Tue, 27 Nov 2018 07:12:53 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 9ED5E1277C8 for <dnsop@ietf.org>; Tue, 27 Nov 2018 07:12:53 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id n32so22047721qte.11 for <dnsop@ietf.org>; Tue, 27 Nov 2018 07:12:53 -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=mVOjxgu12f9SqdPeIXcKL9LIS90C5i8Y2U3waF62k1o=; b=dL/N+EE6nLf26/pZK/HFfbYn/82apR+c5N/LHxEGhc68cMfutcJQwEJlWDY2zMVLfZ CXZkbFcyIlLMlJmsGseUCW8siKvYpMaNjzNQriFA9ewF2uGjbGIy0vrXlS7pC/7eXU3j AI4VedIVLSQB+kkMID8g9dwxJzu+VCWu5dm1q6dq/H4g0PMDcXTbX2npm2ma+lP/8+Yb NwuBSykBl7AiMzliuBIOwJzw7DDCwcDsLUYPN3FvFegaM606svkXogC1HQI65GgLzFxz f+zg0HB4/yARsoAdj9g1oExbqEaPBIhrX59JjMA1WzqvPgHbtF6NriqkhgPmlD30h8S5 WSgA==
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=mVOjxgu12f9SqdPeIXcKL9LIS90C5i8Y2U3waF62k1o=; b=Y6wIdN5xJZktX0n+d5nyajsLbyk/2bNOT1IKqZti2/4MEkTRFiGK9ML8C8IqLwNg5P gC/XoF1fKoNV6KOd1ZwRuNOqXBqCm5jU1XEbiyOsg7eLzZhi8p5IAP4NAjUwimgxKuwS ZA1HfJOZjUoihP04Sae5I/6H25zo4ZqqhVjp5pHleFbHZz4f2QXA7sXXUKCRF7a7jXaN fplT1Yfh2Wytv0SoYdMfKpcLBLfPRYwE6heRvSwPFjzVFXuB6e5wPcwAcrtP4thlFpER fWG65G3DKIuom06yF9K3iqALh4gUVb0ZwPJQF/nNz+4NeASaNvgeyJHHyeym7S0rnh8d 77sQ==
X-Gm-Message-State: AA+aEWZYqKlJMHdsss+oCMd7d8VtcvQ79SiiEvO8VAtsOcCL7RQoVJhw Kp8G29X8UeAB9OqQ8tEqieyzQalEYd9inMcdyysMmg==
X-Google-Smtp-Source: AFSGD/XaTCR3HfgXbXS51GSI8tnT1C4jiLp3FkSaT4lyDqkrik5Fqm1TI3zMHjw+btJJFidCzM1X7puAwqdoKS2xtE8=
X-Received: by 2002:a0c:c966:: with SMTP id v35mr31868182qvj.45.1543331572660; Tue, 27 Nov 2018 07:12:52 -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>
In-Reply-To: <alpine.DEB.2.20.1811271453020.3596@grey.csi.cam.ac.uk>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 27 Nov 2018 10:12:15 -0500
Message-ID: <CAPt1N1kk37y4jA_808HbLbR3ecU82-5L41xQbL3xkbP3BAPOiw@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: Paul Wouters <paul@nohats.ca>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000028e0cd057ba6e227"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LftlLkHPm3_SVJTJaNLsHWGtIxU>
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 15:12:56 -0000

An explicit exception could be made for "locally served zones," which would
include RFC1918 zones.   We've thought a lot about this problem in homenet;
the conclusion we ultimately drew is that it's way too hard to try to come
up with a ToFu solution that adds value, and anything that's not automatic
is useless.   So we concluded that if you want DNSSEC, the right way to do
it is to have a delegation from the root.   If you don't have the
wherewithal to do that, you don't get DNSSEC on the homenet.

We also considered the  case of DNSSEC for reverse mapping zones.   I don't
know if I can safely say "we" here because I just presented my conclusion
and nobody argued with it.   But my conclusion was that I couldn't think of
a threat model that justified the complexity of signing a locally-served
reverse mapping zone.   The reverse mapping zone is of very limited
utility.   People occasionally use it for authentication, but I think
there's a pretty clear lack of consensus in the IETF that this is a good
idea, since it gets shouted down every time anyone mentions it.   The other
use is for annotating logs.   That's just not something that's useful
enough that attacking it makes sense even if the attack is easy.   Any
complexity that is added to make the attack harder than it already is is
simply adding risk, not removing it.

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.   If there are some specific corner
cases where doing it makes sense, then yes, having a document that talks
about the problem and how to mitigate the risks makes sense, but the
mitigation strategy is most likely always going to be solution-specific
anyway, as it is here.

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

> Ted Lemon <mellon@fugue.com>; wrote:
> >
>
> Snipped and edited to add numbering for reference...
>
> > 4. Split DNS, DNSSEC, trust anchor required because the hidden zone is
> > under or at an unsigned delegation
> >
> > 5. Split DNS, DNSSEC, trust anchor required because the hidden zone has
> > a secure delegation that won't validate
>
> [ snip lots of stuff I agree with ]
>
> > 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.
>
> Case 4 is pretty common for RFC 1918 reverse DNS :-)
>
> Really, I don't think this is (just) a VPN issue: the question of how to
> install DNSSEC trust anchors for private zones has not been solved for the
> general case, so a VPN-only patch seems premature and unhelpfully specific
> to me.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
> an equitable and peaceful international order
>