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 18:18 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 C1EAB130F13; Wed, 21 Nov 2018 10:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S4N3UcfRuJjl; Wed, 21 Nov 2018 10:18:39 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1CA130F17; Wed, 21 Nov 2018 10:18:38 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CAD8220089; Wed, 21 Nov 2018 13:18:31 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 3EE18BD3; Wed, 21 Nov 2018 13:18:36 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3CEDA18B; Wed, 21 Nov 2018 13:18:36 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Warren Kumari <warren@kumari.net>
cc: Paul Wouters <paul@nohats.ca>, ipsec@ietf.org, ipsecme-chairs@ietf.org, "Waltermire\, David A." <david.waltermire@nist.gov>, The IESG <iesg@ietf.org>, draft-ietf-ipsecme-split-dns@ietf.org
In-Reply-To: <CAHw9_iLv=f7Z0m6Fa_XfcPF26ia-NTSoaCqOJLN3E1Y1jYu=hg@mail.gmail.com>
References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <alpine.LRH.2.21.1811210006170.29140@bofh.nohats.ca> <CAHw9_iKyBpOa1ktYvDDvuHnN+nLN7GnP49PwdT6-FWqNzDrUgg@mail.gmail.com> <alpine.LRH.2.21.1811211012160.24767@bofh.nohats.ca> <CAHw9_i+j92j4-DZHrL21CNkUFdheOO6z5+wfsG8Lrq1WorwnCw@mail.gmail.com> <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> <CAHw9_iLv=f7Z0m6Fa_XfcPF26ia-NTSoaCqOJLN3E1Y1jYu=hg@mail.gmail.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 13:18:36 -0500
Message-ID: <30238.1542824316@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/gGIuVFMAs7yNp9m29snIshoVzMw>
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 18:18:51 -0000

{sorry to re-interate, and/or beat what might be a dead horse already}

Warren Kumari <warren@kumari.net>; wrote:
    > So, I'm still fairly uncomfortable - having a VPN provider able to
    > override my DNSSEC configuration worries me, especially if things like
    > TLSA / DNSSEC Chain Extension / similar are used.
    > I was starting to come to terms with this, as I'd assumed that the
    > common deployment scenario was "Install (as root / admin) this binary
    > package containing a VPN client.", in which case a malicious VPN
    > provider already has the ability to do, well, basically anything (and
    > doesn't need this method to be malicious), but if this isn't the
    > universal case, I'm concerned again...

It's more of the: "Install (as root / admin) this binary package containing
                  an *IKEv2* VPN client."
and this just does not apply to 90% of the non-Enterprise use cases, because
they aren't using IKEv2 anyway.

The places where you should have a concern are:
  1) iOS, Android phones,   Linux/MacOS desktops,   running the OS-provided
     IKEv2/IPsec client.
  2) installing an opaque (to the end user) configuration blob.
     - configuration blob enables DNSSEC and INTERNAL_DNS configuration support
  3) connecting to a non-Enterprise VPN supplier, or to an Enterprise that
     does not already own (p0wn) the device you are using (i.e. BYOD).

I omit windows desktop VPN (even if it's IPsec), because in practice there is
always a binary install of some kind, despite decades of trying to do otherwise.
(This in itself should make the IESG sad)

Note if (2) is not true, that is, the end user is loading .p12 files, and
setting up policies in some semi-manual fashion (IKEv2 lets us automate a
great deal of the policy), then the dialog ought to have some way for a
knowledgeable user to decline and/or whitelist the DNSSEC overrides.
A non-knowledgeable user is going to be loading a configuration blob.
Potentially, there might be validation on the contents of that, and whatever
DNSSEC whitelisting is going to occur.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [









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