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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 21 November 2018 16:00 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 221061277CC; Wed, 21 Nov 2018 08:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Irqcq8A9xMmL; Wed, 21 Nov 2018 08:00:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD79130DBE; Wed, 21 Nov 2018 08:00:44 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A19CA20089; Wed, 21 Nov 2018 11:00:38 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 155FDB98; Wed, 21 Nov 2018 11:00:43 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1306FB93; Wed, 21 Nov 2018 11:00:43 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Warren Kumari <warren@kumari.net>
cc: The IESG <iesg@ietf.org>, ipsec@ietf.org
In-Reply-To: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com>
References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 21 Nov 2018 11:00:43 -0500
Message-ID: <25704.1542816043@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/iVfxC2L4JhsFnWrfBb0bK5shBUU>
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 16:00:51 -0000

Warren, I see your concern, but I don't think it's much of an in practice.

Warren Kumari <warren@kumari.net> wrote:
    > Lots of "regular" users use VPNs for access the Internet, either to bypass
    > censorship / content restrictions, or to improve their privacy. These are not

Sadly, very few regular users use IPsec/IKEv2 for this kind of access.
So, really, this comment applies to a vanishing few number of people.
(There are a few:  Openswan is run by at least one big one to provide
IPsec/IKEv2 access, but I note that they provide 5 other protocols as well).

In almost all cases the VPN provider is in control of the software that is
installed on the client system, so they can hijack paypal already.
Few support IPv6 or DNSSEC for the VPN either.  Some are effectively HTTPS
proxies only, so ALG gateways, with HTTPS certificate evaluation done by the
VPN provider.  This is not much of a new threat.


In the remote cases where a user uses IPsec/IKEv2, and configures it
themselves (perhaps from instructions), then they could easily omit the:
  trust-ikev2-internal-dns=true
configuration option.  In the case where they don't configure it themselves,
then DNSSEC would get hijacked at configuration time, does not matter what
the protocol does.

****
Where I think there may be issues is when one has a non-technical consultant
who has an Enterprise-VPN to *two* customers, that the two Enterprises could
arrange to do things to each other via the cross-site scripting via the
consultant.

I think the document does a good job of making it clear that there
are issues the client implementer needs to worry about.
****

But, this seems terribly unlikely since just getting two VPNs installed
(and compatible) and running at the same time is such deep VPN-fu, that it's
like only half the IPsec WG members that could ever make this work anyway.


    > "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?

If she managed to install the TrustVPN herself, then I think yes.
Otherwise, she is going to call whomever installed the thing (I guess you),
and ask them.

{I think walled-garden DNS (whether for Enterprise use or IPTV) is security
threatre myself.  IPv6 is here, use it, and stop building coconut networks.}

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-