Re: [IPsec] Terry Manderson's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

[Paul Wouters <[e-mail]>]

On Tue, 20 Nov 2018, Terry Manderson wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for the time and effort invested in this document. I'm also very
> interested to see the resolution to Warren's DISCUSS regarding
> ipsecme-split-dns being used as an easy tool to over-claim entire sections of
> the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client
> MUST be in the administrative control of the VPN provider (I'm not sure I read
> that in the draft) might be one way out, yet I wonder if this is a case of
> simply having to trust that the VPN provider does the right thing (as cold as
> that leaves me) regardless of the words in the document.

The defense mechanisms against that are (and I will clarify the text for
that):

1) If there is no split-tunnel, then split-DNS payloads MUST be ignored.
    (this covers the third party VPN providers, but note those services
     can also specify INTERNAL_IPV4_DNS to take all your queries. Of
     course, they can see /modify all your packets that have no
     cryptogrpahic protection beyond the IPsec layer)

2) Don't accept TLDs (and/or wellknown SLDs)
    This might be easy for com/net/org, but harder for facebook.com or
    gmail.com)

3) Any DNSSEC trust anchor overrides MUST come in via the provisioning
    proces and NOT via the IKE protocol.

It is step 2) that might require user interaction and is hard to do, but
I do not think it is a solvable problem, and note that split-tunnel
setups that require split-dns are typically enterprise deployments where
you must trust the enterprise. There is some question about 1) being
abused, eg offer 0.0.0.0/1 and 128.0.0.0/1 to trick the client into
believing it is on split-tunnel even though it is not, but we feel any
VPN actor being that malicious can do more evil things secretly after
decrypting your traffic anyway, such as a transparent proxy for port 53.
That is why we allow INTERNAL_DNS_DOMAIN without the provisioning step,
but do not allow INTERNAL_DNSSEC_TA without it being provisioned outside
of IKE.

Paul
Paul