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

Ted Lemon <> Fri, 30 November 2018 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66591130DE2 for <>; Fri, 30 Nov 2018 08:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.358
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c7ngqxN3pKLF for <>; Fri, 30 Nov 2018 08:29:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FED5128D0C for <>; Fri, 30 Nov 2018 08:29:48 -0800 (PST)
Received: by with SMTP id p17so6532377qtl.5 for <>; Fri, 30 Nov 2018 08:29:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Fri, 30 Nov 2018 11:29:11 -0500
Message-ID: <>
To: Paul Wouters <>
Cc:, Tony Finch <>, dnsop WG <>, Tero Kivinen <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="000000000000babe41057be44ed3"
Archived-At: <>
Subject: Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:

> On Thu, 29 Nov 2018, Ted Lemon wrote:
> > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters <> wrote:
> >       How could the use case be more constrained without breaking
> functionality?
> >
> > I discussed this in detail in several previous posts, e.g.:
> >
> >
> 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 or
> > 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."
> >
> >