Re: [Doh] Talking to my resolver

"Martin Thomson" <mt@lowentropy.net> Mon, 18 March 2019 02:11 UTC

Return-Path: <mt@lowentropy.net>
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 3E896131217 for <doh@ietfa.amsl.com>; Sun, 17 Mar 2019 19:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=OnDl9fmp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ELs6TLc/
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 TlKJFBGo0Y-f for <doh@ietfa.amsl.com>; Sun, 17 Mar 2019 19:11:18 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33ACE127967 for <doh@ietf.org>; Sun, 17 Mar 2019 19:11:18 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 53B792174F for <doh@ietf.org>; Sun, 17 Mar 2019 22:11:17 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 17 Mar 2019 22:11:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=FoJ7LiPlBZMY0gIXJ741NA9HxjDFPJU h9sv6N8MsKVg=; b=OnDl9fmp4/YkaQy1L3h3J7r6TMHBtdzGASkMEfGjpWch4H5 sqrTiPmmj1FNkitIyR1i1bJUF5thER3afP5s7PT6NUWPswrgZSArFfcy+AlQx0ZX P5UwcEMyrWzL6vRYzAph5G0SZc2pdKkyyQ8c7r1MR4rBbhICVZmaq5JDHxqMW366 9AH4CnF71jtq7eAWo/x1qmoeOGMPH0FDVUTsD/PzUfPvCKGdUBZuKakJI5PYwdC2 RdcLUEgQlSzcE/eF9V2PcFA85T+o0iXpl/l8oj+dcz5cgPOI5u0uqyxdYbmwkFXL UQnXUZmvlHojXXEWJBKHoAKAQlnYpx0n1jF/bmA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=FoJ7Li PlBZMY0gIXJ741NA9HxjDFPJUh9sv6N8MsKVg=; b=ELs6TLc/p3EZ88a38tgpmq LoxKuDvyDu+PFo5PcpjmrCyOeEapwULJdA/0pQYYGDnTJOzHmGlBmPwP3YUrecaB WOclV2tyUPEOOmaDaoe5yQdwi960pg8UQ8TPe7jsM+LGj8inBWm9mUeeTfZBU/hK NDSQ1CHm9tfwBIZ2WIq3MvfcmMjOUlQBwOXxpbljLWMwmQgyxYuIPKucCH4XcdmV j6sK2I9FbLIH1yNYcVfJbDT039cF7SZjEYAbDEVJNa82AdQn1W5RSkyDrmrsrbyH Lamn9aHFIdm3pLiHnw4ONyajUhsuhunnGPTa/LP7YFiiONsMwvxsFqcL9z6Yvucw ==
X-ME-Sender: <xms:Rf6OXMNs6oeejazLY2fO0Nrj8G4RDqp4U8KeDrl4BP8cDYTjORYOUw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddriedtgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:Rf6OXNJ_McrNUYgqGTiHUAhgI_sw4TUi3Y2je5hpdW76J02sAl9hwA> <xmx:Rf6OXH42ZAq9JLESolUtG8_gy6od_J3a650NBwcSwz5oAPB8gmM58w> <xmx:Rf6OXFTwJfu4p1Y4oluHTBfSpBz-kMugeBb64D5sHK47q73kODdrHg> <xmx:Rf6OXH5polpsk8NmuF1MqcqoP0qJWEiok_whX8MP8BIWLyTdW47x7w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0D39F7C651; Sun, 17 Mar 2019 22:11:17 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <bc485de8-0fa9-44a9-96ff-2a694e45f7b3@www.fastmail.com>
In-Reply-To: <4de48a75-955d-89e3-7da3-4a1876edc53a@riseup.net>
References: <CAHbrMsCNyeabhk0sVexOHVedVkgG2dvV9T8wWL++om5juAUvEw@mail.gmail.com> <b3c252eb-f8de-42f7-bedd-ef23375b5325@www.fastmail.com> <4de48a75-955d-89e3-7da3-4a1876edc53a@riseup.net>
Date: Sun, 17 Mar 2019 22:10:41 -0400
From: Martin Thomson <mt@lowentropy.net>
To: doh@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Gl8Ux3kF1LFm1TUOpDT7DfTnaqk>
Subject: Re: [Doh] Talking to my resolver
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Mar 2019 02:11:20 -0000

On Mon, Mar 18, 2019, at 10:52, nusenu wrote:
> The mechanism in chapter 2 (DoH Servers from HTTPS) is authenticated, 
> right?
> (but still vulnerable to downgrade attacks). If we ignore the fact that
> the resolver IP has probably been configured over an unsafe protocol in 
> the first place (DHCP).

Yeah, if we assume that the configuration is OK (a big assumption, but there are reasons we might tolerate DHCP authentication being what it is), then you are right.  The most troublesome bits are the .arpa lookups, which aren't authenticated, and can't be authenticated.  That might be considered a feature: if my home router passes the request on upstream to a resolver that supports this protocol, then that resolver gets a second chance to provide the information.  Of course, that assumes that you find unauthenticated anything a feature.  I tend to see it as a bug.

> Those that do [DoT] (Android 9 for example) don't really authenticate 
> the endpoint and use it opportunistically, right?

That is my understanding.

> > But why not provide a
> > mechanism that can do for DoT what this does for DoH? 
> 
> I'd like to see that happen as well but I assume that will not be on the DoH WG
> since it is outside it's charter?

I'd hate for our charter to cause us to disregard better solutions.

> The idea I had in mind would be to have "DoT Servers from HTTPS"
> like section 2 in this draft but without the unauthenticated options
> in section 3 and 4.
> 
> > HTTP also has a convenient mechanism for doing exactly what this
> > draft is attempting to do (almost, more later): find an alternative
> > service endpoint for the current service, [...]
> 
> How would the DoH URI be authenticated in that case?

This is a good question.  If you have any cause to believe that the server is providing valid responses, then you could take whatever it gives you.  That's arguably worse than what is in the draft now.  The way Firefox authenticated its configured DoH resolver was by providing both an IP address and a name against which the server is authenticated.  But most situations won't have a name configured.  One could be added to DHCP, and PvD too I guess, but that doesn't help the web application all that much and it might only help an operating system (or applications on platforms with an interface to DHCP options).