[Doh] Clarification for a newbie DoH implementor
"Mark Delany" <d5e@xray.emu.st> Thu, 18 April 2019 07:12 UTC
Return-Path: <d5e@xray.emu.st>
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 2E0B61200B8 for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 00:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
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 qm_oRlzH86aq for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 00:12:42 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id E68D31200E3 for <doh@ietf.org>; Thu, 18 Apr 2019 00:12:41 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 75F1A3B01C; Thu, 18 Apr 2019 17:12:38 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1555571558; bh=9qyBvBDJ1P39cteJuExQW8nQuPI=; h=Comments:Received:Date:Message-ID:From:To:Subject:MIME-Version: Content-Type:Content-Disposition; b=ecnnYqWD3k8bTKvCSaFdzUSLmoxBHL6Arz+dtsttAbgrz0i0bx14gpquiQuNbmZCg rs5Ya6onQFGzDxdWSD9hNrtfbvGDk/KmVObuYhrFwP2rky5GXdL+eDdzm57F9CZ2Dp lVEgmaM8FubwWdpOsBtW6Ip0NKeeHyLxkYxmeqEU=meqEU=
Comments: QMDA 0.3a
Received: (qmail 68407 invoked by uid 1001); 18 Apr 2019 07:12:38 -0000
Date: Thu, 18 Apr 2019 07:12:38 +0000
Message-ID: <20190418071238.68406.qmail@f3-external.bushwire.net>
From: Mark Delany <d5e@xray.emu.st>
To: doh@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/CRLW5hwgsN-EvZ9vd9mLnNPjjw8>
Subject: [Doh] Clarification for a newbie DoH implementor
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: Thu, 18 Apr 2019 07:12:44 -0000
I'm working on a proxy/server DoH implementation designed to install on CPE and a private DoH server respectively. The development is strictly based on the RFCs without reference to any existing implementations and there are a few areas that seem ambiguous or undefined. I'm hoping to get clarity from this list. The model is: port 53 -> CPE proxy -> HTTPS -> private server -> localResolver For those familiar with CPE think of a dnsmasq replacement. The questions: ## TTL reduction due to HTTP "Age" header RFC8484 Section 5.1 advises that clients MUST account for the HTTP "Age" header by reducing TTLs. Unfortunately the RFC is silent on what to do if that reduction causes the TTL to be reduced to zero or below. Should the RR be removed which could result in an empty/odd response? Should the TTL be set to zero and let the client deal with it? This seems a risky choice as client behaviour with zero TTL is well-know to be quite unpredictable. Current behaviour is to never set the TTL lower than 1s and leave every RR in place. ## ECS Performance I've had conversations around this topic in other forums and consensus seems hard to find. Should a DoH server - when appropriately configured or signalled - add an ECS option based on the HTTPS client source IP? That seems like it would really help ECS-aware auths give much better answers than they otherwise would. Particularly as DoH servers are likely to be topologically distant from DoH clients resulting in otherwise very sub-optimal ECS answers. As best I can tell, ECS is perfectly suit to DoH but the RFC is silent on the matter. So what's the general thinking? ## ECS Privacy The converse view is that ECS is antithetical to DoH and should be avoided with extreme prejudice. If so, should a DoH implementation remove any pre-existing ECS option to protect a naive client? I know it's not particuarly likely as ECS is mostly generated by resolvers/caches rather than stubs or clients, nonetheless having a DoH implementation let a privacy-exposing option leak out seems at odds with the central tenant of DoH. ** RFC8467 DNS Padding for DoH client RFC8484 Section 9 recommends adding padding to the DNS query sent between client and server. What should a client do if the query already contains padding? Should it assume the initiator has a specific purpose in mind and not do anything or should it replace the padding to comply with RFC8484? Again unlikely, but not impossible. ** RFC8467 DNS Padding for DoH server RFC8484 is not clear about whether a DoH server should forward queries with any existing padding remaining in place or whether the padding should be removed. Arguably from a "layering" perspective if the DoH client has "pushed padding onto the stack" then the DoH server should "pop it off the stack". But the DoH server has no idea whether the padding was added by the DoH client or whether it was in the original query given to the client. The other thing to consider is that passing on padding may disclose that the query probably travelled via DoH. Is that a concern given we're trying not to disclose anything about the client? ** RFC8484 DNS Padding for GET requests My first thought is that DNS padding should apply to both GET and POST methods, but 4.1.1 says "Finally, a GET-based query ... and that padding is omitted". Is "padding omitted" referring to DNS padding or base64url padding? I presume base64url padding, but it's ambiguous. For now the implementation doesn't add DNS padding for GET requests. Should I change that? ** RFC8467 padding ambiguity with "closest multiples" and "a multiple" I've sent this to dprive but maybe it's more appropriate here. This is a truly minor nit about the precision of the text in 4.1. Nonetheless... For clients the text says pad to the "closest multiple" but for servers the text says pad to "a multiple". A literal interpretation is that servers can use a padding value which may *not* be the closest multiple, but maybe 2 or 3 or 100 multiples? My interpretation is that the intent is the same for both client and server, namely that the padding should increase the size to the next multiple up as I don't see anything else in the text that explains why larger multiples are of value. But it may be that a server is given latitude for some security or traffic analysis reason I don't understand. Is that latitude in the text on purpose and if so on what basis should a server exercise that latitude? ** A naive answer to most of these questions is that the DoH channel is merely a secure tunnel transporting a DNS blob. Leastwise I think the primordial DoH implementations worked that way. But that genie was let out of the bottle with the "Age" header modifications and DNS padding and possibly ECS. In short DoH implementations are now expected to peer into the message and mess with it. I'm new to DoH so any and all clarification and corrections appreciated. Mark.
- [Doh] Clarification for a newbie DoH implementor Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Vladimír Čunát
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Ben Schwartz
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Ben Schwartz
- Re: [Doh] Clarification for a newbie DoH implemen… Ray Bellis
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Ben Schwartz
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Tony Finch