Re: [Doh] WG Review: DNS Over HTTPS (doh)

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 21 September 2017 12:12 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD9C132055; Thu, 21 Sep 2017 05:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9U5DsOLsZMDo; Thu, 21 Sep 2017 05:12:22 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5A9132949; Thu, 21 Sep 2017 05:12:20 -0700 (PDT)
X-AuditID: c1b4fb3a-9e1d49c0000051a3-e4-59c3aca282a7
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5C.B2.20899.2ACA3C95; Thu, 21 Sep 2017 14:12:18 +0200 (CEST)
Received: from [147.214.163.22] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 21 Sep 2017 14:12:17 +0200
To: <ietf@ietf.org>
CC: <doh@ietf.org>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <86d3aee8-57bf-5baf-2fda-0849b3ba35f2@ericsson.com>
Date: Thu, 21 Sep 2017 14:12:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010602090608030402090603"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdVHfRmsORBl/mKFpcu3uRzeLZxvks DkweS5b8ZApgjOKySUnNySxLLdK3S+DK2HdxL1vBF8+KbT9PMjcwnnbuYuTkkBAwkVi/tI2t i5GLQ0jgCKPEjD3NUM5mRokbvY3sIFXCAjoSjx4/YgWxRQSEJY48+gcWZxYQkti2aDMjiC0k 4Cux/MEXJhCbTcBC4uaPRjYQm1fAXuLHpFlgNouAqsSstxfAakQFYiR+XnrEAlEjKHFy5hMw m1PAT2Jt10+wI5gFuhkljvVMYoVYoC3R0NTBCnG2ksT1eddZJjAKzELSPwtZzyywA80k5m1+ yAxha0ssW/gayhaXaPqyEqrGWmLGr4NsELaixJTuh+wQtqnE66MfGSFsI4l3exrZFzByrmIU LU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjJGDW35b7WA8+NzxEKMAB6MSD+/dqMORQqyJZcWV uYcYVYDmPNqw+gKjFEtefl6qkgjv2RqgNG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATS E0tSs1NTC1KLYLJMHJxSDYzmjTMflf1l7vvW/aAq/FtweGUc8873JrUfd8RLbvgfa/nO4GrK ecPObR7/tC3L92XMOVh6sXSxx8xdWcxLhK0sG9qLmziO/c/apvW9KuYZv/y347odAa0iZvq5 AfPnhnHnq+inlMc2GLnfLTr1aZEKs8gZpaOm9xWWdtSFtKvbyduEfv2yTImlOCPRUIu5qDgR AM46D3yZAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Z9cyFFGi9gSEVDPMvzjqLa6pHi8>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 12:12:28 -0000

Hi,

The issue with this charter I have is that unless you specify one or 
several usages one can't evaluate or write security considerations or 
even discuss the actual security properties of the resulting component. 
Or rather the statement you can do is very limited. And I think the 
below quote from the charter is quite misleading, even if accurate.


Den 2017-09-15 kl. 17:44, skrev The IESG:
> The use of HTTPS
> provides integrity and confidentiality, and it also allows the transport to
> interoperate with common HTTPS infrastructure and policy.

So, yes HTTPS will provide two properties. The DNS data provided are 
from the "entity" given by Server's cert, and it is provided 
confidentiality and integrity protected between that server and my 
client. However, without discussing a particular usage of this format, 
the system security properties and especially what trust I can place in 
the data as well as what privacy that is provided is unknown.

Just to show how strange this can be lets compare two different usages 
with quite different properties are present.

1. After having connected to a web site, the web application uses its 
own servers to resolve the DNS information for resources the client side 
application needs by submitting those resolve requests to the same 
origin server. In this case we keep the usage within the same trust 
domain. The distributed web application uses the mechanism internally 
with resolvers that it is configured to be trusted. Each web service has 
its own resolver and the DNS resolution is internal and separated 
between applications.

2. Using some autoconf setting, the free WIFI access point at Joe's 
Coffe announces a DNS over HTTPS stub resolver. The only difference from 
current DHCP DNS server setting is that the communication between the 
client and resolver at the gateway is that communication is secured, 
thus preventing active and passive attacks from other entities in the 
same WIFI/LAN. But otherwise the trust possible in responses from the 
resolver has not changed. Nor has the privacy aspects in respect to the 
infrastructure and what happens upstream of the LAN gateway.

I am quite worried that by simply defining a format and not discuss how 
it will be used, people will lock on to those three words from the 
charter: "integrity and confidentiality" and think this resolves everything.

Also which "old" use cases that is really intended to cover and by which 
entities are really not clear. As "new use cases" are ruled out of 
scope. So, is the browser contacting an recursive resolver without going 
through OS a new or an OLD use case?

I really want more clarity on what the WG really should do as its first 
steps and what usage considerations it needs to write!

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------