[IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-split-dns-16: (with COMMENT)

Warren Kumari <warren@kumari.net> Tue, 04 December 2018 18:18 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F27130E9D; Tue, 4 Dec 2018 10:18:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Warren Kumari <warren@kumari.net>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire <david.waltermire@nist.gov>, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154394752013.4979.13588546042247755495.idtracker@ietfa.amsl.com>
Date: Tue, 04 Dec 2018 10:18:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/oLr4X2SPKSGWuH6Gn9AEISH9vgE>
Subject: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-split-dns-16: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 18:18:40 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-ipsecme-split-dns-16: 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:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS.
I still don't love this idea / solution, but after asking the DNSOP list for
review (https://www.ietf.org/mail-archive/web/dnsop/current/msg24835.html) and
getting feedback
(https://www.ietf.org/mail-archive/web/dnsop/current/msg24881.html) I've been
persuaded that the benefits (with the mitigations) outweigh the risks.

---- Original DISCUSS position ----
I hope I'm just missing something obvious here, but this seems like it may
cause a significant security issue.

Lots of "regular" users use VPNs for access the Internet, either to bypass
censorship / content restrictions, or to improve their privacy. These are not
"corporate" / "enterprise" VPNs, but rather public ones - and sometimes they
are run by people I wouldn't entirely trust.

What is to stop one of these VPN providers setting:
INTERNAL_DNS_DOMAIN(www.paypal.com)
INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)

or, better yet:
INTERNAL_DNS_DOMAIN(com)
INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)

and so being able to spoof DNSSEC for paypal.com / all of .com?
This is especially worrying if something like DANE is ever deployed...

The draft *does* says:
"Other generic or public domains, such as top-level domains, similarly SHOULD
NOT be whitelisted." - this doesn't really answer the above. 1: It is
increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2:
How do I programatically tell if www.foo.net is a "public domain"? What is a
public domain anyway? How is an implementer supposed to address this?

It also says:
"Any updates to this whitelist of domain names MUST happen via explicit human
interaction to prevent invisible installation of trust anchors." Is my auntie
really expected (or competent) to understand what "Your VPN provider, TrustVPN
wants to whitelist com. Do you want to allow this? [Y/N]" means?

I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit
works.

Also, some of the DNS behavior is handwavey - I think that the document really
should be reviewed by DNSOP, but will leave it to Eric to make that call.

--------------

This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
   passed to another (DNS) program for processing.  As with any network
   input, the content SHOULD be considered untrusted and handled
   accordingly." feels a bit handwavey. Are there currently any DNSSEC
   validating clients which can easily take a targeted TA for a specific domain
   / set of domains?

I’m also not quite sure how this interacts with delegations. E.g:

example.com   600 IN NS ns01.internal.example
And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local
recursive, does it need to send the query to ns01 though the VPN or not?