Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]
Patrick McManus <mcmanus@ducksong.com> Wed, 03 May 2017 19:04 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E19127977 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 3 May 2017 12:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.401
X-Spam-Level:
X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sendgrid.me
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 5WojviIc-ZTR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 3 May 2017 12:04:22 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97301294E1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 3 May 2017 12:01:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1d5zUD-0004UR-BF for ietf-http-wg-dist@listhub.w3.org; Wed, 03 May 2017 18:58:53 +0000
Resent-Date: Wed, 03 May 2017 18:58:53 +0000
Resent-Message-Id: <E1d5zUD-0004UR-BF@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1d5zU8-0004TH-Ih for ietf-http-wg@listhub.w3.org; Wed, 03 May 2017 18:58:48 +0000
Received: from o1678950229.outbound-mail.sendgrid.net ([167.89.50.229]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1d5zU1-0002Vb-4C for ietf-http-wg@w3.org; Wed, 03 May 2017 18:58:43 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=ZDxzA2ehY5oCkLD90ABHTv7EfNk=; b=wEwecGCVExDkQ8E2yA Rbr43w2NWW6aBHJik2K4nNaO2eI6oDGBINNm3NdwpTEEdbK6Z0PZoxxNXMSY+Qts JOVbuetOo8hWtBFKXp63K9XRKcSOqHIwVmV1RCfiLuexasOLnkmQ5rmXuSg5B2g3 UWUfNGFOpIk5kJrwnhKuvJW8I=
Received: by filter0855p1mdw1.sendgrid.net with SMTP id filter0855p1mdw1-27993-590A2815-2D 2017-05-03 18:57:25.399790924 +0000 UTC
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id xhKoFMGASEOPolMpCv-FGg for <ietf-http-wg@w3.org>; Wed, 03 May 2017 18:57:25.344 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id n4so47406865qte.2 for <ietf-http-wg@w3.org>; Wed, 03 May 2017 11:57:25 -0700 (PDT)
X-Gm-Message-State: AN3rC/7mFqFSMKWpWxRZ0D2tTmMa73BgyzH1nO/gjz8N9eCka7dhf1Dy k/Ov+nMx58BnTDwPRdU7ogAVBCVtcQ==
X-Received: by 10.200.42.29 with SMTP id k29mr35724524qtk.186.1493837845014; Wed, 03 May 2017 11:57:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.182.31 with HTTP; Wed, 3 May 2017 11:57:24 -0700 (PDT)
In-Reply-To: <87tw51remp.fsf@fifthhorseman.net>
References: <87tw51remp.fsf@fifthhorseman.net>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 03 May 2017 14:57:24 -0400
X-Gmail-Original-Message-ID: <CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com>
Message-ID: <CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="001a114114f21ab223054ea33a96"
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh7tBxtS5cFldkpYmjhAFbUAoo+8G+AV5W0I5x edRyMFN4rQEV/HonL+SwWEF0WHkbRYuzNknsVAoecub3ZPoaIAxc2fl8il++CnlJvqVaTMoQVUhIv+ Cb3GDqWH3H6CzIaSklOmZ1C8X6EnY0tbs2Ctd4etq8gZBgAaOIBnpuPYetuNyr1qBUsTk2ij34fwwu M=
Received-SPF: pass client-ip=167.89.50.229; envelope-from=bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net; helo=o1678950229.outbound-mail.sendgrid.net
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=0.580, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1d5zU1-0002Vb-4C 1078ee5780613e5d7f18ec2a759469b0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]
Archived-At: <http://www.w3.org/mid/CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33861
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hey DKG - My initial response is that legacy HTTP/1 implementations will sink you by scanning for stuff that looks like HTTP in your stream - even if the leading bytes don't match the production those RFCs required (and HTTP/1.0 is only informational anyhow). You can look at the websockets masking madness to see the lengths the community went to to avoid that kind of detection in rfc 6455. Coincidentally I have a draft with Paul Hoffman that we're close to publishing, that describes how to do DNS over https:// in a way that I think will play better with both the http and dns ecosystems than previous work in that area. It wouldn't be a http-wg item though, we don't normally take FOO-over-HTTP drafts here. That might be a better option - if you want to use the https port, and the https alpn token, perhaps the https protocol (without constraining its future) is the right choice :) -P On Wed, May 3, 2017 at 2:15 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > 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 >
- Demultiplexing HTTP and DNS on the same listener … Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Joe Touch
- Re: Demultiplexing HTTP and DNS on the same liste… Patrick McManus
- Re: Demultiplexing HTTP and DNS on the same liste… Patrick McManus
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Roy T. Fielding
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- Re: Demultiplexing HTTP and DNS on the same liste… Alex Rousskov
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Daniel Kahn Gillmor
- RE: Demultiplexing HTTP and DNS on the same liste… Mike Bishop
- Re: Demultiplexing HTTP and DNS on the same liste… Martin Thomson
- Re: Demultiplexing HTTP and DNS on the same liste… Patrick McManus
- Re: Demultiplexing HTTP and DNS on the same liste… Patrick McManus
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- Re: Demultiplexing HTTP and DNS on the same liste… Martin Thomson
- Re: Demultiplexing HTTP and DNS on the same liste… Martin Thomson
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- Re: Demultiplexing HTTP and DNS on the same liste… Daniel Kahn Gillmor
- RE: Demultiplexing HTTP and DNS on the same liste… Mike Bishop
- Re: Demultiplexing HTTP and DNS on the same liste… Stefan Eissing
- Re: [dns-privacy] Demultiplexing HTTP and DNS on … Ilari Liusvaara
- RE: Demultiplexing HTTP and DNS on the same liste… Mike Bishop
- Re: Demultiplexing HTTP and DNS on the same liste… Alex Rousskov
- Re: Demultiplexing HTTP and DNS on the same liste… 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