[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 18:17 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 BCB4712947F for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 11:17:21 -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=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 31jcIDkleO_8 for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 11:17:19 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9684512948D for <dns-privacy@ietf.org>; Wed, 3 May 2017 11:15:18 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E0FABF98C; Wed, 3 May 2017 14:15:18 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id CD6242061B; Wed, 3 May 2017 14:15:13 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Date: Wed, 03 May 2017 14:15:10 -0400
Message-ID: <87tw51remp.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/61cNpYrLUgGMHCRCMRXcry-FF8Y>
Subject: [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 18:17:22 -0000
Hi HTTP folks-- I've just pushed a revision to a recent individual submission about a technique for hiding DNS traffic that makes use of HTTP: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ It describes how a TLS server can offer both HTTPS and DNS-over-TLS on the same port, because valid initial messages from the client in each protocol are always distinguishable by the server. I brought this up first over on the DPRIVE mailing list (in CC), and i've made some initial cleanup and improvements based on the suggestions i got there. But i also wanted to bring this to the HTTP working group for feedback, since it's possible that i've mischaracterized the current state of HTTP in my analysis. Please review and let me know if i've gotten anything wrong! Also, if adopted widely, the draft has implications for the future evolution of stream-based HTTP as well as stream-based DNS (see below). And Joe Touch pointed out that the draft should explicitly update the HTTP as well as DNS specifications, so i've marked the latest revision of the draft that way. If you think that's OK (or if you think it's unnecessary), please let me know! Assumptions about HTTP ---------------------- The main constraints that the draft places on future stream-based versions of HTTP (that is, HTTP-over-TCP or HTTP-over-TLS, but not HTTP-over-QUIC any other fun non-stream transport) are: (a) it assumes that stream-based HTTP will remain a client-speaks-first protocol. (b) it assumes that the first flight of data sent by the client without expecting a response from the server will be at least 14 octets. (c) it requires that none of the first 14 octets of the stream sent by the client to the server be below 0x0A (LF) or above 0x7F. AFAICT, These constraints are already met by HTTP/1.0 and HTTP/1.1 and HTTP/2, as documented in the draft. Please tell me if that's wrong! Given HTTP/2's "connection preface", i've imagined thus far that future stream-based versions of HTTP would be fine having their own "connection preface" that meets constraints (b) and (c), and i don't see how a future version that listens on the same port as existing versions of HTTP could in any way violate constraint (a). I hope the members of this fine WG will tell me otherwise if that's not a good assumption. Also, if you review the draft and you think it's placing some additional constraint on future versions of stream-based HTTP that i haven't mentioned, please call it out! Implementation status --------------------- I have a functional implementation listening behind a TLS frontend on TCP port 443 on dns.cmrg.net right now, if anyone wants to experiment with it. Consider all the possibilities of this terrible layering violation! Both of these commands work just fine: wget -O- https://dns.cmrg.net/ kdig +tls @dns.cmrg.net:443 www.ietf.org The implementation is in C, freely-licensed, and available at https://gitlab.com/dkg/hddemux for anyone who wants to play with it. It's also available in Debian's unstable distro: https://packages.debian.org/unstable/hddemux Followup -------- The IETF mailing lists aren't well-structured for conversations that need to happen between WGs. I'm subscribed to both ietf-http-wg@w3.org and dns-privacy@ietf.org, and i welcome feedback from both working groups. But maybe some folks who want to follow up are not subscribed to both. Unless either WG complains, i encourage followup to be made to both mailing lists unless it's clearly specific to one protocol only, and i humbly ask admins of both lists to allow traffic from the other community through. Minor editorial cleanup can be made as a merge request or issue at https://gitlab.com/dkg/hddemux or by private e-mail. 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