On Tue, 19 Jun 2018, Eric Rescorla wrote:
Yes. You are the Enterprise customer. It's a feature.
Not all enterprises who use VPNs want to run a MITM proxy.
So only specify INTERNAL_DNS_DOMAIN with "internal.example.com"
and all TA's outside that domain would not be accepted by the client.
The basic problem here is that the security properties of DNS are
radically different from those of the WebPKI (which is why we
routinely rely on HTTPS in cases where DNS is untrustworthy).
So, it's totally unexpected that allowing the VPN operator to
inject a new DNS trust anchor would allow them to attack HTTPS
connections. The problem with this design is that it ties those
properties together. This is a problem for the users but also for
the enterprise because it takes something which might have
been offline signed and makes it online.
Local policy gives clients the chance to only allow preconfigured
domain(s) to be accepted for redirection over the VPN, with or
without trust anchors. If the network operator is smart, they have
only one internal-only zone in use. And the client accepting that
trust anchor is not a problem. In the case of the network insisting
you need to accept dozens of trust anchors, then yes the network
administrator makes it hard or impossible for their users to engage
in anything other then blind trust of their enterprise devices.
(but to be fair, you are in that situation already when you take
that enterprise pre-installed laptop)
Client
implementations can limit these domains, eg using VPN profiles
that the user has to agree to. There is not much more we can do
at the protocol leven, than say the two things we already say:
1) If not split-view, do not accept any DNS trust anchors
This prevents third party VPN providers from injecting rogue trust
anchors. Note that in this case you already _are_ giving all your
traffic including DNS to the VPN server. (but hey, we have DOH)
2) Don't accept trust anchors for anything not specifically
split-redirected into the VPN infrastructure
So in my redhat case, I would either allow "redhat.com" or
"internal.redhat.com" to be redirected through my VPN profile
and not anything else. (well, actually some reverse zone parts too)
There are actually a number of oither things you could do:
- Totally forbid the use of TLSA signed by non-default trust anchors
The IKE/IPsec protocol should not modify the DNS protocol. The fact
that control of a certain (sub)domain is transfered via a private
view reachable via IPsec is a feature, not a bug. That would also break
the use of TLSA records in those private/internal views.
Practically speaking, in my setup, the unbound daemon cannot tell the
difference between trust anchors loaded via IKE/IPsec or via another
method.
- Make the use of TLSA signed by non-default trust anchors a separate
protocol option with those trust anchors defined separately.
That goes against the goal of the protocol. The goal _is_ to place a
certain (internal only) domain fully under control of the network of
the VPN server. Including all security features and trust anchors within
that zone.
I imagine there are other choices.
This protocol extension is explicitely to add or a move a subdomain in
the public DNS view to a private DNS view, after the user has given
permission for this. Any suggestions to do otherwise is undesired.
Trust isn't a monolithic thing.
Right, we are in fact carving out a little bit to move that trust
from the public DNS view to a private trusted actor.
It's one thing to trust the administrator to route
your packets and quite another to trust them to MITM TLS.
MITM TLS for those domains you have given them permission for.
Again, this is
why it's mostly safe to use HTTPS on networks owned by other people.
And it is _still_ save to use other people's domains unrelated to the
internal vpn zone(s) for HTTPS and no new trust anchors are added
that would compromise that security.
Also, look at it from the reverse perspective. The enterprise might like
the security of their highly valuable non-public servers/data to be higher
then trusting 500+ webpki entities and google/mozilla, patched up with CT.
They might want to rely on DANE/DNSSEC that's actually fully under only
their own organisations sole control, bys using that overriding local
trust anchor. Including for TLSA/HTTPS on their private servers. Why would
you want to prevent them from leveling that extra security?
Note that without this document, the only way for VPN clients to get
functional DNS beyond the 1 hardcoded domain, is to give the VPN all
your DNS queries, which allows even more manipulation (especially with
an installed Enterprise CA cert, now they can override gmail.com)
I'm not saying this document is bad. I'm saying it should exclude TLSA.
I'm saying that cannot happen without breaking to use of TLSA in
internal networks. Also, then the issue moves to IPSECKEY records
which have an even stronger case to be used with internal DNSSEC
based trust anchors.
How is a DNS server to know which TLSA records to ignore? And are
browsers going to clear their DNS cache when a VPN goes up or down?
Modifying the DNS protocol seems rather unrealistic.
So it seems to me that the likely consequence of this function is
that a lot of
clients will be accepting what amounts to MITM certificates (again,
assuming
that they support DANE) as part of their VPN config.
You could ask IKE client implementations what they plan to do for
INTERNAL_DNSSEC_TA. Our implementation will allow specifying a list
of domains for which you will allow redirection and trust anchors.
And I would set this to "redhat.com, 10.in-addr.arpa" to prevent
the corporate network from installing anything else on my machine.
Not doing this makes the situation even worse. Do you have a proposal
that would make it better? I cannot think of one.
Because in the current situation, the protocol does not allow to request
only DNS queries for one or some domains. You can only ask for none or
all DNS queries. That has a huge privacy impact. So only power users
like us can tweak things like adding a forward_zone to unbound to ensure
only the internal-domain DNS queries go the the server.
Why does it make the situation worse? Again, what's the use case why
it's needed to have the VPN install a new WebPKI trust anchor.
Because the public DNSSEC view proves the internal view does not exist,
so you need an override.
Because the private DNS wants to use DNSSEC too.
Also, part of your concerns could be mitigated by CT as well for the
TLS cases. I assume if browsers require CT, that internal-only domains
also need to get some kind of CT logging (redacted or not) and that
would also prevent a rogue gmail.com TLSA from being accidentally
accepted by the user at the IKE/VPN first as 'internal domain' and
then additionally at the TLS/TLSA layer?
Well, the semantics of CT+DANE are totally undefined
I was not talking about CT+DANE. I was talking about browsers mandating
CT and browsers not being aware that internal.redhat.com would need to
be treated differently. So even for those internal domains will need to
publish valid CT data (redacted or not) which would further reduce the
effects a malicious INTERNAL_DNSSEC_TA could do even if the client
accepted one for a domain not under enterprise control.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
