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

Mark Nottingham <mnot@mnot.net> Tue, 09 May 2017 01:20 UTC

Return-Path: <mnot@mnot.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 E611D127ABE for <dns-privacy@ietfa.amsl.com>; Mon, 8 May 2017 18:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ZfyhK5Nraa9l for <dns-privacy@ietfa.amsl.com>; Mon, 8 May 2017 18:20:42 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DD5126C83 for <dns-privacy@ietf.org>; Mon, 8 May 2017 18:20:41 -0700 (PDT)
Received: from [192.168.1.18] (unknown [124.189.96.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 97FD022E1F3; Mon, 8 May 2017 21:20:33 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <8737clqund.fsf@fifthhorseman.net>
Date: Tue, 09 May 2017 11:20:30 +1000
Cc: Martin Thomson <martin.thomson@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C207AD90-62B5-4AD0-BF34-C0EA52ED5696@mnot.net>
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> <CABkgnnUgy+iD8R=WOBFb8bFWrtX=06unmiA5Ne3eEkt_KLcGxw@mail.gmail.com> <8737clqund.fsf@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/X28OG3wT2wN_ZjNZgQ15pDWUcfU>
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: Tue, 09 May 2017 01:20:44 -0000

Hey DKG,

Throwing my .02 in, although it's similar to what you've heard from others upthread --

I wouldn't do this for h1; it'll be an interop nightmare. H2 gives you the properties you want and the implementation / testing burden is much more realistic.

For H2, I wouldn't use an ALPN token; define a new frame type or two that you can send optimistically before SETTINGS sync, stopping them if you don't get the right SETTING from your peer. Realistically, this is going to need to be configured into the client anyway, so there's some amount of pre-arrangement.

Cheers,



> On 4 May 2017, at 11:26 am, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote:
>> On 4 May 2017 at 10:43, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>>> I address this in the draft section "Why not ALPN?" -- if anyone thinks
>>> the text there could be improved, i'd be happy to hear suggestions for
>>> how to change it.
>> 
>> Mike is suggesting that you define one that is "http + dns" or maybe
>> "http or dns", which would mean that you could use either.  Then you
>> convince existing HTTP clients to use that (a few browsers would do
>> the job).  Even if they didn't actually DO DNS, you would still be
>> able to hide in the mass/mess that they represent.
> 
> hm, it sounds like that won't work for h2, given Patrick's point that h2
> isn't client-speaks-first.  Right?  If we tried to do something like
> "h2|dns", it seems like it would introduce a potential latency hit for
> any h2-specific client that proposed it, because the server couldn't
> send its first frame unsolicited.  I know you can't speak for Mozilla,
> but would you imagine firefox opting into this for normal http/2
> connections?
> 
>> In TLS 1.3, the server choice is hidden, so even where the server
>> doesn't pick this choice, it works.  In TLS 1.2, you probably want to
>> convince a few servers to pick this new thing, but that obviously
>> means more work for those servers.
> 
> For http/1.x, the draft is arguing that using an ALPN label is
> unnecessary -- so if that's right, what would we gain from a new ALPN
> label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN
> or the ALPN token "http/1.1")?
> 
> It looks to me like the new ALPN label introduces costs:
> 
> * implementations on both server and client need to specify it
> 
> * client implementations need to verify that it was chosen, and fail if
>   not
> 
> * network monitors can see that it was offered and discriminate against
>   the offerer at least (TLS 1.3), and in some cases the established
>   connections (TLS 1.2 and earlier).
> 
> What are the benefits of introducing a new ALPN label for demuxing
> HTTP/1.1 from DNS?
> 
> Thanks for the discussion,
> 
>     --dkg

--
Mark Nottingham   https://www.mnot.net/