Re: [dnsoverhttp] [dns-privacy] draft-hoffman-dns-over-https

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 04 May 2017 07:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAFE129BAA for <dnsoverhttp@ietfa.amsl.com>; Thu, 4 May 2017 00:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 xL-Wwv_8caMY for <dnsoverhttp@ietfa.amsl.com>; Thu, 4 May 2017 00:10:35 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E11129401 for <dnsoverhttp@ietf.org>; Thu, 4 May 2017 00:10:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DC03BE2E; Thu, 4 May 2017 08:10:29 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEklkN_Fp9RE; Thu, 4 May 2017 08:10:28 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5D0CABE2C; Thu, 4 May 2017 08:10:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1493881827; bh=fyX4u4WIQeq99rJXWI6N799v2T8FgRXQ+om9/TBHhdg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=M5qBraAFZFJJ0gRd0N6DKp+ODCQRgoO3s4k7EF0PSwh/ULT088uKRpQaZw4MjcJ3M ZGao5veaAQtfRrgIqg7h7wx5kZ3KkMCYQanPJmXhCR7AdY2WQ1t2DQtw5e8ZM3ke+E V1KzD/vygoVcQ2VXvajLVQ38SZSrEbC2/5FeHsjM=
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <41EE33B8-0FB9-432C-83C7-69DE9F115BD9@vpnc.org>
Cc: dnsoverhttp@ietf.org
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <4c71400d-825e-dc64-8891-09cfd038dc5e@cs.tcd.ie>
Date: Thu, 04 May 2017 08:10:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <41EE33B8-0FB9-432C-83C7-69DE9F115BD9@vpnc.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="v1Jg8bppbfw47xSCp9E0HJbKtkxCbn7gJ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/MRMb55ugL9NEiZbom9Mc66D_VrA>
Subject: Re: [dnsoverhttp] [dns-privacy] draft-hoffman-dns-over-https
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2017 07:10:37 -0000

Hiya,

Thanks for doing this. I fully support efforts to experiment
with privacy enhancing DNS.

A query and a comment:

- Query: I wonder if it's wise to take the "it's not DNS, it's
an API to DNS" approach? Ubuntu 17.04/systemd-resolved is the
reason I'm asking, as that's now an irritant for me (until I
find the time to ditch it;-)

- I think this approach (and maybe others) has a missing
security consideration, that could be telling were this widely
deployed. IIUC, the same server here can, and is fairly likely
to, offer both DNS and the web over HTTPS. That has some nice
features, but also a downside - such a server is in a position
to choose which DNS entries it forces the client to resolve
and to also answer those queries. A client that then used
those DNS answers in another context (e.g. on another browser
tab, or cached OS-wide) could have bed consequences as it's
fairly easy to convince a browser to navigate to some bad
actor's web site and if that same bad actor could then poison
my DNS cache for any domain of it's choosing, then that is
a real worry. So I wonder if there needs to be some scoping
on the re-use of (non-DNSSEC) answers delivered via this
mechanism.

Cheers,
S.



On 04/05/17 04:36, Paul Hoffman wrote:
> This has a similar filename and title as previous drafts, but we started
> a -00 because the content is different. The discussion should probably
> happen on the https://www.ietf.org/mailman/listinfo/dnsoverhttp mailing
> list for now, but it is our intention to bring this to the DISPATCH WG
> because the draft is more about "foo over HTTP" (which is the purview of
> DISPATCH) than "DNS in private", even though the latter is assured by
> the protocol.
> 
> --Paul Hoffman
> 
> Name:           draft-hoffman-dns-over-https
> Revision:       00
> Title:          DNS Queries over HTTPS
> Document date:  2017-05-03
> Group:          Individual Submission
> Pages:          10
> URL:           
> https://www.ietf.org/internet-drafts/draft-hoffman-dns-over-https-00.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/
> Htmlized:       https://tools.ietf.org/html/draft-hoffman-dns-over-https-00
> Htmlized:      
> https://datatracker.ietf.org/doc/html/draft-hoffman-dns-over-https-00
> 
> 
> Abstract:
>    DNS queries sometimes experience problems with end to end
>    connectivity at times and places where HTTPS flows freely.
> 
>    HTTPS provides the most practical mechanism for reliable end to end
>    communication.  Its use of TLS provides integrity and confidentiality
>    guarantees and its use of HTTP allows it to interoperate with
>    proxies, firewalls, and authentication systems where required for
>    transit.
> 
>    This document describes how to run DNS service over HTTP using
>    https:// URIs.
> 
>    [ This paragraph is to be removed when this document is published as
>    an RFC ] Comments on this draft can be sent to the DNS over HTTP
>    mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp .
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>