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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> You almost certainly will need to install some local webpki trust anchor
> to make use of your internal TLS servers reachable via the IPsec VPN.
> 
> For example, to reach any of our internal redhat servers over HTTPS, I
> need to install a redhat internal CA into my system/browser. I believe
> this is extremely common (although I do hope it is less common to give
> these internal CA's the CN="Certificate Authority")

Reading this thread now, I have few comments.

1) The current practice (before this draft) for split-dns is as
   follows: Forward ALL traffic to SGW when VPN is up (includes all
   DNS, including traffic to 8.8.8.8 etc). Forbid sending any traffic
   out except through VPN.

   Mandate that clients will install Enterprise Root CA to the trust
   anchor list of the client (i.e., operating system global trust
   anchor list). The client will have that Enterprise Root CA
   configured always, i.e., regardless whether VPN is up or not. Those
   Enterprise Root CAs do not have name constrains (as they do not
   work) or anything else that will limit their use for creating
   certificates for any domain name in world (CT might help). I.e., to
   be able to access enterprise https protected sites you MUST install
   the Enterprise Root CA, and to do anything useful you need to do
   that.

   One reason they want to do this is to limit what client can send
   out, for example make sure it cannot send any email out directly
   but all emails must go through the enterprise SMTP server which
   will do virus checking, add stupid disclaimers to them. They also
   want to do virus and malvare verification on all web traffic, thus
   they will want to use that Enterprise Root CA for MitM of all web
   traffic, or they might mandate the use of proxy that does the
   checking. If you want to connect your bank etc, do not use your
   enterprise laptop for that...

2) With this protocol, we can have Split-dns setup where the server
   can say that my "internal.local" domain is served by 10.0.0.1 and
   which has TA of XXX. This will provide much better security, as now
   enterprise can get rid of the Enterprise Root CA which allows MitM
   of whole web, and instead they can provide local TA configured
   DNSSEC protected TLSA records for all internal services. I.e.,
   after this there would no longer be need to require installing of
   the Enterprise Root CA just to get internal services working.

   I.e., we want to use TLSA which is protected by local TA to protect
   the internal servers. This is why we do not want to filter TLSA
   records out.

   Enterprise might still want to use Enterprise Root CA to do the
   MitM for virus etc checking, but this is outside the scope of this
   protocol.

3) Usually enterprises try to configure their internal domains to only
   include very limited number of domains, as the more you have those,
   the more issues you will have with configation.

   Quite often they use something that does not exists at all outside
   the enterprise. I.e., names like .internal, .local, .enterprise,
   .company-name.

   Sometimes they use names that do exists in outside world, but which
   are not owned by them (yes, this can and will happen, most commonly
   when they start using some foo.bar domain, and then someone decides
   to register .bar top level domain).

   If they are smart they use some domain owned by them which do have
   external visible name servers, and use some subdomain there which
   might not exist outside, i.e. internal.example.com.

   The reason why they end up with multiple internal domains is
   because every acquisition, merge etc usually adds some new names,
   and it takes years to get rid of them all. I think in my last
   employer we had about 5-8 different internal domain names in total
   during last 20 years, but only 1-2 were in use in the end.

4) If the enterprises have very complicated network they will usually
   have management system (or MDM) that will automatically configure
   the clients for them. I.e., the device is fully configured by the
   management system, and they will automatically apply configuration
   changes when needed. I think most of those system do allow
   completely take the device in their control, i.e., most likely they
   can silently install the Enterprise Root CA there if they want, or
   push device updates which include any code they want...

   In those cases the security of the device is in the hands of the
   enterprise anyways, and users might not even have permissions to
   change anything on the devices.


So I think the feature that we can use TLSA records in the split-dns
is very important. I agree that it would be VERY BAD for the client to
just accept whatever domains server sends, and it SHOULD always verify
it against its local configuration.

As I said in complicated cases the configuration itself might come
from the management system, so client does not need to silently accept
what server says, it can always verify it against the list it has in
configuration. But as the list comes from the enterprise this does not
protect the client from the malicious enterprise, but it does protect
it against case where attacker manages to hack in to the SGW, but was
not able to gain access to the management system. It most likely will
not protect against case where the attacker hacks in to the management
system, as the SGW configuration might also come from there...
-- 
[e-mail]