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

[Eric Rescorla <[e-mail]>]

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

> On Mon, 18 Jun 2018, Eric Rescorla wrote:
>
> Right but the problem is that accepting the TA for a given domain allows
>> the IPsec endpoint to act as a TLS endpoint for that domain
>> (assuming that the TLS client supports DANE).
>>
>
> Yes. You are the Enterprise customer. It's a feature.


Not all enterprises who use VPNs want to run a MITM proxy.

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.


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
- Make the use of TLSA signed by non-default trust anchors a separate
protocol option with those trust anchors defined separately.

I imagine there are other choices.



> Yes, but it's not clear to me that clients can adequately determine which
>> domains
>> are internal -- they just get that information with some VPN config they
>> got
>> from their VPN provider. The text in the document says as much:
>>
>
> Yes. And that is the same DNS problem in general when connecting to a
> network and running your own recursive server. You usually get only one
> domain via DHCP, but universities tend to have dozens, and they demand
> you give them all your DNS queries so they can screw with internal only
> domains for you on the fly. You just have to drop DNSSEC to let them do
> that. That is a situation that needs fixing, and at least if you connec
> to those networks using a VPN, this document is that fix. It allows the
> network to send more than one DNS domain, and let's the client decide
> whether or not to accept it. Where yes, most clients will do this based
> on trusting their administrator of the VPN they are connecting to. Others
> could have VPN software that lets them (de)select the ones they would
> not accept.
>

Trust isn't a monolithic thing. It's one thing to trust the administrator
to route
your packets and quite another to trust them to MITM TLS. Again, this is
why it's mostly safe to use HTTPS on networks owned by other people.


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.


> 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.
>>
>
> Not doing this makes the situation even worse. Do you have a proposal
> that would make it better? I cannot think of one.
>

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.


>
> 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, but generally,
no, I wouldn't expect things that were TLSA-authorized to be CTed.
If anything, I would expect them to use some sort of CT-for-DNS, but
of course that doesn't exist. And of course, with raw public keys
that's not even possible.


Paul
> ps. I'd really prefer this discussion to be in public on the list.
> Please do any replies to this to the ipsecme list. You have my
> permission to quote anything I wrote in this offlist mail thread.
>

Sure. We really need aliases that do the right thing here.

-Ekr