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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 14:15:10 -0400

Hi HTTP folks--

I've just pushed a revision to a recent individual submission about a
technique for hiding DNS traffic that makes use of HTTP:

  https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/

It describes how a TLS server can offer both HTTPS and DNS-over-TLS on
the same port, because valid initial messages from the client in each
protocol are always distinguishable by the server.

I brought this up first over on the DPRIVE mailing list (in CC), and
i've made some initial cleanup and improvements based on the suggestions
i got there.  But i also wanted to bring this to the HTTP working group
for feedback, since it's possible that i've mischaracterized the current
state of HTTP in my analysis.  Please review and let me know if i've
gotten anything wrong!

Also, if adopted widely, the draft has implications for the future
evolution of stream-based HTTP as well as stream-based DNS (see below).
And Joe Touch pointed out that the draft should explicitly update the
HTTP as well as DNS specifications, so i've marked the latest revision
of the draft that way.  If you think that's OK (or if you think it's
unnecessary), please let me know!

Assumptions about HTTP
----------------------

The main constraints that the draft places on future stream-based
versions of HTTP (that is, HTTP-over-TCP or HTTP-over-TLS, but not
HTTP-over-QUIC any other fun non-stream transport) are:

 (a) it assumes that stream-based HTTP will remain a client-speaks-first
     protocol.

 (b) it assumes that the first flight of data sent by the client without
     expecting a response from the server will be at least 14 octets.

 (c) it requires that none of the first 14 octets of the stream sent by
     the client to the server be below 0x0A (LF) or above 0x7F.

AFAICT, These constraints are already met by HTTP/1.0 and HTTP/1.1 and
HTTP/2, as documented in the draft.  Please tell me if that's wrong!

Given HTTP/2's "connection preface", i've imagined thus far that future
stream-based versions of HTTP would be fine having their own "connection
preface" that meets constraints (b) and (c), and i don't see how a
future version that listens on the same port as existing versions of
HTTP could in any way violate constraint (a).  I hope the members of
this fine WG will tell me otherwise if that's not a good assumption.

Also, if you review the draft and you think it's placing some additional
constraint on future versions of stream-based HTTP that i haven't
mentioned, please call it out!

Implementation status
---------------------

I have a functional implementation listening behind a TLS frontend on
TCP port 443 on dns.cmrg.net right now, if anyone wants to experiment
with it.  Consider all the possibilities of this terrible layering
violation!

Both of these commands work just fine:

    wget -O- https://dns.cmrg.net/

    kdig +tls @dns.cmrg.net:443 www.ietf.org

The implementation is in C, freely-licensed, and available at
https://gitlab.com/dkg/hddemux for anyone who wants to play with it.

It's also available in Debian's unstable distro:
https://packages.debian.org/unstable/hddemux

Followup
--------

The IETF mailing lists aren't well-structured for conversations that
need to happen between WGs.

I'm subscribed to both [email-masked] and [email-masked], and
i welcome feedback from both working groups.  But maybe some folks who
want to follow up are not subscribed to both.  Unless either WG
complains, i encourage followup to be made to both mailing lists unless
it's clearly specific to one protocol only, and i humbly ask admins of
both lists to allow traffic from the other community through.

Minor editorial cleanup can be made as a merge request or issue at
https://gitlab.com/dkg/hddemux or by private e-mail.

Regards,

        --dkg

---

From: Joe Touch <[email-masked]>
Date: Wed, 3 May 2017 11:33:38 -0700

Hi, all,

FWIW...speaking from the experience I have leading the IANA ports expert
review team and developing BCP165 (RFCs 6335 and RFC7605):

> unnecessary), please let me know!
I would characterize this as redefining ports 80 and 443 to include DNS
as part of the HTTP specification.

That has some very important ramifications, indicated here as
"assumptions", that limit the future development of HTTP (notably
reserving certain prefixes and patterns to differentiate DNS requests
from HTTP). That could constrain all current and future uses of ports 80
and 443, and could potentially affect any other service that uses HTTP
as a framing layer.

Joe

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 12:26:40 -0700

>   https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/

Cool idea. One concern might be compatibility with other similar
mechanisms. For example, there are protocols such as Netscaler Client IP:

https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/

or HAProxy's Proxy Protocol:

https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

Where proxies may insert their own pre-amble on the connection, to pass on
something like an L4 X-Forwarded-For.

Sometimes the backends behind these proxies have to accept traffic directly
too, and they fingerprint the first few bytes to determine whether it's a
direct HTTP connection, or a proxied request. I haven't thought through it,
but it might get a little complicated doing two levels of demuxing, and it
might not even be possible in some cases.

-- 
Colm

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 May 2017 12:35:52 -0700

> On May 3, 2017, at 11:33 AM, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 

I agree with Joe.  My answer would be "no".  It certainly isn't an Update
for the HTTP specs.

I see no reason to suggest that spraying DNS on an HTTP connection would
be interoperable.  HTTP/1.x has a tradition (good or bad) of allowing
robust parsing of bad messages, which means no analysis of DNS uniqueness
can guard against the potential variance of a thousand or so independent
implementations of servers and intermediaries (there are at least four
figures of independent server development in the craft-your-own-microserver
category).

In contrast, it is trivial to transform a DNS query into a GET request
which can be handled by any current or future version of HTTP.
All you need is the absolute URI, which is already defined, and a
media type for the response payload.  That would just be using HTTP,
so no need to call that an update either.

....Roy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 19:12:01 -0400

> figures of independent server development in the craft-your-own-microserver

Perhaps the draft needs to be clear that this draft provides guidance
for servers that *want* to be able to distinguish a DNS-over-TLS stream
from an HTTP-over-TLS stream.  According to the published specs, a
server is within its rights to not treat invalid HTTP requests as valid
HTTP requests, right?

> so no need to call that an update either.

Agreed on this one, quoting from the draft:

    If being able to interleave DNS queries with HTTP requests on a
    single stream is desired, a strategy like
    {{I-D.ietf-dnsop-dns-wireformat-http}} is recommended instead.

The advantage of draft-dkg-dprive-demux-dns-http over this approach is
that existing DNS-over-TLS clients (of which there are several) don't
need to learn any HTTP framing or parsing, and can simply be repointed
to a server that already supports this demultiplexing on port 443.

For folks in the HTTP world that might sound like "just use HTTP", but
for an existing DNS client, it's an entirely different codebase to adopt
(or to build), with all the attendant bugs and maintenance risks.

Regards,

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 19:17:42 -0400

Hi Patrick--

On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote:

> My initial response is that legacy HTTP/1 implementations will sink you by
> scanning for stuff that looks like HTTP in your stream - even if the
> leading bytes don't match the production those RFCs required (and HTTP/1.0
> is only informational anyhow). You can look at the websockets masking
> madness to see the lengths the community went to to avoid that kind of
> detection in rfc 6455.

Are you talking about an existing HTTP/1 server implementation?  The
idea of the demuxing stage is that a server that opts into this would
put the demuxing *before* the HTTP/1 server implementation gets access
to the data.

> Coincidentally I have a draft with Paul Hoffman that we're close to
> publishing, that describes how to do DNS over https:// in a way that I
> think will play better with both the http and dns ecosystems than previous
> work in that area. It wouldn't be a http-wg item though, we don't normally
> take FOO-over-HTTP drafts here. That might be a better option - if you want
> to use the https port, and the https alpn token, perhaps the https protocol
> (without constraining its future) is the right choice :)

is the draft you and Paul are working on different than
ietf-dnsop-dns-wireformat-http ?  Can they be reconciled?  See my
response to Roy T. Fielding (upthread) for why the demux approach seems
cleaner and safer for clients as long as we're using stream-based
transport.

I certainly wouldn't want this work to get in the way of
ietf-dnsop-dns-wireformat-http (or any similar proposal), but i don't
think it does.  does it?

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 19:21:44 -0400

On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote:
> I forgot to mention another potential challenge with the demux approach -
> h2 is not client send first.. typically both sides send SETTINGS
> simultaneously.. and its important to the server not to hold those back
> .5RTT as it can contain a bunch of configuration information (buffer
> sizing, levels of parallelism, extension negotiation, etc..) that it wants
> the client to start honoring asap. (Whether this is actually simultaneous
> boils down to which flavor of tls handshake is done.)

Ah!  Thanks for this heads-up.  That's definitely an interesting
wrinkle.  How does this interact with HTTP/1 clients connecting to the
service?  or is it only possible to do this because of the negotiated
ALPN?

If so, perhaps the demuxing needs to be done only when not sending an
alpn of "h2", and the draft can drop the HTTP/2 section.  What do you
think?

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 19:50:00 -0400

Hi Colm--

> might not even be possible in some cases.

Thanks for the pointers to these protocols!  It's good to know that
people are already doing this sort of demuxing on the fly in some cases,
and that they haven't broken HTTP for everyone else yet :)

One approach for the current draft would be to explicitly call these
protocols out as things that are incompatible with he proposed form of
demuxing.  I'd be happy to add a generic "do not mix this mechanism with
other similar mechanisms" section.  I've just opened
https://gitlab.com/dkg/hddemux/issues/2 to make sure that doesn't get
lost.

FWIW, it actually looks like both versions of haproxy's Proxy Protocol
can be distinguished from DNS just by looking at the same octet ranges.
For the human-readable protocol, its first many octets (more than 14 of
them) are all within the 0x0A and 0x7F range.  for the binary protocol,
its initial static 12-octet preamble puts a 0xD nybble directly in the
DNS header's RCODE field, which should be 0x0 in a DNS stream assuming
the initial client message must be a Query and not a Response.

But i don't plan to turn this draft into a generic
how-to-demux-anything-with-anything draft, so i don't think i'll write
that up more formally ;)

So i think the result is to say that if a server is already demuxing an
inbound stream based on the same octets, they might not want to adopt
this.  Do you have any qualms with making this particular concern
something that is out-of-scope for the draft?

Regards,

        --dkg

---

From: Mike Bishop <[email-masked]>
Date: Thu, 4 May 2017 00:14:44 +0000

It's ALPN.  At first blush, I would pick a different ALPN token for h2+DNS and define it as a new, derivative protocol.

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:[email-masked]] 
Sent: Wednesday, May 3, 2017 4:22 PM
To: Patrick McManus <[email-masked]>; Patrick McManus <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; DNS Privacy Working Group <[email-masked]>
Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote:
> simultaneously.. and its important to the server not to hold those 
> back .5RTT as it can contain a bunch of configuration information 
> (buffer sizing, levels of parallelism, extension negotiation, etc..) 
> that it wants the client to start honoring asap. (Whether this is 
> actually simultaneous boils down to which flavor of tls handshake is 
> done.)

Ah!  Thanks for this heads-up.  That's definitely an interesting wrinkle.  How does this interact with HTTP/1 clients connecting to the service?  or is it only possible to do this because of the negotiated ALPN?

If so, perhaps the demuxing needs to be done only when not sending an alpn of "h2", and the draft can drop the HTTP/2 section.  What do you think?

     --dkg

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 10:21:20 +1000

> 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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 20:43:40 -0400

On Thu 2017-05-04 10:21:20 +1000, Martin Thomson 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.
>

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 20:38:21 -0400

Hi Alex--

On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote:
> On 05/03/2017 05:17 PM, Daniel Kahn Gillmor wrote:
>> The idea of the demuxing stage is that a server that opts into this would
> Think of the HTTP proxies, not just origin servers. Using an HTTP proxy
> is often _required_ when sending traffic over an HTTP port. These HTTP
> proxies will break all the muxed DNS traffic they will get. Opting them
> "in" will be a lot more difficult than opting a specialized origin
> server that wants to participate...
>
> And yes, this deployment concern applies to port 443 traffic as well,
> unfortunately.

Thanks for this, but i'm not sure i understand the whole situation
you're describing.  Can you help me make more sense of it?  Here's a few
things i think you might be saying:

 0) A DNS client shouldn't expect this mechanism to work in the clear
    over port 80, because existing transparent HTTP proxies that the
    client doesn't know about will likely choke on it.  I've noted this
    as https://gitlab.com/dkg/hddemux/issues/3

 1) A DNS client shouldn't expect to use this mechanism through an
    explicit HTTP proxy either, as the explicit proxy will also choke on
    it.  However, i'm not sure how this works for port 443.  I think
    you're saying that the common network interference pattern is to
    block outbound TCP port 443 explicitly, but to allow HTTP CONNECT
    when established through the local required HTTP proxy.  Is that
    right?  I've tried to capture this as
    https://gitlab.com/dkg/hddemux/issues/4

I'm not sure what the right tradeoffs are here, or how widespread such
network interference is.  I am aware that the draft under discussion
can't solve all problems for all networks.  But i imagine that any
network that blocks TCP port 443 outbound and expects clients to route
through an HTTP CONNECT to an explicit proxy has already blocked TCP
port 853 outbound, so the DNS client that tries to use DNS-over-TLS is
no worse off for trying 443 instead of 853, at any rate.

Am i missing some other details of the circumstances you're describing?
Do you have suggestions of text for the draft that would address these
concerns?

Regards,

        --dkg

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 11:11:59 +1000

> the text there could be improved, i'd be happy to hear suggestions for

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.

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 21:06:50 -0400

On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote:
>> ietf-dnsop-dns-wireformat-http ?  Can they be reconciled?
>
> its a superset of that -more aligned with HTTP than that draft, but it can
> also carry wireformat.
>
> your work doesn't break it anymore than it breaks h2 generally :)

Is your draft h2-specific, or is it valid for http/1.x as well?

> I totally support the end goal here of dns looking like https.. but
> honestly I didn't hear anything about cleaner and safer. I heard that you
> wanted to use the https port, the https alpn token, and constrain the http
> protocol, but found the requirement to implement http burdening :)

:) I'm not actually interested in constraining the http protocol, i'm
just trying to make something that works with existing versions of the
http protocol.  I documented my expectations of future versions of HTTP
to make sure that they're understood, which got me to your helpful point
about h2 not being client-speaks-first.  I've documented that here now,
btw:

    https://gitlab.com/dkg/hddemux/issues/5

I'd expect this draft to work with no ALPN token at all (which is the
traditional HTTP/1.1-over-TLS use case, and ALPN is still not mandatory
for TLS, right?

the "cleaner and safer" remark was from the DNS client point of view:
they already implement DNS-over-TLS, they just need to be pointed to the
right server and the right port -- that's literally no change to the
existing code, and as long as they don't indicate an alpn of "h2" they
should be safe, right?

> The most straightforward way seems to make dns look like https is to
> actually carry it in https.
>
> perhaps we could work together on making a dns client more capable in
> this regard?

I'd be happy to do that to make something like this work with HTTP/2.
I'll contact you off-list about what might be sensible next steps.

It occurs to me that an h2 CONNECT stream to localhost:53 ought to be
sufficient to do a stream-based wireformat transition (assuming that
there was a local DNS-over-TCP service active).  Does that seem right to
you?  If that's the case, then a DNS-only client would "only" need to
know enough HTTP/2 to establish the connection and to parse the incoming
frames.  Are there specific advantages of making the protocol
entanglement more complex?

----

Given that not everyone is adopting HTTP/2 right away, though, do you
think the proposed draft would be acceptable if it was limited in scope
to demuxing DNS with HTTP/1.x?

Regards,

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 21:13:58 -0400

On Wed 2017-05-03 20:49:22 -0400, Patrick McManus wrote:
> the http/1 share of https:// traffic is dwindling fast. Its down to about
> 1/3 of https for me. So if you're looking to hide in a big pool, that's a
> shrinking segment.

1/3 of https traffic is still huge collateral damage to inflict, if a
network adversary were to try to block things to stamp out encrypted DNS
traffic.

> imo its a bigger problem because any rfc that required h1 would
> dis-incentivize h2 which is something the IETF should surely not want to do
> for many reasons.

I also wouldn't want to disincentivize h2.  But any server which still
offers h1, at any time in the future could implement this approach with
relatively little overhead (and no impact on h2 adoption) and it already
works today.

So an updated draft would be intended mainly as a stopgap measure while
we're getting DNS-over-h2 spec'ed and implemented, and as something a
server can offer to clients that don't yet speak h2.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 May 2017 21:26:46 -0400

> 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?

> 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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 11:44:22 +1000

> but would you imagine firefox opting into this for normal http/2

Patrick owns that decision and could tell you.

The cost would be on the DNS-enabled client, who would have to detect
and ignore any h2 preface from a server for that protocol.

> or the ALPN token "http/1.1")?

Upthread we see several reasons why that argument might not be valid.

>  * client implementations need to verify that it was chosen, and fail if

I would have thought that these are benefits.

>    connections (TLS 1.2 and earlier).

A lot depends on the population size.  If this were enabled in a
sizeable chunk of the browser market, then the TLS 1.3 option goes
away.  Note that you only create the full exposure if you decide to
implement this at a server without also implementing TLS 1.3.

> What are the benefits of introducing a new ALPN label for demuxing

Certainty, primarily.  A clear signal that both peers agree to use the
same protocol.  It might also reduce ossification effects, but I
haven't gamed that out.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 4 May 2017 02:53:38 +0000

No, the network observer can observe which clients are offering that protocol as one of a set of options -- selection happens server-side.  In TLS 1.3, the selection is part of the EncryptedExtensions, no?  Which means an observer can tell that the client offers it, but can't tell whether the server is selecting it at any given time.  (Without making the same offer to the server and seeing what it chooses for them, at least.)

As Martin says, if you can get a broad set of clients to start offering it all the time, a network controller would have to kill a lot of connections to be sure they didn't let DNS traffic out.  (Of course, if major networks start killing connections with this ALPN token, major implementations would probably find themselves having to implement a fallback, and you haven't won.)  My other major issue with your approach is something we learned while prototyping h2c:  Looking at the content of a message and dynamically swapping out parsers takes a lot of investment to do performantly.  You can bound it by only looking at the beginning of the stream, as you do, but it still hurts.

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.

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:[email-masked]] 
Sent: Wednesday, May 3, 2017 5:44 PM
To: Martin Thomson <[email-masked]>; Mike Bishop <[email-masked]>
Cc: Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>; DNS Privacy Working Group <[email-masked]>
Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

> 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

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 4 May 2017 11:42:25 +0200

> Am 04.05.2017 um 04:53 schrieb Mike Bishop <[email-masked]>:
> 

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)

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 4 May 2017 13:16:04 +0300

> https://gitlab.com/dkg/hddemux/issues/2 to make sure that doesn't get

Note that in case of PROXY, you shouldn't try to discriminate it from
DNS. Read the PROXY header if source is configured to have one and then
tell apart HTTP and DNS if appropriate.

Other reverse proxying schemes that actually play with HTTP headers are
incompatible with demuxing HTTP and DNS this way, since those assume that
all traffic is HTTP.

-Ilari

---

From: Mike Bishop <[email-masked]>
Date: Thu, 4 May 2017 18:23:35 +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:[email-masked]] 
Sent: Thursday, May 4, 2017 2:42 AM
To: Daniel Kahn Gillmor <[email-masked]>
Cc: Martin Thomson <[email-masked]>; McManus Patrick <[email-masked]>; HTTP Working Group <[email-masked]>; DNS Privacy Working Group <[email-masked]>; Mike Bishop <[email-masked]>
Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Cheers,

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 5 May 2017 10:27:21 -0600

On 05/03/2017 06:38 PM, Daniel Kahn Gillmor wrote:

>> Think of the HTTP proxies, not just origin servers.

> Here's a few things i think you might be saying:
> 
>     it. 

Yes, both.

You can address (1) if you add support for HTTP proxies to the DNS
client, but, at that point, you should just do the Right Thing and
implement DNS-over-HTTP instead IMHO.

> However, i'm not sure how this works for port 443.

Due to the success of the "TLS everywhere" campaign, port 443 is nearly
the same as port 80 from the deployment point of view these days. There
are proxies that intercept and inspect port 443 traffic (just like they
intercept and inspect port 80 traffic) and there are explicit proxies
that inspect CONNECT tunnels, just like they inspect unencrypted HTTP
messages. Needless to say, your DNS client may prohibit such inspections
(like some HTTP sites/apps do) at the risk of being blocked or let the
users/admin configure who to trust (like HTTP clients do).

> Do you have suggestions of text for the draft that would address these

AFAICT, these concerns cannot be properly addressed in the proposed
DNS-or-HTTP framework. They can only be addressed by a proper
DNS-over-HTTP protocol.

HTH,

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 May 2017 11:20:30 +1000

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 <[email-masked]> wrote:
> 

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 9 May 2017 07:29:51 +0300

On Tue, May 09, 2017 at 11:20:30AM +1000, Mark Nottingham wrote:
> 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.

I don't think what you are saying is workable.

>From what I can gather, the intention for this thing DKG gave is to
be pure TLS-wrapped DNS from the client side. Any SETTINGS or otherwise
from the server breaks this. And it can not use any odd ALPN values
either.

This impiles this thing can't be used with HTTP/2, as it is both-
sides-send-first, instead of client-sends-first.

Yes, if you try this with random HTTP server, it will choke. The
intention is that the client knows via configuration that the HTTP
server is capable of DNS demux.

The schemes for riding DNS on top of HTTP or HTTP/2 framing structure
are totally different thing. Those are obviously more compatible with
HTTP/2.

-Ilari

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 May 2017 14:32:17 +1000

> On 9 May 2017, at 2:29 pm, Ilari Liusvaara <[email-masked]> wrote:
> 

Sorry if it wasn't clear -- what I was saying was "don't do this (DKG's proposal); do that (DNS-over-HTTP)".

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 17 May 2017 22:57:17 -0400

Thanks to everyone for their useful feedback and commentary.  I've just
uploaded draft-dkg-dprive-demux-dns-http-03, which attempts to include
the insights that people have shared here.

Most significantly, it drastically tightens the scope of the draft by
focusing on HTTP/1.x only and explicitly excluding HTTP/2 and all future
versions of HTTP.

As such, it can be seen as a stopgap measure until one of the
DNS-over-HTTP/2 drafts reaches consensus (and running code).  I'm
interested in seeing that happen, and will work on it, but i've got to
come up to speed on h2 and its implementations myself.  And in the
meantime, i think can be useful to document what is working today.

I welcome further feedback on the draft!

          --dkg