Re: [IPsec] draft-pauly-ipsecme-split-dns
Paul Wouters <paul@nohats.ca> Wed, 20 June 2018 19:55 UTC
Return-Path: <paul@nohats.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 9FBF2130DC2; Wed, 20 Jun 2018 12:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: 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 R3RWdqXeCoqy; Wed, 20 Jun 2018 12:55:09 -0700 (PDT)
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 BE6011294D0; Wed, 20 Jun 2018 12:55:08 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419wXp25J3zF3y; Wed, 20 Jun 2018 21:55:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529524506; bh=TIiVmvvK1LdzMk0qGU1vIucLndUjBW7W7WnupdI4QOI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NP/Nm+rSukJTCBPKLcgj/6VnIa3KuI06esCwkbC6ClpjEzZRQDcGjQ0NJ94bEpv7O yGNd/gwwnKka8/NoDxRYYJCeCKj3zZYms/DwCc9ISUZYB8Bvh3Ak30oAtEwt2OyEIK y7e0aWLevXL0WUPVzv2UpMjxyLmUB8cMraPdJBhw=
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 e6CQJYU3SjSM; Wed, 20 Jun 2018 21:55:04 +0200 (CEST)
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; Wed, 20 Jun 2018 21:55:03 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6D297B8AF; Wed, 20 Jun 2018 15:55:02 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6D297B8AF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6142A407821F; Wed, 20 Jun 2018 15:55:02 -0400 (EDT)
Date: Wed, 20 Jun 2018 15:55:02 -0400
From: Paul Wouters <paul@nohats.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: Eric Rescorla <ekr@rtfm.com>, "draft-ietf-ipsecme-split-dns.all@ietf.org" <draft-ietf-ipsecme-split-dns.all@ietf.org>, Tero Kivinen <kivinen@iki.fi>, IPsecME WG <ipsec@ietf.org>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, Nico Williams <nico@cryptonector.com>
In-Reply-To: <20180620193225.GL4946@kduck.kaduk.org>
Message-ID: <alpine.LRH.2.21.1806201534260.31124@bofh.nohats.ca>
References: <CABcZeBPh33RMWy=pWVSWPp9cDrzrRrVQXgw1BKPLy_W0_Wrdgg@mail.gmail.com> <20180619224651.GD4218@localhost> <CABcZeBObub+rYYURt9SSumYqqWGxDMqhOG64oA+979n=mduXMw@mail.gmail.com> <20180619230148.GE4218@localhost> <CABcZeBNmavpZvzNRZBdOTKQYZ=yW=y2poaoVtsOeESNyRrG15Q@mail.gmail.com> <alpine.LRH.2.21.1806200002340.18235@bofh.nohats.ca> <CABcZeBPbq9ga8oSQ09GLyonPgZLOpFAy9hDJYAagUFz7GSHEoQ@mail.gmail.com> <alpine.LRH.2.21.1806201010490.6077@bofh.nohats.ca> <CABcZeBO0FjTWhhqv4s9Jf=+Pb61iGx+n=u0DWjDyM7X=NDm6eg@mail.gmail.com> <alpine.LRH.2.21.1806201511530.31124@bofh.nohats.ca> <20180620193225.GL4946@kduck.kaduk.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/o8Xvk6E9SUJ0c_IWIdMyCx1jDlg>
Subject: Re: [IPsec] draft-pauly-ipsecme-split-dns
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.26
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, 20 Jun 2018 19:55:11 -0000
On Wed, 20 Jun 2018, Benjamin Kaduk wrote: > This seems like the main fear, yes, but perhaps not exclusively so. > It's kind of how users "always" click through certificate warnings in > browsers, or "alway" grant a mobile app all the requested permissions. > If, to expand unreasonably upon a previous example, connecting to the Red > Hat VPN wanted to take over redhat.com, openstack.com, rhbz.com, > rhmail.com, rh.zone, redhat.googleapps.com, rh.googleapps.com, > realham.googleapps.com, freeipa.com, freeipa.org, and centos.org, is it > reasonable to expect the user to look at the list and pick out > "realham.googleapps.com" as not belonging? Maybe they think it's a > codename for some Red Hat project, but maybe it's something totally > unrelated and reflects overreach by the VPN provider. If you are thinking of such a large list, then this information could be conveyed via the Enterprise VPN Profile that the user must install. Then you could either not allow any changes from that profile without updating, or you could decide as a client to present only new names to the user. This is all local policy between enterprise server and client. Just like the mandatory use of some algorithms can be (and are) set in those profiles. > It seems to border on unreasonable to have such a long list and expect user > knowledge. On the one hand, the VPN provider "ought to know" what domains > it's responsible for (and are on the internal view), but on the other hand > this is essentially a self-certification and does not inherently have any > level of trust. It would be great if there was some third party that could > provide some certification that the list of controlled domains is valid, or > at least not present in the public view Names might be present in the public view and private view. That is not a valid criteria. > and controlled by someone else If you solve the Public Suffix list problem, there are more people interested in how they can use that information :) Although again, draft-pwouters-powerbind comes close to offering that functionality. > (since there will presumably be cases when internal names are not expected > to be visible in the public view at all). I'm not coming up with a great > technical solution off the top of my head, though. "Something in the public > DNS" might work, if you can forgive the incredibly vague idea. That would mean publishing something about private domains in the public dns and worse publishing something in the parent zone about child zones, which would be next to impossible for second level domains. >> know how common this new behaviour would be and how reasonable it is >> for a client to understand what is happening. I cannot answer how common >> this would be other than stating in the past this wasn't possible at >> all. And that client understanding could be presented cleanly and I gave >> an example. > > I think it will be very common for users to "click through" without > actually looking at the list, with fairly high confidence. I expect (but > at a lower level of confidence) that it will also be common for enterprises > to have lists of more than three domains in the internal view. If you do not make this option available at all, then the only option for the enterprise VPN's are: - Conveying this information hardcoded in installation profiles without any user visibility or negotiation/rejection posibility - Demanding to just get all DNS traffic despite being a split-tunnel VPN, at the expense of the user's privacy when doing DNS lookups for things that are not supposed to go into the VPN tunnel. Possibly requiring the user disables DNSSEC completely. Note also that the harm that can be done with realham.googleapps.com is basically the same as with any typosquat domain name, like me getting rhel.googleapps.co or realham-googleapps.com. I think that is not the real issue here. The issue is missing facebook.com, twitter.com or gmail.com in a long list of domains. And those would have a much higher chance of being seen as inappropriate. If it helps we could limit the number of INTERNAL_DNS_DOMAIN payloads or INTERNAL_DNSSEC_TA payloads allowed to put an artificial cap on these lists. I personally don't think we should, but I wouldn't object to one either if it is not too low. The reality is that using an Enterprise VPN means letting the enterprise control part of your machine. If the enterprise is malicious or incompetent, than there is nothing you can do as enduser. If anything, allowing this draft gives the VPN client a better chance to compartmentalize what it gives the Enterprise VPN. It is simply not different from the mandatory enterpise CA and/or anti-virus you have to install. If you think that risk is too high, you should not use the enterprise hardware for anything not related to the enterprise, and BYOD for personal matters. To greatly reduce any abuse, the draft disallows any of these CFG payloads for those VPNs that are not split and take all traffic. If the VPN client is using its own validating resolver, the remote VPN cannot falsify any TLSA records. This covers the use case of all commercial VPN providers out there, some of which are pretty malicious. Paul
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Tero Kivinen
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Tero Kivinen
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Benjamin Kaduk
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Tommy Pauly
- Re: [IPsec] draft-pauly-ipsecme-split-dns Benjamin Kaduk