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

Ted Lemon <mellon@fugue.com> Fri, 30 November 2018 16:25 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 8B857128D0C for <dnsop@ietfa.amsl.com>; Fri, 30 Nov 2018 08:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dTc_eaZSKZNp for <dnsop@ietfa.amsl.com>; Fri, 30 Nov 2018 08:25:48 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 670CB1271FF for <dnsop@ietf.org>; Fri, 30 Nov 2018 08:25:48 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id r14so6546963qtp.1 for <dnsop@ietf.org>; Fri, 30 Nov 2018 08:25:48 -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=oTJCCzzD9Rrd/XLM8mclioI54ri7OYRNZ3duGdAl1RA=; b=O3WQ5wkaUWE5cK95N6ai3IHk99VIhvE+LZJlioMjBLUmOFV7b46QHw584LxeUU3v8e oyVJvb338+E3aluv2+GKJkMCOOan7vOjEZwW9pxPc770ehaZ4Dk72xxidu+SWRyZFE10 tbHBrF7d06bT+ICbp7J2gKO1AaG6Z0Q877Ah2egCZWW/B2EuqVDuJZ7p1som46PowAIc O0egGD/O/IjWh08FRPWjc8iKYDbOZ6LySlFeRREDKNUY1vjcNXi9eaFfUN/Ep/IIMlHz gn3P8APoTbAUNBsW9dleTgeKGwqOgR2RVZaGJPGUjMzJJu7NVTKS93siv3j9qy+dj1OD 4OPw==
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=oTJCCzzD9Rrd/XLM8mclioI54ri7OYRNZ3duGdAl1RA=; b=HspkBTbIVU6poh5BE7gm0CGdfbRFsALbut3svX5aq21rQOmcN46w7kGtkbSktAGD9c Rjq+LrxlxbPTK+WfAkxqGfoeD+KBmLZhO7CQsult9WGlvrcvYyLmhA3RSYSXmSREsVde O/PlJq/25lEkL+yV9SrSh2N4hrjsIJKzYXTf3aFVvo3MUkADqU8SmqYehEMJo2E0UGvs T3UlvmL01JSR5hxCFSFvEIHxiujwJw8qPAuAdcAZZ8W2WA6lfFgq7KbEZUJ8F3nxKDKy r7Rj71l4boXCxFu8/3vkSs2zJPEXJKsybjhOl0B92WgrOByOgfi4NyuoweaZyOlbvVrc OwBg==
X-Gm-Message-State: AA+aEWaOEe62HoYmd9++qV2VzeddfPGA3K47yjultc2tlQ2rh1bKx77R 3mPIqOm5VRm+Vv4f3cgqCbrdhOWDedAMDP852S5z4w==
X-Google-Smtp-Source: AFSGD/UTBqvkiOzxF3b5pDOa8rjTsUCeEf5WzB4ihtwGAvxl75jpy3OdkbmcEY9it119DubYK5bYhqRnhm8Vwl8AH48=
X-Received: by 2002:a0c:981b:: with SMTP id c27mr6401055qvd.184.1543595147436; Fri, 30 Nov 2018 08:25:47 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com> <46B41554-ABC0-4939-99E3-703E1FD998D5@hopcount.ca> <alpine.DEB.2.20.1811261658250.3596@grey.csi.cam.ac.uk> <23550.37961.117514.513410@fireball.acr.fi> <CAHw9_iJ0XFzErwbUci_WmN1pzZHbapj2JNu4j2YbMFbBt-m+aw@mail.gmail.com> <CAPt1N1m2upV2yJsFVyac6n-_MzFsv_g_fMaYP_UueTFR_3OPCA@mail.gmail.com> <1FBDB971-A632-4E32-A6CF-D422BBF6F8D3@nohats.ca> <CAPt1N1nK=QurJGdoKhJfg6BV6yUn9dtWZBZDfE+PGDmm2SAdvw@mail.gmail.com> <alpine.LRH.2.21.1811301042420.22612@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1811301042420.22612@bofh.nohats.ca>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 30 Nov 2018 11:25:11 -0500
Message-ID: <CAPt1N1=4hEMPgS3nJxPwjhhwY=nNDZrq7+dH0M313YBGbfkn3A@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: draft-ietf-ipsecme-split-dns.all@ietf.org, Tony Finch <dot@dotat.at>, dnsop WG <dnsop@ietf.org>, Tero Kivinen <kivinen@iki.fi>, Joe Abley <jabley@hopcount.ca>
Content-Type: multipart/alternative; boundary="00000000000070d528057be44049"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zFzYKSv4qTkNUAVqlYgsoDHwyiU>
Subject: Re: [DNSOP] 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: Fri, 30 Nov 2018 16:25:52 -0000

Paul, I think it is a bit much to accuse me of wanting a pony here.

Suppose you have a company that has a subdomain that's internal (this is
the case where they control the delegation).   The way you make this work
is that you publish a signed delegation to the internal zone.   When you
look things up in that zone outside the firewall, you get NXDOMAIN for
everything but the SOA on the zone, which returns an old serial number.
 Inside the firewall, they get answers, which are signed, and which
validate.   There's no need for a special trust anchor here.

So that works if the zone being queried is just nonexistent outside the
firewall.   If the zone looks different outside the firewall than inside
the firewall, it's a bit more complicated, but essentially similar.   There
are two ways to approach this.   One is to assume that the validator never
checks the SOA on the zone.   This is almost certainly the case for nearly
any use case.   In that case, you just run the internal and external name
servers with the same ZSK, and have a delegation above it.   You don't
worry about zone serial numbers, because they don't affect validation.
 When you're inside the VPN, you get answers for the internal zone; when
you're outside the vpn, you get answers for the outside.   Both validate,
because the DS record(s) are referring to the same ZSK(s).

If you really care about SOAs being accurate, then you need to update the
zones in lockstep: the external zone will always have a different serial
number than the internal zone, and they will always differ by one, with the
internal zone being the larger number.   Whenever you make a change to
either zone, you increment the serial numbers on both zones.   Answers from
the internal zone will always have the higher serial number, and therefore
be preferred.

So in this case, there is no need for a special trust anchor, and using one
makes you substantially less secure, and hence is not something we should
be advising.


On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters <paul@nohats.ca>; wrote:

> On Thu, 29 Nov 2018, Ted Lemon wrote:
>
> > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters <paul@nohats.ca>; wrote:
> >       How could the use case be more constrained without breaking
> functionality?
> >
> > I discussed this in detail in several previous posts, e.g.:
>
> > https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk
> > https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I
>
> Well, you argued for changing things so much that it breaks
> functionality :) And you would require the VPN client to have
> some kind of DNSSEC resolving capability before the tunnel is
> setup. And if those checks need to be done during tunnel setup
> then there is also a significant delay that would affect on-demand
> tunnels.
>
> I especially disagree with your text:
>
>         I think that we should let the field tell us before figuring out
> how to solve that problem.
>
> > I explained this in the previous posts.   I would be happy (really!) to
> help improve the text, but it would be a significant change, and I'm
> getting the impression from
> > Warren that he would like to not do that..
>
> More specifically, the enterprise use case should not be further changed
> to a more manual problem. In our previous discussions, both with the list
> and the Security AD, we made it clear that this is as far as we can go
> without destroying the enterprise use case. That is, let the provisioning
> provide the list of names for override, give software a chance to warn,
> and treat it otherwise as trusted enterprise provisioning. It is up to
> the implementations on how or where they would support internal trust
> anchors. For example a phone OS could limit this via "enterprise managed"
> phone modes only and not allow "emailed profiles" to have these trust
> points.
>
> >> Have you ever installed a Configuration Profile on iOS device? If your
> profile contains a VPN profile which contains a PkCS12 it will warn (entity
> installing this
> >> can monitor all your traffic) and show you the root CA.
> >
> > Yes.   That's a very bad UI flow.   It means that I can just hand you a
> configuration profile to install, and you can install it easily.   And you
> will install it—you're
> > installing it because you want to get something, and when you're
> presented with "ok" or "cancel," it's going to be very clear to you that
> "ok" will get you whatever it
> > is that you want, and "cancel" will not get you what you want.   So even
> offering the user this choice has created a gigantic attack surface..   I
> think of UIs like this
> > as "social engineering enablement UIs."
>
> Well, this is where rubber meets the road. There is nothing I can come
> up with that will be rejected by the people who want to see dancing
> hamsters or playful kittens. An enterprise can hand out phones that
> are restricted with respect to provisioning and they can control it
> as they see fit. If such an enterprise wants to support BYOD, they
> can choose to forbid these trust anchors on those phones and/or
> limit those VPN connections in other ways.
>
> If you let random internet companies install profiles with various
> kinds of super powers, no RFC in the world will stop them.
>
> Paul
>
>
>
> >
> >       The idea of the text is that this can be similarly done and
> warning you about the domains whitelisted. That would help if it suddenly
> lists gmail.com or
> >       yahoo.com. I believe this adds value and is better than not
> presenting the whitelist. Ignorant users will just click click click
> regardless and knowledgeable
> >       users can go “wait a minute”
> >
> >
> > I assume that knowledgable users will do the right thing if given the
> right information; often these dialogs do not actually give the right
> information.   But it's the
> > ignorant users I actually care about, because there are probably three
> or four orders of magnitude more of them.   As a knowledgable user, UIs
> like this actually create
> > a lot of stress for me, because they never actually tell me what they're
> going to do, and yet I know that if they are doing something other than
> what I hope they are
> > doing, clicking "yes" will create a new attack surface on my device.
>  So I usually click "no," even though it's probably okay to click "yes."
>  If we want devices to be
> > more secure, we have to come up with UI flows that get the user what
> they need without forcing them to choose between "win and get hacked" and
> "lose and don't get
> > hacked."
> >
> >
>