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

Ted Lemon <mellon@fugue.com> Fri, 30 November 2018 16:29 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 66591130DE2 for <dnsop@ietfa.amsl.com>; Fri, 30 Nov 2018 08:29:51 -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 c7ngqxN3pKLF for <dnsop@ietfa.amsl.com>; Fri, 30 Nov 2018 08:29:48 -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 0FED5128D0C for <dnsop@ietf.org>; Fri, 30 Nov 2018 08:29:48 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id p17so6532377qtl.5 for <dnsop@ietf.org>; Fri, 30 Nov 2018 08:29: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=BnUKVqqnEDH8BVs8kw2wRATgveNO8seUet4rO/zbT5E=; b=oAdi3K2ZwRhr9tH91LFqAQ7MJa2uwiytsHrYreFKVfrdiZgzpqNugJ7302JVippkiI SH36WN5dgc4k+qf94HL1RhJSxKlnO+M/oBc+3zKgMthLmdQg98zdV0ZMFcVLB81mqKAc q9dfax7D1tgfYQXQXM+Su2zGr3XKq6h5eMN/q3b0JF4NqifL3cDnOkQUapHTOwwuX88C uh1I6Sxhv4+lU3gIhgISq90Tpor/9EXeTlcgHTGx7BiYuBYSz0EqmVq+9LGlqhm8oWjV jcb3F5JZBhUYGT9p3ZUvBNGOh2NQEhSw1eqYG3Djk+H8P0vDLX/2Rvp7tWLNXfGmXbQO /6/w==
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=BnUKVqqnEDH8BVs8kw2wRATgveNO8seUet4rO/zbT5E=; b=VxwnyKUHO8XHSaEs3KSYi7j46VJWRL9gPlTznTLVBLATwkq5Xw9J7KcHrazxJWcKHb mpdIzth6QMjMSKZPcMDGx2FSJnGCKIQCYSYyebANAO5z4gyK0jVq7eIFk2Y82ThsJK5y 5WXDw1aR/f1nSeYefNgKSB0md30RJuuwAhwc+rcduk3ZBuOK222QX7VBvQ88uBuKKJ92 HAdZ9P2BPCVlST9HjeDOWPt+4SPTD5RRi9mSgBGqHGJqstKSPI01ZIwlV+wM1cqbbPEx K15J/VUZCnxXL+plSqnt9QAHVgOojSTAgQLXvZoqg7PXG9cTB+rfLCJGpuodOiApMS9/ PZ2A==
X-Gm-Message-State: AA+aEWb8U0ufzV/OvRNqBRD4oF0akcraa8iBugGWwiMujOPhdZJUJToF rki0T/VaaxhMVrk0NlpyoSgHnX99/vLlCxz9P7IoXwY8LIE=
X-Google-Smtp-Source: AFSGD/WG0UxxS9FScHj613VtCvlQXwStkR26UX8TlmaqD4Oz7TfWLyznlahGueJGGzFCzyGDoNc12q8yLi5ZDqow3H0=
X-Received: by 2002:ac8:7518:: with SMTP id u24mr6234706qtq.75.1543595387164; Fri, 30 Nov 2018 08:29: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:29:11 -0500
Message-ID: <CAPt1N1=Q=EKPGN0DMDLwHxRoSqRs76VUMufWMEexqVHAeA9Wwg@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="000000000000babe41057be44ed3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/C8yqZBfSq6paCGMLgsnz7I_6jn4>
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:29:51 -0000

Separately, on the topic of provisioning, the right answer here is to just
say that the whitelist is installed with the provisioning profile, and not
recommend a UI flow.   It's the recommendation for the UI flow that I'm
objecting to.   This is a bad security practice that is slowly falling into
disfavor.   I admit I'm ahead of the curve on this, but the writing is on
the wall, and again, I'm not asking for ponies here.   I agree that if you
are going to use the whitelist method, you need to install it somehow.   I
do not agree that you need to advise implementors to do something which,
while presently common, is actually a bad practice.

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."
> >
> >
>