On Tue, 19 Jun 2018, Eric Rescorla wrote:
1. In the current design, many clients (those whose enterprises have any
significant number of domains) are just going to have to accept
whatever domains the VPN server claims should be treated as internal, and to
accept the trust anchors the VPN server claims
I don't agree clients have to accept anything. Currently, my iphone will
prompt me with this when installing a VPN Profile:
The network traffic of your iPhone may be secured, filtered, or
monitored by a VPN server.
It's easy for it to extend this with:
The VPN profile is requesting to take control of the domain name(s)
"redhat.com"
Or if the VPN profile wouldn't constrain the DNS names, upon connecting
to the VPN it could warn the user and store the decision:
The VPN server is requesting to take control of the domain name(s)
"redhat.com", "centos.org", "openstack.com".
If it later wants to add "gmail.com", the phone could do the popup
again, and hopefully the user would say no to that.
In addition, the current CT requirements would block rogue attempts by
the VPN server to take over domains not under its control, as a rogue
enterprise certificate for "gmail.com "would not appear in any CT logs,
and the browser would not be aware whether or not this domain would be
a private or public view.
2. Because the current design also allows those trust anchors to sign TLSA
records, any TLS client which accepts those TLSA records is subject
to MITM by the VPN server
Again, this is the feature, not the bug. We want to use TLSA records in
the enterprise network.
3. Even if enterprise doesn't intend to run a MITM proxy, this means that any
compromise of the VPN server automatically makes it an MITM
proxy for the Internet as a whole, because the person who compromises it can
simply reconfigure it to advertise any domain of its choice as
internal, as well as the corresponding keys and TLSA records.
If the server constrained itself in the VPN profile given to the client,
it cannot modify this later on when there is a VPN server compromise.
If the profile did not constrain itself, a popup could ask the user once
the server requests to install trust anchors for new domains.
CT would further prevent a compromised server from making up
certificates for domains not under its control.
If you wanted, you could add some new EKU or HSTS or other TLS
mechanism marking a domain name as never appearing as an
internal zone.
What, if any, of the above do you disagree with?
The premise that enterprise deployments are a bug instead of a feature.
The premise that this auto-configuration issue is more important than
allowing DNSSEC to be used on internal-only domains and that it cannot
be contained with local client policy.
Compare this to the current webpki, where I don't even get notified by
the browser when it adds/removes a webpki CA that can say anything about
everything on the internet _at all_. It is fully blind trust and I don't
have an enterprise trust relationship with them. Or compare it with
openvpn, that allows the server to execute arbitraty commands on the
client.
There is no IETF protocol that allows for reconfiguration of trust
anchors. If there was, we could have used that here.
A VPN enterprise profile is a trust relationship. This draft tries
to limit the amount of trust the client needs to have while ensuring
that the DNS protocol still works as expected. That is why it does not
support "." or "send everything over the VPN" deployments. I am happy to
clarify text if that is not clear enough, but I think it is unreasonable
to start talking about DNS filters or modifying DNS protocol behaviour
other then the (re)configuration of specific mutually agreed DNS zones
and trust anchors.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
