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

From: Terry Manderson <[email-masked]>
Date: Tue, 20 Nov 2018 19:59:50 -0800

Terry Manderson has entered the following ballot position for
draft-ietf-ipsecme-split-dns-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 00:41:31 -0500 (EST)

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