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 21:26:46 -0400
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>
Message-ID: <8737clqund.fsf@fifthhorseman.net>
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

Received on Thursday, 4 May 2017 01:36:16 UTC

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