Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Tero Kivinen <[e-mail]>]

Tony Finch writes:
> Joe Abley <[e-mail]> wrote:
> >
> > It seems to me that the intended use-case is access to corporate-like
> > network environments where intranet.corporate-like.com might exist on
> > the inside but not on the outside.
> 
> More likely cases like corporate-like.local or corporate-like.int or
> like.corp etc. usw. :-(

Yes, this is the more common practice to use. I.e., several companies
quite often have (multiple) internal domains they use. Because those
are internal domains they cannot get real certificates for them.
Because they cannot use real certificates they use self signed
certificates, thus users have to click on "trust this web site having
invalid certificate yes/no". The idea is that with TLSA we could get
some kind of security for those internal sites.

More competent companies might also run their own CA and use that to
sign internal web sites, but unfortunately those more competent
companies usually then also have heavy IT processes that requires all
kind of complicated stuff to get things be signed by corporate CA, and
then developers setting up intranet / chat system / testing setup etc
revert to self signed certificates, because it is easy. On the other
hand getting DNS names added to the internal DNS is usually something
that happens often, and is not too hard to do, getting TLSA record
along with the name should also be quite easy.

Now when browsers start to make it harder and harder to allow access
to self signed certificates, users are seeing more and more problems
with that.

> Private DNSSEC trust anchors should be distributed in the same way
> that you would distribute corporate X.509 trust anchors.

This is exactly what is proposed by the draft, execpt that it is split
in two parts, i.e., the names for which TAs can be given are
distributed in same way as X.509 trust anchors, the actual contents
for the TA for that whitelisted name is distributed inside IKE.

The draft requires the whitelist to pre-configured before starting up
the VPN connection. It also do require implementations to ignore all
those settings unless user have explictly configured split-tunnel on
for that connection.

I.e., in the example the VPNs-R-Us would not be able to set those
configuration settings, nor would it be able to provide dialog asking
that.

VPN-R-Us would require provide instructions how to configure your VPN
client to do that, i.e., it would need to ask users to do following:

  - In your IPsec VPN configuration dialog click "Add" to add new VPN. 
  - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
  - Click advanced
  - In Advanced settings to go the enterprise VPN tab
  - In there click the Enable Split-tunnel setup check box.
  - Answer YES to question verifying that you really want to configure
    this manually, and do not want to use the managment profile
    provided by the enterprise (normally enterprise VPN setups are
    managed automatically by profiles provided by the company, normal
    users usually do not even have option to change anything).
  - After that click "Add items to DNSSEC whitelist".
  - Type in "farfetch.com", and click OK.
  - (vpn client would probably forbid him adding .com to list as or if
    it is added it would be ignored), so VPN-R-Us is smart and asks
    following:
  - Type in "paypal.com" and click OK.
  - Click OK to few times and get the VPN configuration setup.
  - Then fire up the VPN client.

More likely VPN-R-Us would say if you do not want to do that, just
download this easy binary exe that will do all that configuration for
you (and some others they do not mention).

I.e., that whitelist needs to be modified out of band. Usually it is
done by the management system taking care of the enterprise profiles,
i.e., the same program that installs X.509 roots for the company CA,
and mandates that virus checkers are up to date before allowing
connection to the corporate network, and which also configures the VPN
connection too.

If you are running that kind of programs you have already given all
control to whoever provided you that program (VPN-R-Us, or the
enterprise).

In enterprise case, you usually do not have option not to, as those
softwares come pre-installed and you cannot uninstall or not to use
them. On the other hand do not use your work laptop to go to paypal,
if you do not trust your company...

And yes, the enterprise (or VPN-R-Us) management.exe could also
install those TAs directly for the global system use without any
problems. This would not be problem for the VPN-R-Us (they would be
happy to have fake TA in your system even when you are not using their
VPN), but enterprise might not want to have its TA there when you are
not connected to its network, just to limit the exposure, and they
might want to update the TA contens, even when the whitelisted domain
name stays same.

I.e., if the TAs cannot be transmitted and agreed to be taken in use
(after comparing them to whitelist) inside the IKE, then enterprises
will most likely just install them by the management system for
general use (or not use DNSSEC). I think that would weaken security
more than what is proposed in this draft.
-- 
[e-mail]