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

[Benjamin Kaduk <[e-mail]>]

Sorry for the slow response; several things colluded to keep me
unavailable.  For bonus fun, mutt crashed trying to send this so I get to
try to reconstruct from scrollback history.  Hopefully nothing important
gets garbled along the way...

Do note that this is not really my area of expertise and is also not a WG
I'm responsible for, but I'm trying to help brainstorm a way past this
apparent impasse.

On Wed, Jun 20, 2018 at 03:55:02PM -0400, Paul Wouters wrote:
> 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.

Sure ... and local policy between the enterprise server and client could
also have the ability to actually show the list to the user.  (There's not
really a great reason for the enterprise to choose to do so, but if we're
hiding behind "local policy matter", we can keep our options open.)

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

It's not entirely clear that a true third party would be needed.  Perhaps a
cross-signed (by public and private keys) statement of joint ownership
could be visible in the private DNS, for example.  Yes, that's a logistical
hassle to arrange, but we're still in the "is the crypto possible" stage
for this question and can optimize eventually.

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

So, at some philosophical level, the public Internet is "more important"
for IETF standards than private Intranets.  Yes, it would be nice if our
Internet protocols can be used elsewhere, but in lots of places we use as
criteria "benefit the public Internet", "not harmful to the public
Internet", etc..  It may seem that in a case where there is conflict
between the public Internet and the private enterprise Intranet (e.g., when
the same name is controlled by a different entity in the two locations)
that we the IETF are obligated to prefer the public Internet.  I'm not
generally a huge fan of trying to use one IETF protocol as a forcing
function for some other change we want to see, but sometimes it happens,
and "if you want TLSA in the enterprise you can't have it for random
namesquats that mean something else in public" may be a valid case.

Does the public suffic list necessarily come into play?  If I walk up the
hierarchy looking for the same DNS key in both views, then force the first
level of divergence to have some authorization for the private view, would
that work?

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

Sure.  "Put it in the public DNS" is approximately the first easy thing
that came to mind.  What about my other proposal above?

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

See my previous note about "local policy", which has no technical reason to
prohibit user visibility.

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

Yes, this is bad.

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

That doesn't seem like a great plan to me, either, though I suppose I could
live with it if it ends up being the consensus proposal.

-Ben

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