W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

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

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 03 May 2017 20:43:40 -0400
To: Martin Thomson <martin.thomson@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Message-ID: <87bmr9qwn7.fsf@fifthhorseman.net>
On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote:
> On 4 May 2017 at 10:14, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> It's ALPN.  At first blush, I would pick a different ALPN token for
>> h2+DNS and define it as a new, derivative protocol.
>
> For DKG to realize his goal, every client would have to offer that
> label.  That's not impossible, nor does it make it a bad choice, but
> you have to realize that this isn't as good an outcome.

if you're going to define an ALPN label, you might as well just pick
"dns" and then do straight DNS-over-TLS with it (no need for in-stream
demuxing).  The problem with this approach is that the network monitor
can observe which clients are picking "dns" and which ones are picking
"http/1.1", which puts you back in the position where the network
adversary can trivially hobble DNS-over-TLS requests while permitting
HTTPS.

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.

All the best,

        --dkg

Received on Thursday, 4 May 2017 01:07:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC