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

Paul Wouters <paul@nohats.ca> Thu, 29 November 2018 00:47 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C591310F3; Wed, 28 Nov 2018 16:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 pU86-8bYF7nT; Wed, 28 Nov 2018 16:47:28 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AD91310EF; Wed, 28 Nov 2018 16:47:28 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 434zPn2rD3zF2f; Thu, 29 Nov 2018 01:47:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543452445; bh=m79sf+paPZDmNK4w88pxvZIgGe9783UXitemLGGZsKk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Fo02kyCRRipaKL3/L77pvqyO78/h3DJu5roYby8E36ny1D3y/cU81VSSnVENkXuNB i+nnaz98q7JroyqhQicvNAISLDknQhpmLUahA/Ke6O4buRodnwxR+NTnWw/1dGNis2 rAmenKC/n3ann/HKdjwMZrngsHr4Bl5Guffy9n9I=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id TXeYXpJQ3AMR; Thu, 29 Nov 2018 01:47:22 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 29 Nov 2018 01:47:21 +0100 (CET)
Received: from [IPv6:2001:44c8:4480:2df4:3927:ab1:7e88:46fc] (unknown [182.232.216.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 5FC9C4A280C; Wed, 28 Nov 2018 19:47:19 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5FC9C4A280C
Content-Type: multipart/alternative; boundary="Apple-Mail-8FE9F882-B793-403C-9216-1FA0F35314AC"
Mime-Version: 1.0 (1.0)
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (16A405)
In-Reply-To: <CAHw9_iJ0XFzErwbUci_WmN1pzZHbapj2JNu4j2YbMFbBt-m+aw@mail.gmail.com>
Date: Thu, 29 Nov 2018 07:47:15 +0700
Cc: Tero Kivinen <kivinen@iki.fi>, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, draft-ietf-ipsecme-split-dns.all@ietf.org, Joe Abley <jabley@hopcount.ca>
Content-Transfer-Encoding: 7bit
Message-Id: <7DE4235C-A00F-493A-A5A0-96FCF9C32621@nohats.ca>
References: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com> <46B41554-ABC0-4939-99E3-703E1FD998D5@hopcount.ca> <alpine.DEB.2.20.1811261658250.3596@grey.csi.cam.ac.uk> <23550.37961.117514.513410@fireball.acr.fi> <CAHw9_iJ0XFzErwbUci_WmN1pzZHbapj2JNu4j2YbMFbBt-m+aw@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OqB9ePNeFv3uEmAykipFa8KwGVI>
Subject: Re: [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: Thu, 29 Nov 2018 00:47:35 -0000

On Nov 29, 2018, at 04:53, Warren Kumari <warren@kumari.net> wrote:
> 
> 
> helps mitigate this -- as Tero says above, the user would have to jump through many stupid hoops in order to make themselves vulnerable.

That’s what we came up with when we talked to ekr.

> If think that if the text around "that can be updated out of band" were strengthened (the current wording sounds like being updated out of band is one option, but e.g being updated in-band and "approved" by the user is another), and it were made a bit clearer how the whitelist might be managed I'd be (grudgingly) willing to remove my DISCUSS.

I have no problem making that text stronger / clearer.

> Again, I don't love this, but I think that the mitigations can be made to work, and it *does* solve a real world problem.

Yes, if we want enterprises to deploy DNSSEC, we need this. The internal/external views are almost always administrated by a different party, so the likelihood of sharing private key is extremely unlikely (plus we would be telling them how to run their infrastructure). 

> Can anyone *not* live with this?
> W

I’m fine with the phrasing changes you are requesting.

Paul

> 
>> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen <kivinen@iki.fi> wrote:
>> Tony Finch writes:
>> > Joe Abley <jabley@hopcount.ca> wrote:
>> > >
>> > > It seems to me that the intended use-case is access to corporate-like
>> > > network environments where intranet.corporate-like.com might exist on
>> > > the inside but not on the outside.
>> > 
>> > More likely cases like corporate-like.local or corporate-like.int or
>> > like.corp etc. usw. :-(
>> 
>> Yes, this is the more common practice to use. I.e., several companies
>> quite often have (multiple) internal domains they use. Because those
>> are internal domains they cannot get real certificates for them.
>> Because they cannot use real certificates they use self signed
>> certificates, thus users have to click on "trust this web site having
>> invalid certificate yes/no". The idea is that with TLSA we could get
>> some kind of security for those internal sites.
>> 
>> More competent companies might also run their own CA and use that to
>> sign internal web sites, but unfortunately those more competent
>> companies usually then also have heavy IT processes that requires all
>> kind of complicated stuff to get things be signed by corporate CA, and
>> then developers setting up intranet / chat system / testing setup etc
>> revert to self signed certificates, because it is easy. On the other
>> hand getting DNS names added to the internal DNS is usually something
>> that happens often, and is not too hard to do, getting TLSA record
>> along with the name should also be quite easy.
>> 
>> Now when browsers start to make it harder and harder to allow access
>> to self signed certificates, users are seeing more and more problems
>> with that.
>> 
>> > Private DNSSEC trust anchors should be distributed in the same way
>> > that you would distribute corporate X.509 trust anchors.
>> 
>> This is exactly what is proposed by the draft, execpt that it is split
>> in two parts, i.e., the names for which TAs can be given are
>> distributed in same way as X.509 trust anchors, the actual contents
>> for the TA for that whitelisted name is distributed inside IKE.
>> 
>> The draft requires the whitelist to pre-configured before starting up
>> the VPN connection. It also do require implementations to ignore all
>> those settings unless user have explictly configured split-tunnel on
>> for that connection.
>> 
>> I.e., in the example the VPNs-R-Us would not be able to set those
>> configuration settings, nor would it be able to provide dialog asking
>> that.
>> 
>> VPN-R-Us would require provide instructions how to configure your VPN
>> client to do that, i.e., it would need to ask users to do following:
>> 
>>   - In your IPsec VPN configuration dialog click "Add" to add new VPN. 
>>   - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
>>   - Click advanced
>>   - In Advanced settings to go the enterprise VPN tab
>>   - In there click the Enable Split-tunnel setup check box.
>>   - Answer YES to question verifying that you really want to configure
>>     this manually, and do not want to use the managment profile
>>     provided by the enterprise (normally enterprise VPN setups are
>>     managed automatically by profiles provided by the company, normal
>>     users usually do not even have option to change anything).
>>   - After that click "Add items to DNSSEC whitelist".
>>   - Type in "farfetch.com", and click OK.
>>   - (vpn client would probably forbid him adding .com to list as or if
>>     it is added it would be ignored), so VPN-R-Us is smart and asks
>>     following:
>>   - Type in "paypal.com" and click OK.
>>   - Click OK to few times and get the VPN configuration setup.
>>   - Then fire up the VPN client.
>> 
>> More likely VPN-R-Us would say if you do not want to do that, just
>> download this easy binary exe that will do all that configuration for
>> you (and some others they do not mention).
>> 
>> I.e., that whitelist needs to be modified out of band. Usually it is
>> done by the management system taking care of the enterprise profiles,
>> i.e., the same program that installs X.509 roots for the company CA,
>> and mandates that virus checkers are up to date before allowing
>> connection to the corporate network, and which also configures the VPN
>> connection too.
>> 
>> If you are running that kind of programs you have already given all
>> control to whoever provided you that program (VPN-R-Us, or the
>> enterprise).
>> 
>> In enterprise case, you usually do not have option not to, as those
>> softwares come pre-installed and you cannot uninstall or not to use
>> them. On the other hand do not use your work laptop to go to paypal,
>> if you do not trust your company...
>> 
>> And yes, the enterprise (or VPN-R-Us) management.exe could also
>> install those TAs directly for the global system use without any
>> problems. This would not be problem for the VPN-R-Us (they would be
>> happy to have fake TA in your system even when you are not using their
>> VPN), but enterprise might not want to have its TA there when you are
>> not connected to its network, just to limit the exposure, and they
>> might want to update the TA contens, even when the whitelisted domain
>> name stays same.
>> 
>> I.e., if the TAs cannot be transmitted and agreed to be taken in use
>> (after comparing them to whitelist) inside the IKE, then enterprises
>> will most likely just install them by the management system for
>> general use (or not use DNSSEC). I think that would weaken security
>> more than what is proposed in this draft.
>> -- 
>> kivinen@iki.fi
> 
> 
> -- 
> 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
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop