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

[Daniel Kahn Gillmor <[e-mail]>]

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
>> put the demuxing *before* the HTTP/1 server implementation gets access
>> to the data.
>
> 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