Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 03 May 2017 23:22 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC72A127876 for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 16:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 sw1S-eDtgxNt for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 16:22:09 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B961F124234 for <dns-privacy@ietf.org>; Wed, 3 May 2017 16:22:06 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 434A2F98C; Wed, 3 May 2017 19:22:06 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 0E20B20C10; Wed, 3 May 2017 19:12:04 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Roy T. Fielding" <fielding@gbiv.com>, Joe Touch <touch@ISI.EDU>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
In-Reply-To: <B0511F40-AA89-47C3-93F2-7A5121F842AA@gbiv.com>
References: <87tw51remp.fsf@fifthhorseman.net> <0a2e075d-59fc-1e0d-d745-31f5608a525c@isi.edu> <B0511F40-AA89-47C3-93F2-7A5121F842AA@gbiv.com>
Date: Wed, 03 May 2017 19:12:01 -0400
Message-ID: <87r305r0vy.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ACjkh7ERSW6PhIh3SKKAY6c7OGk>
Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 23:22:11 -0000

On Wed 2017-05-03 12:35:52 -0700, Roy T. Fielding wrote:
> I see no reason to suggest that spraying DNS on an HTTP connection would
> be interoperable.  HTTP/1.x has a tradition (good or bad) of allowing
> robust parsing of bad messages, which means no analysis of DNS uniqueness
> can guard against the potential variance of a thousand or so independent
> implementations of servers and intermediaries (there are at least four
> figures of independent server development in the craft-your-own-microserver
> category).

Perhaps the draft needs to be clear that this draft provides guidance
for servers that *want* to be able to distinguish a DNS-over-TLS stream
from an HTTP-over-TLS stream.  According to the published specs, a
server is within its rights to not treat invalid HTTP requests as valid
HTTP requests, right?

> In contrast, it is trivial to transform a DNS query into a GET request
> which can be handled by any current or future version of HTTP.
> All you need is the absolute URI, which is already defined, and a
> media type for the response payload.  That would just be using HTTP,
> so no need to call that an update either.

Agreed on this one, quoting from the draft:

    If being able to interleave DNS queries with HTTP requests on a
    single stream is desired, a strategy like
    {{I-D.ietf-dnsop-dns-wireformat-http}} is recommended instead.

The advantage of draft-dkg-dprive-demux-dns-http over this approach is
that existing DNS-over-TLS clients (of which there are several) don't
need to learn any HTTP framing or parsing, and can simply be repointed
to a server that already supports this demultiplexing on port 443.

For folks in the HTTP world that might sound like "just use HTTP", but
for an existing DNS client, it's an entirely different codebase to adopt
(or to build), with all the attendant bugs and maintenance risks.

Regards,

        --dkg