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

Hey DKG -

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.

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 :)

-P


On Wed, May 3, 2017 at 2:15 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

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