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

Joe Abley <> Tue, 27 November 2018 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9120130EA0 for <>; Tue, 27 Nov 2018 07:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D4dme2ka1QGI for <>; Tue, 27 Nov 2018 07:28:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0DA5130E91 for <>; Tue, 27 Nov 2018 07:28:07 -0800 (PST)
Received: by with SMTP id g192-v6so9205895ybf.3 for <>; Tue, 27 Nov 2018 07:28:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=abUdyJFNlPCYJA2eAPnzKPHyTT+S9wtQNi/zRIiPao8=; b=oFLXnTA5xLxNCkkOVgClW1Khefvq56ObYcRe7MFFkjfvtwhkysspkkV6X5BC084TKX E9hu6kLL9p/N23NfINNlEi2s5zdN6rQDkzAyPWBKr9T9nudnQX6Mb9XPCh2g6Ni+I8+q oGdIVrWAGABnkLkui/j/WrmHvU+H7a4BWrM1Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=abUdyJFNlPCYJA2eAPnzKPHyTT+S9wtQNi/zRIiPao8=; b=DF923b+CBgjIqXRfxOdT24ckKzUKtv2heEbxNmp8ppSH0V59a9LZQFzubNVSolkbuo IuBwfI2f05Pr3zUlWr5grVMk3h/1P/nwbmyNAs8ByydNc1dzfKvy+lYdv8FBrhhCLV6Y i4UfsT8ipMEWMHW5FGpLk4F48+ZYOhTl1qSGYN+Qvj4uUyPKWA+BKMarOScQ7ymurM8M SkzaDl9h9Tno/UAXZGRDZ6/hm8obEDOQp+pq8+jg7iHEgu8grJyaK5OE69xSLlMykdLE K+YK2A2tBpd+lcWlZcQJyEo1ZhrM+Da+eieCFu04ky62fuEvGVmRRj8MbJPHcVx924hu LpJQ==
X-Gm-Message-State: AA+aEWaMcxLglSgCkOnJqzcf5/oXaf2hGBE3r2qXU+aLkAKdfseHMnp4 3oTUcf/SbPn74jq2wXaH5eWalw==
X-Google-Smtp-Source: AFSGD/U/wxoWOMdq4B46RGClWez9WChSls5CH4t8uFr2Z1dOJjc4tWeL4ptpFbkZbzCa5xIzCP6A6w==
X-Received: by 2002:a25:4746:: with SMTP id u67-v6mr30745961yba.156.1543332486801; Tue, 27 Nov 2018 07:28:06 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:3:d1f:ad17:49c6:784f? ([2607:f2c0:101:3:d1f:ad17:49c6:784f]) by with ESMTPSA id 131sm1078316ywn.88.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 07:28:06 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Joe Abley <>
In-Reply-To: <>
Date: Tue, 27 Nov 2018 10:28:04 -0500
Cc: Ted Lemon <>,, Paul Wouters <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Tony Finch <>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <>
Subject: Re: [DNSOP] [Ext] 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: Tue, 27 Nov 2018 15:28:17 -0000

On 27 Nov 2018, at 10:02, Tony Finch <> wrote:

> Really, I don't think this is (just) a VPN issue: the question of how to
> install DNSSEC trust anchors for private zones has not been solved for the
> general case, so a VPN-only patch seems premature and unhelpfully specific
> to me.

That is a more concise and straightforward rendering of the main point I was blathering about the other day.

To your point, Paul, I did see the text in the applicability and security considerations sections about ignoring the INTERNAL_DNSSEC_TA payloads in the case of non-split-tunnel situations. I understand the restriction to use in split tunnel scenarios, and the requirement to implement a whitelist, but I don't think either of those are particularly strong (and the consequences of ignoring or subverting them are more serious than I think the document gives credit for).

For the split tunnel restriction, my pedantic objection is that all VPNs whose payload and scaffolding uses a single protocol (e.g. an IPv4 tunnel endpoint to build a tunnel through which to send IPv4) is a split tunnel, since the tunnel endpoint needs necessarily not to be encapsulated by the VPN client. Local networks are also frequently excluded in non-split configurations, too. Where is the strict definition of "split tunnel"? This is a real question; you know more about tunnel semantics than I do.

My arguably more reasonable observation is that any non-enterprise, Netflix-gaming VPN service that wanted to be a bad actor could simply provide a split tunnel service (according to the definition I was looking for) described as something different, but covering enough of the IPv4 address space that the end-user had no real way of noticing, at which point the INTERNAL_DNSSEC_TA payload could presumably be accepted by the client.

 The whitelist provisions in section 7 seem too weak to me to prevent this. It seems highly likely that someone is going to copy and paste a configuration that is overly broad; in addition, there's no text to confirm that the whitelist ought to be per-VPN-service and not global configuration for the client. There's a risk that a whitelist that makes sense for one VPN could be exploited by a different one that ought not to be able to say anything about it.

In a strictly enterprise scenario it's not uncommon for the client configuration to be handled by the IT department as part of normal IT asset management. If the IT department is configuring the VPN client, is it really a stretch to imagine that they couldn't install a local validator and trust anchors at the same time? That would solve the .CORP and RFC1918-reverse cases for those end-users without having to worry about nefarious use of these proposed new payloads for end-users whose clients essentially have no informed administrator. If you expect administrators to maintain an accurate whitelist, surely they could just configure TAs and forward zones themselves. If there's no centralised mechanism to update that kind of configuration in a friction-free way to accommodate TA rolls then presumably the devices concerned should all be considered compromised and banned from connecting to the network anyway.

One more thought; in a possible future where it's applications like browsers that do validation and not an OS-provided stub resolver library, this proposal leaves a gap between the VPN client (which might receive new trust anchor information) and those applications (which need signalling to know that such new trust anchor information exists). That seems worth mentioning, even if it's out of scope to provide a solution.

As is probably obvious I don't particularly like this proposal, but I also acknowledge that I'm perhaps not the target audience and I'm missing context that would make it seem more useful. If it goes ahead, maybe some of the observations here could help.