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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
