Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)

Warren Kumari <> Wed, 21 November 2018 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DB28130DFD for <>; Wed, 21 Nov 2018 07:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 h1fEfRehUkBL for <>; Wed, 21 Nov 2018 07:00:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD93F124BF6 for <>; Wed, 21 Nov 2018 07:00:36 -0800 (PST)
Received: by with SMTP id u13-v6so6093778wmc.4 for <>; Wed, 21 Nov 2018 07:00:36 -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=fiUwC/xOHzh3MbGOCsk15lPOoH9rVLNdDthmsOFLR2g=; b=axl+NAIAALsi1Ulm2RdolkC7NDfRXglVIUJzlN2WGL4p1k+1n4xiclXsCy6smqieOV w3RhfA/daxpbpbJmhLTSQgskOd4HirzB75cPdp2Z7vyoEjP/yFMpwetYLsqQtXgnuMxN MckrHOehbTkTxyfH8f9wjBHXG+2T6E+TaX75pvy8eJ3mp2eDIZ5B11KcWKegBymMNKIT QhA32Hat40VsPYvDb8clNw3a/9GJ5ojsw1szW9rqlUDf4VV9fOVdx0AVmwNy9erl0yAu YaNo//kYcc7apqd+T9lnCUtCNmeN5ehxgiQecDNiY3UlWI93s1vaTRxvC7uinX2G6uz1 KcLQ==
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=fiUwC/xOHzh3MbGOCsk15lPOoH9rVLNdDthmsOFLR2g=; b=DHivU7+0i69Fh5uNdui4vuyUbhVH9YQ71K5TmwspAfSyAp9fw5AL6Vdd+d9+DYEGrl +idw+HOSh4UR8DIi759QtlyIXw9MQJW0BteYsoZOgSd81RLMZHBsxmB2WyJ5IxOMO2xt gsn1p0WvxkbyWSgY4Fw8JJh3VmxZKAGT5qlDv4SxBJ/5cSx4u6G1Kc1wEwm3+NKi61cQ kkni4gYx7MslLHIm1kARRFkajMVr4wwa5P7z/mukq2KgyadwMBXexOE5/x9fikddrvJg WnR/9GLk1Qbrm0rUvYlP+Njqc7Ha/POfcLUkvrojC8gjF4/GSSZssl+GX2LtBmZcnZDS m5Mw==
X-Gm-Message-State: AGRZ1gL8PavQhOVHo/yyUERome0RdN7aEMiJPg2EUpi1tGHzcrLFxkUW x69jTgJ0+U2hlk6MNewzxBIbTWO0aYhjw0OoWTSpuQ==
X-Google-Smtp-Source: AJdET5eZ5AalhNgkhR+n6E23PkzDMz/h7767FfWZRX9n7mM3b3P7v+R1twQP8dIZlMm5wdWst/vhfte66RWckI1E4JY=
X-Received: by 2002:a1c:c701:: with SMTP id x1-v6mr6340821wmf.116.1542812434810; Wed, 21 Nov 2018 07:00:34 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Wed, 21 Nov 2018 09:59:58 -0500
Message-ID: <>
To: Paul Wouters <>
Cc: The IESG <>,,,, "Waltermire, David A." <>
Content-Type: multipart/alternative; boundary="00000000000021dd39057b2e0365"
Archived-At: <>
Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Nov 2018 15:00:45 -0000

On Wed, Nov 21, 2018 at 12:22 AM Paul Wouters <>; wrote:

> On Tue, 20 Nov 2018, Warren Kumari wrote:
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > I hope I'm just missing something obvious here, but this seems like it
> may
> > cause a significant security issue.
> No, you missed something subtle that clearly needs to stand out more :)
> > What is to stop one of these VPN providers setting:
> > INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)
> >
> > or, better yet:
> This sentence:
>     When only a subset of traffic is routed into a private network using
>     an IPsec SA, these Configuration Payload options can be used to
>     define which private domains are intended to be resolved through the
>     IPsec connection without affecting the client's global DNS
>     resolution.
> I think we had more explicit text in earlier versions that didn't make
> the cut on future revisions. I will re-add proper text in Section 4 and
> the Security Section.
> > and so being able to spoof DNSSEC for / all of .com?
> > This is especially worrying if something like DANE is ever deployed...
> There is a whole section on that.
> Specifically:
>     IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
>     a whitelist of one or more domains that can be updated out of band.
>     IKE clients with an empty whitelist MUST NOT use any
>     INTERNAL_DNSSEC_TA attributes received over IKE.  Such clients MAY
>     interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
>     whitelisted domain as an indication that their local configuration
>     may need to be updated out of band.
> We basically said this is too dangerous to only authenticate via IKE. So
> now, you need to _also_ do a (remote) configuration update, which
> presumbly involves some Enterprise management system or humans.
> > The draft *does* says:
> > "Other generic or public domains, such as top-level domains, similarly
> > NOT be whitelisted." - this doesn't really answer the above. 1: It is
> > increasingly hard to know what is a "real" TLD (.internal? .bank?
> .home?) 2:
> > How do I programatically tell if is a "public domain"? What
> is a
> > public domain anyway? How is an implementer supposed to address this?
> What we tried to say was that any generic domain open for any registrant
> for registration should never be accepted. While if you are Red Hat,
> maybe te TLD .redhat would be okay. (brand TLD vs generic TLD). I agree
> that it is difficult to determine this. The idea of the whitelist is
> that VPN clients will show/confirm/enable the listed DNS domains, so
> that if Honest Paul's VPN service includes "", the enduser can
> freak out properly.
> > It also says:
> > "Any updates to this whitelist of domain names MUST happen via explicit
> human
> > interaction to prevent invisible installation of trust anchors." Is my
> auntie
> > really expected (or competent) to understand what "Your VPN provider,
> TrustVPN
> > wants to whitelist com. Do you want to allow this? [Y/N]" means?
> Split-DNS is meant for Enterprise use of actual domains.

If your auntie
> works for Foo Inc., hopefully she can either have Foo's sysadmin
> configure and install her VPN, or if the admin gives her some kind of
> profile, auntie will be okay seeing "Your VPN provider Foo Inc. wants to
> whitelist" and she would be familiar with using the
> domain from the office.

Yes, I get that the *intended* audience is Enterprises, and that usage
doesn't really scare me (most enterprise admins already have their fingers
sufficiently deep inside their employees machines that they can do
$whatever anyway).
My concerns is that this will also be used for the "Buy our VPN for secure
browsing of the torrentz - only $2.99 per month. Punch the monkey for a
discount!!!!!!!!!!" type people -- I trust my enterprise admins to not
DNSSEC / DANE poison me, but I don't necessarily trust (to pick  at random)
CyberGhostVPN -
(I know nothing about this org!)


> Note that our text basically meant to say the IKE software should
> probably never allow com/net/org/CCtld ever, but that would be difficult
> to hardcode because we _still_ haven't fixed the PublicSuffix issue :/
> > Also, some of the DNS behavior is handwavey - I think that the document
> really
> > should be reviewed by DNSOP, but will leave it to Eric to make that call.
> What is wavey?
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > This section: " The content of INTERNAL_DNS_DOMAIN and
> >   passed to another (DNS) program for processing.  As with any network
> >   input, the content SHOULD be considered untrusted and handled
> >   accordingly." feels a bit handwavey. Are there currently any DNSSEC
> >   validating clients which can easily take a targeted TA for a specific
> domain
> >   / set of domains?
> >
> > I’m also not quite sure how this interacts with delegations. E.g:
> >
> >   600 IN NS ns01.internal.example
> > And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a
> local
> > recursive, does it need to send the query to ns01 though the VPN or not?
> It should not think about "through the VPN or not". We had that text
> originally, but Tero pointed out a lot of Enterprise VPN's can come up
> on demand. So the initial IKE negotiation could be for, and
> include the DNS configuration for the internal auth servers on
> It needs to configure the DNS so a packet for 192.1.1:53
> triggers another IPsec tunnel to be setup.
> So to use an unbound example, you only need to drop in the internal DS
> record, and the "unbound-control forward ip1 ip2"
> configuration pointing to the internal auth servers for
> Paul

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