[Doh] DNS API server trust

Mateusz Jończyk <mat.jonczyk@o2.pl> Fri, 11 May 2018 09:47 UTC

Return-Path: <mat.jonczyk@o2.pl>
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 E6549127078 for <doh@ietfa.amsl.com>; Fri, 11 May 2018 02:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 nnMuFIF9xmEm for <doh@ietfa.amsl.com>; Fri, 11 May 2018 02:47:36 -0700 (PDT)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 E2EC312711E for <doh@ietf.org>; Fri, 11 May 2018 02:47:34 -0700 (PDT)
Received: (wp-smtpd smtp.tlen.pl 33262 invoked from network); 11 May 2018 11:47:30 +0200
Received: from agkb104.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.129.104]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <doh@ietf.org>; 11 May 2018 11:47:30 +0200
To: DoH WG <doh@ietf.org>
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
Openpgp: preference=signencrypt
Message-ID: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl>
Date: Fri, 11 May 2018 11:47:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="KVd6m164uDNsagzP8Qdqjs29LkqttxVpv"
X-WP-MailID: 097579f3655e894f329267d2fe1f6d3f
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000001 [QSLC]
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/7oA6xrVVYIdtSp6DF6OAJzdwAqw>
Subject: [Doh] DNS API server trust
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: Fri, 11 May 2018 09:47:40 -0000

Hello,
There was an interesting discussion on a Github pull request
	https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174

It was discussed whether there should be an absolute requirement which servers
the client can use, i.e. the following text:

	In the absence of DNSSEC information about the authenticity of responses
	a DNS API server can give a client invalid data in responses. A client
	MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use
	DNS API servers specified using mechanisms such as explicit
	configuration. This does not guarantee protection against invalid data
	but reduces the risk.

User roryhewitt opposed this wording, He or She argued that usage of MUST is
unsuitable as it is used here to describe policy, not a mechanism.

I would side with His / Her. The concern is merely theoretical at the time being
as there is currently no other way to obtain a DNS API server other then manual
configuration (the usage of DNS responses obtained by server push is dealt
earlier in the specification). I would claim that concerns "that DOH clients
will spray queries to random webservers, or otherwise violate security common
sense." (as Benjamin M. Schwartz put it) are unfounded.

The policy should probably be defined after DNS API server discovery will be
standarized.

At the very least, I would lower the requirement from MUST to SHOULD here as
trust is an intricate topic.

Greetings,
Mateusz Jończyk