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

Ted Lemon <mellon@fugue.com> Thu, 29 November 2018 11:55 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 A8DDC1292AD for <dnsop@ietfa.amsl.com>; Thu, 29 Nov 2018 03:55:34 -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 URkrXwuzwaOM for <dnsop@ietfa.amsl.com>; Thu, 29 Nov 2018 03:55:32 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 D0BFF127333 for <dnsop@ietf.org>; Thu, 29 Nov 2018 03:55:31 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id r14so1615824qtp.1 for <dnsop@ietf.org>; Thu, 29 Nov 2018 03:55:31 -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=DQwzcfFOrzan0tYLlmVkWRoKQxM6Nv76dzxExWiGFcM=; b=qywzE0lEa8hCrQ4hyA1G9vC4AydttFBWRAo8rAQUPUFKfjqVBDc8W7dp8mD8w1Bpw0 zfo/7tnzJEWvz+zg/rw5hSEG9mqp+308GQi3ooC6H3C2VNLvx/oOYhsFd2PVgisEavFU V6Wod0S+xgME7benkeI4rb6zGM4MT0LHLImwMG25NnAbHJojLvbwTNjglgx2hqF3tPS+ oC8335TlyNmKJ1PX18nVZu3/4Lyp9Kft9bgxV435c+o7SclmqUYSLktBS4opmSoG/lMv mvNA6jWnVjNMpYALktRX7ppuxAWKTcgFgi6TJ0IiIGl5FpoJSa7qRnl42e8N2ZILBHUU 994A==
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=DQwzcfFOrzan0tYLlmVkWRoKQxM6Nv76dzxExWiGFcM=; b=OXSn/KpwK/5wwAA1EFWd7FGnTAvOmMkr0hDwIPzuqvNNR2XwlaNNa3cPcnGwstklj1 q90luzFtDDwOVJbLj/z4GUh9OLu6mo21zvNX4AUG0IUiNJm4mMO3Xsx5Y0WKLT9UrqDU XUGC32RPkWyP7ozZnn72sf21360uLZ0PZFKCYVnDzf3oVpBibSVgqQPMK9I8oVD2LANZ rkgh934Mbpxernb3kxEzNbM4ECoOHXjK5eu0PpbbLa2IGIe6FoqbXTAj3xEuQiDlN+Qs w5TjUX+GsxtwLdrqj8LuC7mLmjuTIPIrwAFVsO6TIzKox5CnHI4sxqBYREVJ6zPJQcFZ ZH1g==
X-Gm-Message-State: AA+aEWZl6IHC8EKbjg1Y10B2JXuGenX4wWuVWbnfR485BwcRLE5PGcC8 3mlz8XRvF04+dBIkG3Ulxw914FACudcZ69+vsIRUyA==
X-Google-Smtp-Source: AFSGD/UsQ90RM4jSBam4PI8GjEHWdssA+Os47x1hxO2fSqUKMSNBSuUcvN/BvqmEoKYCnAGiDTQoh5z7JXu5IWnepvY=
X-Received: by 2002:ac8:24e7:: with SMTP id t36mr1012337qtt.43.1543492530837; Thu, 29 Nov 2018 03:55:30 -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>
In-Reply-To: <1FBDB971-A632-4E32-A6CF-D422BBF6F8D3@nohats.ca>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 29 Nov 2018 06:54:54 -0500
Message-ID: <CAPt1N1nK=QurJGdoKhJfg6BV6yUn9dtWZBZDfE+PGDmm2SAdvw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Warren Kumari <warren@kumari.net>, Tony Finch <dot@dotat.at>, dnsop WG <dnsop@ietf.org>, draft-ietf-ipsecme-split-dns.all@ietf.org, Joe Abley <jabley@hopcount.ca>, kivinen@iki.fi
Content-Type: multipart/alternative; boundary="00000000000003b330057bcc5c49"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lHJ0V2sCLkpntPMC99gQ7k_kP3I>
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: Thu, 29 Nov 2018 11:55:35 -0000

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


> What is unclear ? Do you have suggested improvement text?
>

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.


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


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