[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.