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

[Eric Rescorla <[e-mail]>]

For reference, here is my original review.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3046


The security considerations seem to omit a fairly serious potential
attack. Consider the case in which the client supplies this payload
and the server provides resolvers and DNSSEC anchors for some domain
it does not actually control, such as www.example.com. It then
provides a bogus IP address (of its own) and a TLSA(2)  or TLSA(3)
record asserting its own key pair. In this case, if the client
supports DANE, then you have at least potentially circumvented the
PKI. This is far more serious than a bogus IP.  The most likely
defense against this is for the client to filter the domains for which
it accepts anchor overrides. However, even if you do that, this still
introduces a weakness: if you are using straight DNSSEC, then signing
can be offline, but because the TA is not signed by an offline key,
compromise of the VPN endpoint means that you can forge DNSSEC
records.




COMMENTS
>
>   2.  Background
>
>      Split DNS is a common configuration for enterprise VPN deployments,
>      in which only one or a few private DNS domains are accessible and
>      resolvable via an IPsec based VPN connection.

I see the "only" binding to one, but isn't also generally the case
that they are only accessible via the VPN connection.


>      o  Digest Type (0 or 1 octet) - DS algorithm value from the IANA
>         Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
>         Registry.
>
>      o  Digest Data (0 or more octets) - The DNSKEY digest as specified in
>         [RFC4034] Section 5.1 in presentation format.

I'm having a little trouble reading this. Is the reason these would be
0 because you are using the empty format?


>      o  Digest Data (0 or more octets) - The DNSKEY digest as specified in
>         [RFC4034] Section 5.1 in presentation format.
>
>   5.  Split DNS Usage Guidelines
>
>      If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,

The rules in this section are kind of hard to follow. I'm not sure
what the best way to restructure them are, but perhaps:  (1) If the
domain list is empty, you can use the internal servers for anything
(2) If the list is non-empty, you MUST use the internal servers for
any entries not prohibited by local policy, including total limits ,
and should accept 1918 addresses fore those domains and SHOULD NOT use
the internal servers for anything else.    -


>      servers.
>
>      If the initiator host is configured to block DNS answers containing
>      IP addresses from special IP address ranges such as those of
>      [RFC1918], the initiator SHOULD allow the DNS domains listed in the
>      INTERNAL_DNS_DOMAIN attributes to contain those Special IP addresses.

I would rewrite this with the SHOULD first,, i..e, "SHOULD allow, even
if" because you want this SHOULD to apply even if you aren't
configured this way.


>      no guarantee of being answered.  For example, if the
>      INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
>      "example.com", "www.example.com" and "mail.eng.example.com" MUST be
>      resolved using the internal DNS resolver(s), but "anotherexample.com"
>      and "ample.com" SHOULD NOT be resolved using the internal resolver
>      and SHOULD use the system's external DNS resolver(s).

This paragraph seems to to some extent duplicate the paragraph
starting with "For each INTERNAL_DNS_DOMAIN..."


On Tue, Jun 19, 2018 at 8:44 AM, Eric Rescorla <[e-mail]> wrote:

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