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

Paul Wouters <> Wed, 21 November 2018 05:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54E61130EDF; Tue, 20 Nov 2018 21:22:38 -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] 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 lj9w9ljwqef1; Tue, 20 Nov 2018 21:22:36 -0800 (PST)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F79F128C65; Tue, 20 Nov 2018 21:22:36 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4309ty2hgmzLDW; Wed, 21 Nov 2018 06:22:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1542777754; bh=u8wAA/DUOjh0z0yshTODNZcpeItzpdemOFaIl2P/seM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NRe3Dw5YR23YCC65UR80/+vbHU/TqYLePGF4PJkk6bGY2mMud4Yr5a/BdWFqzLLNH sEKwEv6sMa3kWYGAz9ZZTHR3KOjKND08jEvhtrHcPd1JQ4oxLzJVsIPeFMqLSVS+CI RJY6b5VLzDJi/n4TZDBIR0qL8DwuvjacQZ3QBH4M=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id J7SPxeqVB9Vl; Wed, 21 Nov 2018 06:22:32 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:22:31 +0100 (CET)
Received: by (Postfix, from userid 1000) id 90EC23797AD; Wed, 21 Nov 2018 00:22:30 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 90EC23797AD
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8172241C3B2E; Wed, 21 Nov 2018 00:22:30 -0500 (EST)
Date: Wed, 21 Nov 2018 00:22:30 -0500 (EST)
From: Paul Wouters <>
To: Warren Kumari <>
cc: The IESG <>,,,,
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
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 05:22:38 -0000

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

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.


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

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 INTERNAL_DNSSEC_TA may be
>   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