Re: [Doh] [Ext] Fallback to untrusted DOH servers

Mateusz Jończyk <mat.jonczyk@o2.pl> Mon, 23 April 2018 10:04 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 AA047126BF6 for <doh@ietfa.amsl.com>; Mon, 23 Apr 2018 03:04:01 -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 Z88psShMLPvB for <doh@ietfa.amsl.com>; Mon, 23 Apr 2018 03:03:59 -0700 (PDT)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 0FB3B1241F8 for <doh@ietf.org>; Mon, 23 Apr 2018 03:03:57 -0700 (PDT)
Received: (wp-smtpd smtp.tlen.pl 28702 invoked from network); 23 Apr 2018 11:37:14 +0200
Received: from alr129.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.26.47.129]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <doh@ietf.org>; 23 Apr 2018 11:37:14 +0200
To: Paul Hoffman <paul.hoffman@icann.org>, doh@ietf.org
References: <f17cbdf0-cd88-9fa9-c83d-26e2cf13b8c1@o2.pl> <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <CAOdDvNrC6VGQtCYgLOoRvwCGn0kRJuchncFj4m5r_KZ-ig7=NA@mail.gmail.com> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org>
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
Message-ID: <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl>
Date: Mon, 23 Apr 2018 11:36:46 +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
In-Reply-To: <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="hJDrJykKDiCfoG7uZDSJpy2ljp07dZV0y"
X-WP-MailID: 0d8b9f514abe5fb76772955601324b60
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 000000A [obOE]
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/fmvriluBtgAtM2KR62lPUhlpNk8>
Subject: Re: [Doh] [Ext] 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: Mon, 23 Apr 2018 10:04:01 -0000

W dniu 22.04.2018 o 17:15, Paul Hoffman pisze:
> On Apr 22, 2018, at 6:21 AM, Mateusz Jończyk <mat.jonczyk@o2.pl> wrote:
>> I think if Your interpretation of DOH is correct, that the text is unclear there
>> and should be clarified.
>> I would suggest to add the following clarification:
>>
>> 	A client MAY use an untrustworthy DNS API server as a fallback.
> 
> This seems horribly dangerous without a clear definition of "fallback".

There was a definition of "fallback" in a modification I proposed several mails
ago, but I removed it for sake of simplicity.

So, I would propose a following addition:
   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 the client
   checks whether an untrustworthy DNS API server would resolve the address in
   question).

   The client MUST use separate DNS API caches for trustworthy and untrustworthy
   DNS API servers or drop DNS caches when switching from an untrustworthy
   DNS API server to a trustworthy one.

Ted Lemon suggested in a private e-mail that contacting an untrusworthy DNS API
server after the trustworthy DNS API server returned NXDOMAIN exposes all
mistyped domains to the untrustworthy DNS API server. This is a valid concern,
and applies equally well to using old-school DNS in such a situation.

I would therefore propose to add the following warning after the phrase:
	"If a client of this protocol encounters an HTTP error after sending a
	DNS query, and then falls back to a different
	DNS retrieval mechanism, doing so can weaken the privacy and
	authenticity expected by the user of the client."

	When a DNS API server returns NXDOMAIN, a client may wish to check
	whether another server will resolve the domain name (as this may be
	a local name to be resolved by a local DNS server). Doing so will,
	however, expose all mistyped domain to that server.


> 
>> I am going to submit a draft that specifies how a fallback DNS API server could
>> be retrieved from DHCP.
> 
> That would be quite useful. If you do that, wouldn't it define the DNS API server as trusted?

No, the server retrieved via DHCP is going to an untrustworthy DNS API server
(as defined above) as DHCP is usually unauthenticated and prone to various
manipulations.

> 
> --Paul Hoffman
> 

Greetings,
Mateusz Jończyk