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> Thu, 04 May 2017 01:12 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 176FE127058 for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 18:12:26 -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] autolearn=unavailable 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 lHFoMzTMFo3c for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 18:12:23 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id BED8A1294F8 for <dns-privacy@ietf.org>; Wed, 3 May 2017 18:12:23 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5D37DF98C; Wed, 3 May 2017 21:06:58 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id BD5112126D; Wed, 3 May 2017 21:06:50 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
In-Reply-To: <CAOdDvNqB7n60nZV9Y45gHOD6jEC50Xjyq4SJKchniJhwK8nXXQ@mail.gmail.com>
References: <87tw51remp.fsf@fifthhorseman.net> <CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com> <87o9v9r0mh.fsf@fifthhorseman.net> <CAOdDvNqB7n60nZV9Y45gHOD6jEC50Xjyq4SJKchniJhwK8nXXQ@mail.gmail.com>
Date: Wed, 03 May 2017 21:06:50 -0400
Message-ID: <878tmdqvkl.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/hsZHfjSNBeaemcVTWLZedJ9SyGg>
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: Thu, 04 May 2017 01:12:26 -0000
On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote: >> is the draft you and Paul are working on different than >> ietf-dnsop-dns-wireformat-http ? Can they be reconciled? > > its a superset of that -more aligned with HTTP than that draft, but it can > also carry wireformat. > > your work doesn't break it anymore than it breaks h2 generally :) Is your draft h2-specific, or is it valid for http/1.x as well? >> response to Roy T. Fielding (upthread) for why the demux approach seems >> cleaner and safer for clients as long as we're using stream-based >> transport. > > I totally support the end goal here of dns looking like https.. but > honestly I didn't hear anything about cleaner and safer. I heard that you > wanted to use the https port, the https alpn token, and constrain the http > protocol, but found the requirement to implement http burdening :) :) I'm not actually interested in constraining the http protocol, i'm just trying to make something that works with existing versions of the http protocol. I documented my expectations of future versions of HTTP to make sure that they're understood, which got me to your helpful point about h2 not being client-speaks-first. I've documented that here now, btw: https://gitlab.com/dkg/hddemux/issues/5 I'd expect this draft to work with no ALPN token at all (which is the traditional HTTP/1.1-over-TLS use case, and ALPN is still not mandatory for TLS, right? the "cleaner and safer" remark was from the DNS client point of view: they already implement DNS-over-TLS, they just need to be pointed to the right server and the right port -- that's literally no change to the existing code, and as long as they don't indicate an alpn of "h2" they should be safe, right? > The most straightforward way seems to make dns look like https is to > actually carry it in https. > > perhaps we could work together on making a dns client more capable in > this regard? I'd be happy to do that to make something like this work with HTTP/2. I'll contact you off-list about what might be sensible next steps. It occurs to me that an h2 CONNECT stream to localhost:53 ought to be sufficient to do a stream-based wireformat transition (assuming that there was a local DNS-over-TCP service active). Does that seem right to you? If that's the case, then a DNS-only client would "only" need to know enough HTTP/2 to establish the connection and to parse the incoming frames. Are there specific advantages of making the protocol entanglement more complex? ---- Given that not everyone is adopting HTTP/2 right away, though, do you think the proposed draft would be acceptable if it was limited in scope to demuxing DNS with HTTP/1.x? Regards, --dkg
- [dns-privacy] Demultiplexing HTTP and DNS on the … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Joe Touch
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Colm MacCárthaigh
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Roy T. Fielding
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Mike Bishop
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Martin Thomson
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Martin Thomson
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Martin Thomson
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Mike Bishop
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Stefan Eissing
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Ilari Liusvaara
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Mike Bishop
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Alex Rousskov
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Mark Nottingham
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Ilari Liusvaara
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Mark Nottingham
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor