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

Ted Lemon <mellon@fugue.com> Mon, 26 November 2018 16:43 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 214C7130DD2 for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 08:43:35 -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=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 kcWo5YzUg4dM for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 08:43:32 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 1CD8412F295 for <dnsop@ietf.org>; Mon, 26 Nov 2018 08:43:32 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id y78so1904845qka.12 for <dnsop@ietf.org>; Mon, 26 Nov 2018 08:43:32 -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=DCHY1JWyhtIlN/IUYad2+ywZGIA5h5Fd5lP8rtedC1I=; b=nkRokw1a8OCUsldeOcfW2IHlxBXlfRcasVkzg+8xfXlx7Vz7ZD/A8CsDjd5Sudwzv0 3A7V5n9sEm882D0WE+5KPEk1OKEKZ0u1jcAxsljqTQZZPx8QSRT1PFAxB9LqrBxHfBaZ wtr2ZCoLLSzSdli+Lwz4t1bklPZ1pfi0s1aZuJyBWAz1pD3QQWyOPHU/JrTpdJppupit 6fK0LAy4qhAW/gSyHbZemh+Hf3zVosb6nt18kna+ePRGITbis7ORqFGBWNn/osi3kQZu d38faRkbGNdh0C0y09VWXqODNQIF1AFpt5c7oq1FQF4nRHVsnbf4AmWJqvl9xdPaSrZl Ve3Q==
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=DCHY1JWyhtIlN/IUYad2+ywZGIA5h5Fd5lP8rtedC1I=; b=uJmLwAJD/H9OHh0kxLKbx4P4vver416iBiwE2KNO2TB0kW9E/UKboHffc/rT9GN5yg x8oQBffS4g+EToxvkxZQkDexFAiNn+i7b5Xn45zP+XsPQ8VvH6DXRVkfxi8UxeHC7c7l fSH+uhctqRm0i5/9KRwva5HR8M89KIX+byv61CNygq32Ehz4azrqtmVgfEAQD6qSWaXw /tPnyrxnMplT8wg1mc/gg3GRmSuKCSGVK/8TsT9x70lacMaMCjFGvM0ZEf0yKHO7gtTM D2yGV4AAFuSpWIARAVHMYGpD0K6WilzGCFLT8xrnuJkv2tNv86HYu63n8lAiwvz/BzZM BfKQ==
X-Gm-Message-State: AA+aEWZnMFuaePinBv3gJ95xRqCg27smRZpxWMJOuWrMWzoVRYTEqvlw z81mKVzmrgF7vUprTJdweEZm7rPB+MqJ1KQ9dFaSq0jiZLo=
X-Google-Smtp-Source: AFSGD/VSFCR+Wz4o1n/V0MZR+kevvlf2Ax4j4LJJhMEIaxJsTBW5yV8VIBou38TQxDO2jy/OqDffrraKDbiJaALI6Jc=
X-Received: by 2002:a37:e406:: with SMTP id y6mr25652312qkf.216.1543250611081; Mon, 26 Nov 2018 08:43:31 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com>
In-Reply-To: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 26 Nov 2018 11:42:55 -0500
Message-ID: <CAPt1N1n+8n=nM6mfbtmz99MomzE53GD2JMNA810BbfQnqxiyCw@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: dnsop WG <dnsop@ietf.org>, draft-ietf-ipsecme-split-dns.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000793802057b94081c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UTJ2-vY-0C1uZRspfKZMUoiCIaY>
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: Mon, 26 Nov 2018 16:43:35 -0000

I think it's pretty clearly the case that the VPN provider should not be
automatically assumed to be trusted.   Most VPNs that people use nowadays
aren't trustworthy in that sense.   Also, I think that we should draw a
hard line in the sand that it's never okay to override DNS trust.   I can't
actually think of a use case where it makes sense to do this.   It's fine
to add trust when it can be validated that without adding that trust, no
trust would exist.   But it's never okay to override a valid trust
delegation.

IOW, the way to solve this problem is to have a valid chain of trust from
the root, not all of which can be seen by the end user without going
through the VPN.   Then if there's a censorship issue, you just fetch the
whole chain of trust over the VPN, and it validates.   If you want to
provide a trust anchor that is different than what's present in the public
delegation, the way to do this is to have an unsigned delegation, so that
the conflicting trust anchor increases trust, rather than changing it.

On Mon, Nov 26, 2018 at 11:18 AM Warren Kumari <warren@kumari.net>; wrote:

> Hi there DNSOP,
>
> I (and a number of IESG folken) would like some feedback / guidance on
> draft-ietf-ipsecme-split-dns.
>
> This document (which has gone through IESG eval, and on which I'm
> currently holding a DISCUSS) attempts to solve the problem of accessing
> internal domains when using a split-tunnel VPN.
>
> Here is the abstract:
>
> "This document defines two Configuration Payload Attribute Types
> (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key
> Exchange Protocol Version 2 (IKEv2).  These payloads add support for
> private (internal-only) DNS domains.  These domains are intended to
> be resolved using non-public DNS servers that are only reachable
> through the IPsec connection.  DNS resolution for other domains
> remains unchanged.  These Configuration Payloads only apply to split
> tunnel configurations."
>
> Okey dokey, this sounds reasonable, and solves a problem which probably
> shouldn't exist, but does.
>
> The concerning scenario for me (and where I'd like the WG to provide
> feedback if I'm being overly twitchy) is:
> "The INTERNAL_DNSSEC_TA attribute type is used to convey a DNSSEC
> trust anchor for such a domain.  This is required if the external
> view uses DNSSEC that would prove the internal view does not exist or
> would expect a different DNSSEC key on the different versions
> (internal and external) of the enterprise domain."
>
> Let's say I'm visiting Elbonia and really really want to watch "The Great
> British Baking Show" on Netflix. Elbonia blocks all baking shows[0], and so
> I figure I'll fire up my VPN, provided by "VPNs-R-Us - only $1.99 per
> month, don't torrent without it!".
> As you can guess from the name, VPNs-R-Us is sketchy, but, hey, they were
> cheap! (They make up the profit by being malicious).
>
> So, I fire up my IPSEC VPN client, and it pops up a box saying "VPNs-R-Us
> wants to provide you with DNS servers for [.com, farfetch.com ] and
> DNSSEC Trust Anchors for the same. Continue [Y/N]?". Being a users,
> desperate  to watch Paul Hollywood disapprove of someone's puff pastry, I
> click "Yes" (admit it, you would too!)..
> I then browse to www.paypal.com to see if I can buy a shirt just like
> Noel Fielding's.
>
> My DNS request goes to VPNs-R-Us, who (because they have provided me with
> a DNSSEC TA for .com) answers with 6.6.6.6 and a "validly" signed DNSSEC
> answer. They also "helpfully" provide me with a TLSA record, and when I
> connect provide me with a certificate with the DNSSEEC chain extension..
>
> The document attempt to mitigate issues like this with: "Other generic or
> public domains, such as top-level domains (TLDs), similarly MUST be ignored
> if these appear in a whitelist unless the entity actually is the operator
> of the TLD. To determine this, an implementation MAY interactively ask the
> user when a VPN profile is installed or activated to confirm this.
> Alternatively, it MAY provide a special override keyword in its
> provisioning configuration to ensure non-interactive agreement can be
> achieved only by the party provisioning the VPN client, who presumbly is a
> trusted entity by the end-user.", discussions in the Security
> Considerations, etc.
>
> I believe that the document is trying to solve a real world problem, but
> I'm concerned by the ability to push DNSSEC TAs, and rely on user's ability
> to make an informed decision (keeping in mind their behavior when presented
> with big red "Are you sure you want to accept this random TLS
> certificate?!" browser boxes).
>
> So, would y'all mind weighing in to help me decide what I do with my
> DISCUSS? Do the benefits outweigh the risks? Allowing this potentially
> allows for DNSSEC signing of things like internal TLDs / internal
> namespaces, increasing DNSSEC deployment. Am I being overly cautious here?
> Should users know better than to blindly click OK on things they don't
> understand?
>
> I'd really like your advice, preferably before Friday.
>
> The document:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/
> The balloting:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/
>
> The thread on my DISCUSS:
> https://mailarchive.ietf..org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc
> <https://mailarchive.ietf.org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc>
>
>
> W
> [0]: Lest their citizens start wondering why they don't also have cake.
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>