Re: [dispatch] Working Group Proposal: DNS Over HTTPS

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 10 August 2017 16:22 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD53132331 for <dispatch@ietfa.amsl.com>; Thu, 10 Aug 2017 09:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, 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 L6TmNr0pyzn0 for <dispatch@ietfa.amsl.com>; Thu, 10 Aug 2017 09:22:49 -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 3347113239E for <dispatch@ietf.org>; Thu, 10 Aug 2017 09:22:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B47ACBE2F; Thu, 10 Aug 2017 17:22:45 +0100 (IST)
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 wHfd5D9MsAh1; Thu, 10 Aug 2017 17:22:45 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 792FDBE24; Thu, 10 Aug 2017 17:22:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1502382165; bh=ZZj0qRop/RhcDNN7MNj+8Nduwgww8NtMrdlePA0cRTU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HkIbhxJbDh1SrAZ+Ie5mRSvBMUmcWaVpvk2JCgG/okptTRcqqNQVPjCtat3fC+jbN WeTAmPTVZAzVDFjqPFXlPK6+vArLkU6+w4lIPR4KE1V5TGkLQi825GR/WQOQtxWyT/ iGYIY1CVlUGpmQU+Vvy8w27pQVXcvx6t0BjFC0VQ=
To: John Levine <johnl@taugh.com>, dispatch@ietf.org
Cc: paul.hoffman@icann.org
References: <20170810160035.9804.qmail@ary.lan>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie>
Date: Thu, 10 Aug 2017 17:22:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170810160035.9804.qmail@ary.lan>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="xPaWBEVf7cVBShx6KpuaAV9pCR2sPxrDN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/7ZE_1S04sceOMSEaB91PAKoHZ4w>
Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2017 16:22:51 -0000

I'm not against this, pretty much for it in fact, but...

On 10/08/17 17:00, John Levine wrote:
> 
> Someone asked what if the https server lies?  DNS caches have always
> lied, that's nothing new.  If you don't trust it, you have DNSSEC.

Changing the liar can be significant. If this is used with
some dedicated https server that only does dns and nothing
else, and the URL for that is configured into a dns/https
client, that's probably no big change vs. speaking the dns
protocol with a resolver.

If however, a random web site were to be able to get a http
client like a browser to believe lies about dns then that'd
be much worse than today, if those lies affect more than the
web pages that the fibbing web site can control anyway.

That's ack'd in the last para of the security considerations
but I suspect more will be needed there, first to analyse
possible bad behaviours and then to figure out what to say
about those. (I'd be surprised if that were doable by the
end of the year, but since ietf milestone date fiction
deserves it's own aisle in a bookstore, that's ok:-)

As an aside, I'm puzzled a bit by how CORS comes into this.

S.