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

Warren Kumari <warren@kumari.net> Wed, 21 November 2018 15:00 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB28130DFD for <ipsec@ietfa.amsl.com>; Wed, 21 Nov 2018 07:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 h1fEfRehUkBL for <ipsec@ietfa.amsl.com>; Wed, 21 Nov 2018 07:00:41 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 BD93F124BF6 for <ipsec@ietf.org>; Wed, 21 Nov 2018 07:00:36 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id u13-v6so6093778wmc.4 for <ipsec@ietf.org>; Wed, 21 Nov 2018 07:00:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; 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; d=1e100.net; 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: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <alpine.LRH.2.21.1811210006170.29140@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1811210006170.29140@bofh.nohats.ca>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 21 Nov 2018 09:59:58 -0500
Message-ID: <CAHw9_iKyBpOa1ktYvDDvuHnN+nLN7GnP49PwdT6-FWqNzDrUgg@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: The IESG <iesg@ietf.org>, ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." <david.waltermire@nist.gov>
Content-Type: multipart/alternative; boundary="00000000000021dd39057b2e0365"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/pai4cB777Wb8IJo-Buf0OFhVNoI>
Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 15:00:45 -0000

On Wed, Nov 21, 2018 at 12:22 AM Paul Wouters <paul@nohats.ca>; wrote:

> On Tue, 20 Nov 2018, Warren Kumari wrote:
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > 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_DNS_DOMAIN(www.paypal.com)
> > INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)
> >
> > or, better yet:
> > INTERNAL_DNS_DOMAIN(com)
>
> 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 paypal.com / all of .com?
> > This is especially worrying if something like DANE is ever deployed...
>
> There is a whole section on that.
>
> https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-14#section-5
>
> 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
> 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 www.foo.net 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 "gmail.com", 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 internal.foo.com" and she would be familiar with using the
> internal.foo.com 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 -
https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=1392&coupon=FlashSale2&aff_sub4=FlashSale2&
(I know nothing about this org!)

W



>
> 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?
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 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:
> >
> > example.com   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 10.1.2.3/32, and
> include the DNS configuration for the internal auth servers on
> 192.168.1.1. 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 example.com ip1 ip2"
> configuration pointing to the internal auth servers for example.com.
>
> 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
pants.
   ---maf