[Doh] Fallback to untrusted DOH servers

Mateusz Jończyk <mat.jonczyk@o2.pl> Sat, 14 April 2018 16:37 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 AFF1D126CC7 for <doh@ietfa.amsl.com>; Sat, 14 Apr 2018 09:37:12 -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 Pw5pEW9YgEl7 for <doh@ietfa.amsl.com>; Sat, 14 Apr 2018 09:37:10 -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 9CEE41241F5 for <doh@ietf.org>; Sat, 14 Apr 2018 09:37:09 -0700 (PDT)
Received: (wp-smtpd smtp.tlen.pl 4995 invoked from network); 14 Apr 2018 18:37:06 +0200
Received: from agsm209.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.90.209]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <doh@ietf.org>; 14 Apr 2018 18:37:06 +0200
From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <mat.jonczyk@o2.pl>
To: doh@ietf.org
Message-ID: <f17cbdf0-cd88-9fa9-c83d-26e2cf13b8c1@o2.pl>
Date: Sat, 14 Apr 2018 18:36:58 +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="pHAqOQ5kFFj8jLRjzraRjyPklXo0hOiN6"
X-WP-MailID: d0fc87a98c4c0189a7cd73ecfcc422be
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000000 [EaNE]
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/rP1qDQD2QdPiORpV0zKQ8s6PZEw>
Subject: [Doh] Fallback to untrusted DOH servers
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: Sat, 14 Apr 2018 16:37:13 -0000

Hello,
Current DOH draft specifies that:

   A client MUST
   NOT trust a DNS API server simply because it was discovered, or
   because the client was told to trust the DNS API server by an
   untrusted party.  Instead, a client MUST only trust DNS API server
   that is configured as trustworthy.

It may happen that either no trustworthy DOH server has been configured, or the
configured DOH server is not working. In such cases a DOH client would usually
revert to using an untrusted DNS server on port 53, possibly one that was
discovered through unsecure DHCP. This DNS resolver would also be able to poison
DNS caches then.

I think that in this case it would be better to use whatever DOH server is
available as an alternative to an even worse old-school DNS. To avoid cache
poisoning attacks, the client would then have to drop DNS caches after switching
to a more trustworthy DNS once it has been configured or is available.


Also, the current draft does not specify any way of querying IP addresses of
hosts on the local network - it is assumed that if a DNS API server would return
NXDOMAIN the client would query the local old-school DNS server whether the
hostname translates to an IP address on a local network. In the future, there
may be specified a discovery mechanism for a local fallback DOH server, for
example by a DHCP option.

A client would have to drop DNS caches when switching networks anyway to avoid
any stale entries related to local hosts.

Therefore, I would propose the following text:

   A client SHOULD
   NOT trust a DNS API server simply because it was discovered, or
   because the client was told to trust the DNS API server by an
   untrusted party.  Instead, a client SHOULD only trust a DNS API server
   that is configured as trustworthy. A client MAY use an untrustworthy
   DNS API server as a fallback, for example: when no trustworthy DNS API
   server is configured, no configured DNS server works or
   when the trustworthy DNS API server returned NXDOMAIN (and checking whether
   the hostname is a local domain).

   The client MUST drop DNS caches when switching from an untrustworthy
   DNS API server to a trustworthy one.

It should be also noted that the client should drop DNS caches when switching
from an unsecure DNS to DOH.

   "A client SHOULD drop DNS caches when switching from less secure DNS
   retrieval mechanisms to DOH."

Greetings,
Mateusz Jończyk