Re: [IPsec] draft-pauly-ipsecme-split-dns

Benjamin Kaduk <kaduk@mit.edu> Wed, 20 June 2018 19:32 UTC

Return-Path: <kaduk@mit.edu>
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 8511813111F; Wed, 20 Jun 2018 12:32:40 -0700 (PDT)
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 98rP7hrwb70Z; Wed, 20 Jun 2018 12:32:38 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 CC78D130F11; Wed, 20 Jun 2018 12:32:36 -0700 (PDT)
X-AuditID: 12074422-d23ff70000001a12-94-5b2aabd3f5ed
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B9.B2.06674.3DBAA2B5; Wed, 20 Jun 2018 15:32:35 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w5KJWYtx009202; Wed, 20 Jun 2018 15:32:34 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5KJWS6D025222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 15:32:31 -0400
Date: Wed, 20 Jun 2018 14:32:28 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Paul Wouters <paul@nohats.ca>
Cc: Eric Rescorla <ekr@rtfm.com>, IPsecME WG <ipsec@ietf.org>, Nico Williams <nico@cryptonector.com>, "draft-ietf-ipsecme-split-dns.all@ietf.org" <draft-ietf-ipsecme-split-dns.all@ietf.org>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, Tero Kivinen <kivinen@iki.fi>
Message-ID: <20180620193225.GL4946@kduck.kaduk.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.LRH.2.21.1806201511530.31124@bofh.nohats.ca>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsUixG6nont5tVa0wf8/lhYbe/6xWRztd7ZY 8focu8X+LS+AvPPP2SxOXTvCZvH+1iUmB3aPl6fOMXosWfKTyePw14UsHtdO/mX1+D6PyWPy 4zbmALYoLpuU1JzMstQifbsErozzS/8wFsySrtg+saqB8bVoFyMnh4SAicTTH2uYuxi5OIQE FjNJLDvxHMrZyCjx6GQDlHOVSeL0qg8sIC0sAqoSXXNXM4HYbAIqEg3dl5lBbBEBRYlJZx6x gDQwC+xiktg55TYbSEJYwEjizYofjCA2r4CxxMeuM2BxIYEbLBKnXjhDxAUlTs58AraAWUBH YufWO0A1HEC2tMTyfxwQYXmJ5q2zwXZxCjhKNM9aATZSVEBZYm/fIfYJjIKzkEyahWTSLIRJ s5BMWsDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyM4WlyUdjBO/Od1iFGA g1GJh/dGmFa0EGtiWXFl7iFGSQ4mJVFe/hqgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeNbOB crwpiZVVqUX5MClpDhYlcd7cRYzRQgLpiSWp2ampBalFMFkZDg4lCd7Zq4AaBYtS01Mr0jJz ShDSTBycIMN5gIaXgtTwFhck5hZnpkPkTzHqcnw4NLmHWYglLz8vVUqcNxGkSACkKKM0D24O KMlJZO+vecUoDvSWMO9CkCoeYIKEm/QKaAkT0JLqZrAlJYkIKakGxkZpOa5zwj1Mrudvx0vz cAtNPLxq1eG5B8ttlOS+aEyJad5w59eSBJeToQnfUl4JvWXc8lBgj47gsU0RhSm1r9+xHz3+ qseer8PhyOtzLfvYL3XmLFiR/EfWOX6HltVjyWWf5r3gVOLgOXUomG+L2ucgz/lHdhj9vHJG VU/h9rXv1ZaLkzXuKimxFGckGmoxFxUnAgC8yoL8TQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/CGXUpuL3vQua8fAjdbQ35iEB7SI>
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:32:41 -0000

On Wed, Jun 20, 2018 at 03:21:52PM -0400, Paul Wouters wrote:
> On Wed, 20 Jun 2018, Eric Rescorla wrote:
> 
> > I thought I had made clear what was bothering me, so I suppose we must be talking past each other. I read this text as saying that there are
> > important cases where in fact the client will not have any reasonable  way of knowing which domains to accept from the server, which, it seems
> > to me, contradicts the claim above that it's practical. You obviously think i'm wrong, so how should I be reading this text?
> 
> I understand what bothers you. You see browsers getting non-public TLSA
> answers and you are concerned about webpki bypass and enterprise
> meddling.
> 
> I see text restricting and notifying users of the domain names that will
> be part of the IKE configuration or negotiation allowing them to reject
> inappropriate domains.
> 
> You fear the user will just click yes. Then you somehow would like to

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.

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 and controlled by someone else
(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.

> 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.

-Benjamin

> To me, the only question is how to change the text so this is all clear
> to you, but you say you are still gathering facts and you are not ready
> yet to evaluate any proposed changes.
> 
> Maybe some other people can chime into this discussion and/or provide
> text to clarify things to you better than I am able to.
> 
> Paul