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.
- [dispatch] Working Group Proposal: DNS Over HTTPS Paul Hoffman
- Re: [dispatch] Working Group Proposal: DNS Over H… John Levine
- Re: [dispatch] Working Group Proposal: DNS Over H… Stephen Farrell
- Re: [dispatch] Working Group Proposal: DNS Over H… Mark Nottingham
- Re: [dispatch] Working Group Proposal: DNS Over H… Adam Roach
- Re: [dispatch] Working Group Proposal: DNS Over H… John R Levine
- Re: [dispatch] Working Group Proposal: DNS Over H… Stephen Farrell
- Re: [dispatch] Working Group Proposal: DNS Over H… John R Levine
- Re: [dispatch] Working Group Proposal: DNS Over H… Ben Schwartz
- Re: [dispatch] Working Group Proposal: DNS Over H… Martin J. Dürst
- Re: [dispatch] Working Group Proposal: DNS Over H… Martin Thomson
- Re: [dispatch] Working Group Proposal: DNS Over H… Patrick McManus