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

[Eric Rescorla <[e-mail]>]

I don't think that going point-by-point is getting us very far, so I'm
going to try to restate what i think the situation is, from the top.

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
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
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.

What, if any, of the above do you disagree with?

-Ekr


On Tue, Jun 19, 2018 at 9:40 AM, Paul Wouters <[e-mail]> wrote:

> 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
>