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

Alex Rousskov <rousskov@measurement-factory.com> Fri, 05 May 2017 16:27 UTC

Return-Path: <rousskov@measurement-factory.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C28129AE7 for <dns-privacy@ietfa.amsl.com>; Fri, 5 May 2017 09:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoZCtebQyjDo for <dns-privacy@ietfa.amsl.com>; Fri, 5 May 2017 09:27:23 -0700 (PDT)
Received: from mail.measurement-factory.com (mail.measurement-factory.com [104.237.131.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0373C129AD1 for <dns-privacy@ietf.org>; Fri, 5 May 2017 09:27:23 -0700 (PDT)
Received: from [65.102.233.169] (unknown [65.102.233.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.measurement-factory.com (Postfix) with ESMTPSA id 300BDE02F; Fri, 5 May 2017 16:27:22 +0000 (UTC)
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
References: <87tw51remp.fsf@fifthhorseman.net> <CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com> <87o9v9r0mh.fsf@fifthhorseman.net> <2564afa5-1a0d-c3e0-e620-37d67482ce28@measurement-factory.com> <87fuglqww2.fsf@fifthhorseman.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
From: Alex Rousskov <rousskov@measurement-factory.com>
Message-ID: <26d3a30c-02bd-faca-5bc8-a7d9748a753c@measurement-factory.com>
Date: Fri, 05 May 2017 10:27:21 -0600
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <87fuglqww2.fsf@fifthhorseman.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/dZ1nW98CoW3bfkh1gSABqZ1dnzc>
Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 16:30:36 -0000

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

> On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote:
>> Think of the HTTP proxies, not just origin servers.

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

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

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.