IETF Logo Mail Archive

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

Mike Bishop <Michael.Bishop@microsoft.com> Thu, 04 May 2017 18:23 UTC

Return-Path: <Michael.Bishop@microsoft.com>
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 95ECC128BB6 for <dns-privacy@ietfa.amsl.com>; Thu, 4 May 2017 11:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 P78zqF4OYZ0T for <dns-privacy@ietfa.amsl.com>; Thu, 4 May 2017 11:23:37 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B9A12706D for <dns-privacy@ietf.org>; Thu, 4 May 2017 11:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I0pW1gtzGjJpTuwiimpL3R9nWjfcPy+amDEaf7JEwSk=; b=jsrIl66j2VOf0fhxHvHH2Y3JLJ3lTMUCudUQ4xpt1Za5O4hdeFIYjFG/QgPxzx3n7i8tQ25nYPhfskGXn6OKFs6LbbDghE1B3eT8/22k1U7lrul0jpDPAeie6LFoxOzfmSGCe2SgMIP/f4ea349Uu36xfpkpSrokL7OXlpwJnDE=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 18:23:36 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1061.021; Thu, 4 May 2017 18:23:36 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
CC: Martin Thomson <martin.thomson@gmail.com>, McManus Patrick <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]
Thread-Index: AQHSxLrAwbR+E75n5kCXertTWK9cC6HkfSsA
Date: Thu, 04 May 2017 18:23:35 +0000
Message-ID: <BN6PR03MB27081D37B1138616F0C8DD0187EA0@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <87tw51remp.fsf@fifthhorseman.net> <CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com> <CAOdDvNruCCyB2rsF9VgaVEOjQGD82wA0AiLAghiGjDM0SpBFPQ@mail.gmail.com> <87lgqdr0fr.fsf@fifthhorseman.net> <BN6PR03MB27085632B5CBA7324894699487EA0@BN6PR03MB2708.namprd03.prod.outlook.com> <CABkgnnVLasxAfsezDp4H0cSOme5okHUY0ruG7EzgsNEW89SmDQ@mail.gmail.com> <87bmr9qwn7.fsf@fifthhorseman.net> <BN6PR03MB2708762328EE8C91A229B9B987EA0@BN6PR03MB2708.namprd03.prod.outlook.com> <B3FE4E3A-B6C2-44C8-ADFC-20ADD4284E72@greenbytes.de>
In-Reply-To: <B3FE4E3A-B6C2-44C8-ADFC-20ADD4284E72@greenbytes.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:4898:80e8:8::de]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:h//u0C1E8bDoMR6GzBay2Ln2GCURPCEt4CaX36N8en0zKvqW7fcxmJpvJlxIWPEDvCLs602UxeLl+ZgXZEISZiQ21LyaTo9WphZJ7KMK+b36DQM5Yvi9w6SAF8SOnwZqvKkyX/OUaWD+Hgop22r4SZ8ZOl0dMVFhQ/VAo4Ji73K9ops4h9ba2EkVNSQgIkn7EQeHYKjDSQNruK6RpmYG9ed6zHM1zTNws+Miqblslr2m8tBwaPe3KfVSURJ4KnZpNoU+bITiOW1VGkG01+A1yPIKwuIpNMcaBU12rfVStHyJV9DPtJ3TNzP9nG5DdJ4Utp6zUd/axk50wf0F6avP1qE8pg18P/nJaXv3Keo+dx4=
x-ms-office365-filtering-correlation-id: 93f9de20-299a-4c27-05b2-08d4931aadf0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2707;
x-microsoft-antispam-prvs: <BN6PR03MB270796BE6927BFC7E18D179E87EA0@BN6PR03MB2707.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707;
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39410400002)(39400400002)(39850400002)(39450400003)(13464003)(377454003)(8990500004)(25786009)(53936002)(10290500003)(2900100001)(38730400002)(53546009)(5005710100001)(6506006)(478600001)(6246003)(6436002)(50986999)(86612001)(15650500001)(77096006)(76176999)(54356999)(55016002)(86362001)(99286003)(9686003)(54906002)(74316002)(305945005)(102836003)(6116002)(229853002)(7696004)(5660300001)(93886004)(33656002)(122556002)(39060400002)(2950100002)(230783001)(7736002)(8936002)(81166006)(189998001)(8676002)(3660700001)(10090500001)(3280700002)(2906002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 18:23:35.9671 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/3tKcjslhn1pPA-SflZlFNMjxFaM>
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 18:23:40 -0000

Even on the same connection as HTTP traffic, this would work -- it just wouldn't be flow-controlled beyond TCP, while the HTTP/2 streams would be.

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] 
Sent: Thursday, May 4, 2017 2:42 AM
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Martin Thomson <martin.thomson@gmail.com>; McManus Patrick <mcmanus@ducksong.com>; HTTP Working Group <ietf-http-wg@w3.org>; DNS Privacy Working Group <dns-privacy@ietf.org>; Mike Bishop <Michael.Bishop@microsoft.com>
Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]


> Am 04.05.2017 um 04:53 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> 
> If you want to do this transparently inside of HTTP without looking different on the outside, define an HTTP/2 extension for tunneling DNS.  Unknown frame types and settings MUST be ignored -- the client can start shipping DNS queries on stream 0 speculatively and have them ignored if the server doesn't speak your extension, or wait to see if the server's SETTINGS frame indicates that it supports the extension (after 1 RTT), both without any loss of compatibility or performance (other than extra bytes).  It doesn't get you HTTP/1.x compatibility, but I'm dubious anything you do within that can be done performantly nor is it a long-term pool to hide in.

I recommend this as a h2 based solution. If a client wants to use the connection purely for DNS traffic, you just need to add the static preamble and SETTINGS bytes and prefix each data chunk (of max 16K) with a 9 byte h2 frame header. And read the same in answers from the server. Ignoring any frame type you do not know. Flow control is done entirely by TCP.

This gives you an up and down byte stream transferred as h2 extension frames. The connection handshake looks 100% identical before the strong encryption kicks in. And you could the same, maybe with some tweaked frame identifiers, on a QUIC connection in the future, I would assume.

If you want to define something that really lives besides other h2 streams on the same connection, then you need to make use of h2 flow control and other features. But as I understood, this is not a scenario you are aiming for.

Cheers,

-Stefan (h2 in Apache httpd)

v2.23.0 | Report a Bug | By Email