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:35 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 F2ED812785F for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 18:35:49 -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 m_kNmp4sH30o for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 18:35:48 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 95C35127058 for <dns-privacy@ietf.org>; Wed, 3 May 2017 18:35:48 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0D83CF98C; Wed, 3 May 2017 21:35:48 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 621ED20C10; Wed, 3 May 2017 21:26:49 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: 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>
In-Reply-To: <CABkgnnUgy+iD8R=WOBFb8bFWrtX=06unmiA5Ne3eEkt_KLcGxw@mail.gmail.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> <CABkgnnUgy+iD8R=WOBFb8bFWrtX=06unmiA5Ne3eEkt_KLcGxw@mail.gmail.com>
Date: Wed, 03 May 2017 21:26:46 -0400
Message-ID: <8737clqund.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/0PJSSC3eMYAojVgu1LN3_htmWvA>
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:35:50 -0000

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