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

Martin Thomson <martin.thomson@gmail.com> Tue, 12 September 2017 00:28 UTC

Return-Path: <martin.thomson@gmail.com>
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 C2DE4132EBF for <dispatch@ietfa.amsl.com>; Mon, 11 Sep 2017 17:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZDP1K5OyjEHM for <dispatch@ietfa.amsl.com>; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D55129C41 for <dispatch@ietf.org>; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id j141so37137383ioj.4 for <dispatch@ietf.org>; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0rIzntf3nTtFZVrCXlZmDUijVFO5ME0MleVpzgGfpdo=; b=TE52rm77wbFgb1fTgkxoiBuVUu1s9sj1kZaqZRso28zkGSuQ8zi8cBasW5pE89qy+u /ZninRT2aQrIMsvdUbFp3DSDI+9Vl4phkSSd9K9brVL81aPN589R5NVASB3hYdYPPsrb CTVWGnsSAYbecDMJe4P7n6otcdLshq/zkmy3tVox79vEIkJyCn6KFeaSyXgrwz4iJ5lY Mw2xkS9dGuuSg3d6rhWvqGHPmWS1Nk/jUuP41feFTd0UzmUjcNxakxjkshBif4psm5ol 2KlKQWdoo5J8kEr+sty8eoKcC8XbCmmcFU55L/PQjyoGyDsrz9ZMzht2dnKUiFjpbg7u d/pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0rIzntf3nTtFZVrCXlZmDUijVFO5ME0MleVpzgGfpdo=; b=H03U9SKigAjVJ/rYhL2EWaQ5CF6a05LbMwaqc+5+/JvMScio03ZMm+9YZ1qNGXpIxe md9ScYglN/oB3GFq5YC8LdNKnZ3VZXiU8jq5f2Ijw7jd2SvpsMwGilvFveLS9oR3M0Ov wjcOWlX/uN4uxL5suLIc708df/u73xQ+NelanD3TODTRv/ScbGZdVPSfmuRCCl35Ej1W wnfbJ5H8wWt/cBejPj6BHW9Rlks/pveaIzXCOrlpUadurgL2vHuKvnBbboy0QEPF5xgx i7KMk8htXaVjtHvMPpKJMY2wycwFSBC8D07pBnuGsonBhKSyQhVnczRxJY/DeUSduIFQ uHCw==
X-Gm-Message-State: AHPjjUjBhIQH90xZji1/CyJxKG/YXmI0vtiyUeLpeTXi6HFTiGllj1+7 MtLb8pKvqXkyn16E5DvZQP61evWrOCmk
X-Google-Smtp-Source: AOwi7QB1DJV35/GfPppfuwcBjORvJzeFKqtZ8ZfGeWnr2FIzw4M5R3GJ6i3BnTQoiiB+exsNxBoeIu5uwQjwrX5qJu0=
X-Received: by 10.202.170.204 with SMTP id t195mr252232oie.277.1505176116007; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.14.77 with HTTP; Mon, 11 Sep 2017 17:28:35 -0700 (PDT)
In-Reply-To: <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie>
References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> <alpine.OSX.2.21.1708101427390.37126@ary.qy> <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 12 Sep 2017 10:28:35 +1000
Message-ID: <CABkgnnWhbW9DDfEswKTQ-+_BRewnw2RGYWOKtVac=zMCTmqODw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: John R Levine <johnl@taugh.com>, Dispatch WG <dispatch@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/0ZmU7MmN_ADb_pseJnPfjkyFjGQ>
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: Tue, 12 Sep 2017 00:28:39 -0000

On Fri, Aug 11, 2017 at 5:40 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>> CORS?
>
> Yes. The mention of that in the draft we're discussing is
> a bit of a puzzle to me. Hopefully you didn't read some
> other draft:-)

Let me try to clarify, though I might easily do the opposite.

tl;dr: I think that the draft doesn't need to concern itself with CORS.

CORS *is* relevant in the space of things that this is touching.  One
specific (and useful) outcome of this work is that it allows web
applications to make DNS queries.  That naturally raises the CORS
question.  However, the answer is not any different to any other thing
that we might put on HTTP(S).  The server needs to adopt a policy that
ensures that the data that it provides is not made available to those
that shouldn't have it, and that any actions it takes are properly
safeguarded.  This is still not extraordinary in any way.

The draft in question uses GET.  That means that web content will be
able to make queries without any special controls, but it won't be
able to read the response.  The DNS server can block the request from
certain network locations, but it has to specifically look for an
Origin header field.  Again, this isn't particularly special, though
there are some denial of service considerations we might add to a
draft for this case.

The draft also uses POST, which triggers CORS preflights.  These
requests check that the server is OK with receiving the POST before
sending the actual data.  Here, the default is to deny these requests.
A positive signal from the server is needed before the real request is
made.  So only servers that explicitly enable CORS will receive POST
requests from browsers.

Why is this important?  Well, the identity of your private DNS server
is not usually that private (at least not in a real cryptographic
sense).  But the content of certain responses might be.  The server
might provide responses that differ from the responses you get from
other DNS servers.  Operators of DNS servers do not necessarily want
that information out there on the web.  This might include information
about what services are active on the network, network topology and so
forth.

We might get into a whole lot more trouble if we were to - say -
provide an API that allowed web sites to make DNS queries using the
system resolver.  I keep hearing that suggested and I think that this
draft offers a much better alternative - it allows us to lean on a lot
of pre-existing work around cross-origin authentication and ensures
that DNS servers are given at least a semblance of control over who
can ask them for stuff.