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

Warren Kumari <warren@kumari.net> Mon, 26 November 2018 16:18 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7E4D8130F14 for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 08:18:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MbzLeI4ha6XK for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 08:18:30 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 04837130DCF for <dnsop@ietf.org>; Mon, 26 Nov 2018 08:18:30 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id k198so19198613wmd.3 for <dnsop@ietf.org>; Mon, 26 Nov 2018 08:18:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eDtb9+35w6F9O30Pub6FBay/75K0maRePTfE0YGYE80=; b=fUNZbZqlEs19IKP1Tv9nqj26KDLcZ6UF+U4RMvTt6Mv9hB0GGAQw6lwgrvQ2ykgNpW d3Sx9GBSBuU4mArluvM1dkb4zRd4I4uvJwnHcZCMhTio/aIi79nvW4sJS4BuGOv5GP/8 ahVioJEuX7fmaolzpyKWRtSrTFGddUaf9QmIfLDQ44TxwU37rXT01kKDnMIQBLXywxHh HBE+FQMMydA7azgcOxNDTbyo2qiev/vmUObnQo3Di64dJrGiRgBhxREUTdWbvmOgiLzi VaXJn4ujG94Vxk9V15bzX8QXk37iYZSyDcrkHhk+aUOj5ypTVZZ62PFKoxRh7yD7Ntnm QJhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eDtb9+35w6F9O30Pub6FBay/75K0maRePTfE0YGYE80=; b=qOP6T5Cy8Sdka6bHn1zf0sSwiRelzRdn9YrGytkj9J8Xj3MfmnzGqPURlH5QIsI8UI 4zUTabl+lKC80nxTQe+kDjtYJKxE23Zgdkf6QqgQ0BTVPjEpdZznSQW5kvY6Y29ly/pu sO/h1t004JHHxcWWy7AVA1FfAEJbJ/J/MpCYffBMCKn7svktX1auLJQnXhWOcBecoc2y a1ubi74Gb+GcXDZ+8MxY7nONyn6WWoDXUh3XcJssBvRdAiwlBnA4ylMXMnEUPgehrKY/ Fuvzd2VV0lcniU1fZG5/AeUO6/Ecic4MRtcp1T4FB1Xgpp9KwDPGvl672yi6DWF0GoS7 f6CA==
X-Gm-Message-State: AGRZ1gJKAJZb83uRs2NjgZ33I7B1rGE75lESPGcEQqXMgGdlXHQuy9KE JlQqX148mwxEBXROpMPEKld2gg67U1sccBEaSHgXwxEFxao1gg==
X-Google-Smtp-Source: AJdET5epnMzdl4+AUhG/T+vOKC0etZQp+53qQgr4ggiFmns1reMgRlBxAlgfYZwmJC+Fo3qMSABOFPnPvU1VI+bfGSQ=
X-Received: by 2002:a1c:ce0e:: with SMTP id e14mr25593406wmg.53.1543249107787; Mon, 26 Nov 2018 08:18:27 -0800 (PST)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Mon, 26 Nov 2018 11:17:50 -0500
Message-ID: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>, draft-ietf-ipsecme-split-dns.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000deb869057b93ae7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gokQcT6pcLvdN4Mc6_5XerpQ0PI>
Subject: [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:18:33 -0000

Hi there DNSOP,

I (and a number of IESG folken) would like some feedback / guidance on

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

My DNS request goes to VPNs-R-Us, who (because they have provided me with a
DNSSEC TA for .com) answers with 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

I'd really like your advice, preferably before Friday.

The document: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/
The balloting:

The thread on my DISCUSS:

[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