Re: [dispatch] Working Group Proposal: DNS Over HTTPS

"John Levine" <johnl@taugh.com> Thu, 10 August 2017 16:01 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073631323A1 for <dispatch@ietfa.amsl.com>; Thu, 10 Aug 2017 09:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txEbaD4HJGfL for <dispatch@ietfa.amsl.com>; Thu, 10 Aug 2017 09:00:58 -0700 (PDT)
Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B565313239E for <dispatch@ietf.org>; Thu, 10 Aug 2017 09:00:58 -0700 (PDT)
Received: (qmail 50029 invoked from network); 10 Aug 2017 16:00:57 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Aug 2017 16:00:57 -0000
Date: Thu, 10 Aug 2017 16:00:35 -0000
Message-ID: <20170810160035.9804.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: dispatch@ietf.org
Cc: paul.hoffman@icann.org
In-Reply-To: <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/oFJTIzG3AwPckEadEhWPwpCXoe4>
Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2017 16:01:00 -0000

In article <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org> you write:
>Working Group: DNS Over HTTPS (DOH)
>
>DNS queries sometimes experience problems with end-to-end connectivity at times and places where HTTPS flows freely. The use of HTTPS
>provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTP infrastructure and policy.
>
>The WG will standardize how HTTP clients can encode DNS queries and interpret DNS responses.
>
>The WG will use best-practice HTTP semantics.
>
>Specification of how the DNS data may used for new use cases, and the discovery of the DOH servers, are out of scope for the WG.
>
>The WG will begin its work based on draft-hoffman-dispatch-dns-over-https.
>
>The WG will deliver a document describing how to obtain and interpret DNS information using the HTTP protocol, with an IETF Last Call expected in December 2017.

In the discussions to date, the proposal has been to send wire format
queries encapsuated as an appropriate MIME type and get wire format
responses back, to be parsed by the https client.  The design is very
simple.

The main use case I see is that javascript running in browsers can
currently only do implicit A and AAAA queries by looking up URLs.  If
you want to do a SRV or NAPTR or URI lookup, you can't.  So with this
hack, the js application can now do those lookups.

There's also more exotic scenarios where you're trapped behind a
hostile firewall or maybe a captive portal or you want to do queries
that are harder to snoop, but I think that SRV/NAPTR/URI in js is
enough of a use case.

Someone asked what if the https server lies?  DNS caches have always
lied, that's nothing new.  If you don't trust it, you have DNSSEC.

Another suggestion was to turn the queries and responses into easier
to handle json, but that increases the complexity by orders of
magnitude, and would requires an update for every new rrtype or edns
flag.  (If someone wants to build a json proxy on top of this as an
experiment, sure, go ahead.)

As you might gather, I think this is a good idea, and should be
straightforward for us to handle.

R's,
John