Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

Paul Vixie <vixie@tisf.net> Thu, 17 December 2015 03:50 UTC

Return-Path: <vixie@tisf.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD2F1AC445 for <dnsop@ietfa.amsl.com>; Wed, 16 Dec 2015 19:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
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 WqlZQV-AP-WA for <dnsop@ietfa.amsl.com>; Wed, 16 Dec 2015 19:50:05 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A721AC43C for <dnsop@ietf.org>; Wed, 16 Dec 2015 19:50:03 -0800 (PST)
Received: from linux-85bq.suse (unknown [183.131.102.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8F2FB13B5C; Thu, 17 Dec 2015 03:50:02 +0000 (UTC)
From: Paul Vixie <vixie@tisf.net>
To: dnsop@ietf.org
Date: Wed, 16 Dec 2015 19:50:01 -0800
Message-ID: <1880287.khLzgcvgCq@linux-85bq.suse>
Organization: TISF
User-Agent: KMail/4.14.10 (Linux/4.1.13-5-default; KDE/4.14.10; x86_64; ; )
In-Reply-To: <20151217020803.GA28588@mycre.ws>
References: <20151217020754.6915b71c@pallas.home.time-travellers.org> <20151217020803.GA28588@mycre.ws>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart17906866.DCTtWIKVqs"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/E6IldwbpXWAFCiZBikHbULoqpX8>
Cc: Shane Kerr <shane@time-travellers.org>, Robert Edmonds <edmonds@mycre.ws>
Subject: Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 03:50:06 -0000

On Wednesday, December 16, 2015 09:08:03 PM Robert Edmonds wrote:
> Shane Kerr wrote:
> > I have updated the DNS over HTTP review document that I sent some days
> > ago. Thanks to Jinmei for reading it.
> > 
> > As I mentioned before, if there is interest then my co-authors and I
> > are happy to try to get the working group to adopt the document. If
> > there is not interest, then we are happy to go forward with an
> > individual submission.
> > 
> > If I don't hear any positive support over the next week or two then
> > that is a pretty clear sign that the working group has little
> > interest. :)
> 
> Hi, Shane:
> 
> Given BCP 188 ("Pervasive Monitoring Is a Widespread Attack on Privacy"
> and "The IETF Will Work to Mitigate Pervasive Monitoring"), I'm a bit
> disappointed that "HTTPS" is spelled "HTTP(S)" in your document :-) If
> you're going to go to the trouble of defining a new transport for DNS,
> what's the rationale for allowing the transport to permit plaintext?

as the author of the first prototype, let me say that the client side proxy's only knowledge of 
its server side proxy is its IP address, whereas SSL needs a host name. i'd be happy to have all 
that specified by people who understand it, alone with client-side certs and server-side SSL 
ACL's. but i'll still likely use raw HTTP in some situations, so that should also be specified, even 
if explicitly discommended by the final published document.

-- 
P. Vixie