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

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 ietf-http-wg@w3.org and dns-privacy@ietf.org, 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