Re: [Doh] Clarification for a newbie DoH implementor

Ben Schwartz <bemasc@google.com> Sun, 09 June 2019 17:04 UTC

Return-Path: <bemasc@google.com>
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 80F281200D7 for <doh@ietfa.amsl.com>; Sun, 9 Jun 2019 10:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level:
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 NhS6hDVtlWyt for <doh@ietfa.amsl.com>; Sun, 9 Jun 2019 10:04:36 -0700 (PDT)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D081200B7 for <doh@ietf.org>; Sun, 9 Jun 2019 10:04:35 -0700 (PDT)
Received: by mail-vk1-xa36.google.com with SMTP id v69so1246325vke.0 for <doh@ietf.org>; Sun, 09 Jun 2019 10:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2CB92dfXye+PCdtbLoey4MOIgYWfWJ2/HEzw+1VJfI8=; b=XMWjs7oDN5btOcaJ48/z5GxdUbN3LHZaQsdM8TUsqQdMwSnfE9YKrpX2oAM6Cc08jo NdmS6w4Jz+lTkte1qFUhyF5y3+i24KFaUfFkxnJd+FOOgeADVlxKa48M81sETwV7Q8ev CtbJht3zrBoy3s3uZqdEFgOxcx02JAVWeSnZmHO5f6FwnLcieHuWc49eUbT1+iEef37h bQsCdt5u5+idY2wTCqMfpIWs/RUQ4rPmSPhz3A15TOaZV5iM8UhaxETHpVaBDzCKVyVK WzA+6Kc6WwPTDIUFVY0rdZw848J2z16o2+AMFo4jQl7YhH+66utT/PH4gkcyzZMrz97L oYTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2CB92dfXye+PCdtbLoey4MOIgYWfWJ2/HEzw+1VJfI8=; b=kBcYCHoIO/SiI96L0v3VUlhBIyzh4Plt+QxXGB5kYLUXeFTAqaS5saPIPrm9GBpMQh 5e7HYEprjKBeBR+HXQizyo5J++bIbC/5ROcyJG8nIQ7BTas+lTCn3EM+IVUASbJ59uPz OlcamO/OwgSL7Zhg8rJuxz3Gjab/FvlzlRdoBIpRtgtNVdYK6pVra/vzVixkLAoCq2zS VC7dHLl2zHtNDsaTohqajr23LiSxl5wZ1BHmKmJnxp5g1ciTuzTrQoyrsQW70bVKtm9M ec8GXUPZUjARQkLZ+tKAOjofvoVf21wg3DD+/LxQUG2chhE2T1MMHmpXW0jjbnXWgxJH xPtg==
X-Gm-Message-State: APjAAAXI741sZSkpNTiIvIEfN+ISHCqYgQWknIsgxgyGnX7veCsbhwMX BEsLSDoBeifYFLvyezmqqkhxwtgEBX7Qp/UzWPlsM0nD0G8=
X-Google-Smtp-Source: APXvYqyUVJTOal0Olu8tO2Wfh3PoAG6HOXLI3VleZCb4KS/bWo/aGDh8UU0mu+ZZe7pCPRhkRT06f7zbZZMS+3XnQwM=
X-Received: by 2002:a1f:ccc4:: with SMTP id c187mr23679234vkg.56.1560099874222; Sun, 09 Jun 2019 10:04:34 -0700 (PDT)
MIME-Version: 1.0
References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <CAHbrMsCMWtzHXZvpodak59RtAkSQC_ZM03oekKj00WqzNkDaaA@mail.gmail.com> <20190519055255.45717.qmail@f3-external.bushwire.net> <CAHbrMsC-1OQnoaYFE5BO8UzDsebo7jhJBfc9F4J-zgeA2FZm7Q@mail.gmail.com> <20190609083724.23965.qmail@f3-external.bushwire.net>
In-Reply-To: <20190609083724.23965.qmail@f3-external.bushwire.net>
From: Ben Schwartz <bemasc@google.com>
Date: Sun, 09 Jun 2019 13:04:22 -0400
Message-ID: <CAHbrMsD5ioLvC9RXp6sGtjg-K-wfU3hk69dMFcDVy8WQoWYvCg@mail.gmail.com>
To: Mark Delany <d5e@xray.emu.st>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000d9b63e058ae70eac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/6egz90b-kuQf3YvuOMnuLg6Wq08>
Subject: Re: [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: Sun, 09 Jun 2019 17:04:40 -0000

On Sun, Jun 9, 2019, 4:37 AM Mark Delany <d5e@xray.emu.st> wrote:

> On 19May19, Ben Schwartz allegedly wrote:
>
> > In practice, none of this seems to be a problem.  DoH servers simply do
> > their best to fully answer the query
>
> I know this is getting close to flogging a dead horse, but I'm still
> troubled by
> the silent truncation implied by a DoH Server processing TC=1.
>
> Notwithstanding clients which directly connect to DoH servers (such as some
> browsers) the typical scenario is likely to be existing stub clients using
> UDP
> to talk to a DoH proxy/client which in turn talks to a DoH server, i.e.:
>
>  stub (UDP) ->        DoH proxy (HTTPS) -> DoH server (UDP) -> resolver
>  stub (UDP) <-        DoH proxy (HTTPS) <- DoH server (UDP) <- resolver
>
> (Sorry, you'll need to render this in a fixed-width font).
>
> As I understand Ben's response, if the resolver returns TC=1 then a
> typical DoH
> server (or its resolver library) will retry with TCP which makes the flow
> for a
> large response actually look like:
>
>  stub (UDP) ->        DoH proxy (HTTPS) -> DoH server (UDP) -> resolver
>                                            DoH server (UDP) <- (TC=1)
> resolver
>                                            DoH server (TCP) -> resolver
>  stub (UDP) <- (TC=0) DoH proxy (HTTPS) <- DoH server (TCP) <- (TC=0)
> resolver
>
> Which certainly meets the "do their best to fully answer the query" as the
> stub
> never has to worry about TC=1 and simply gets the "full result".
>
> However... It makes me wonder how a large TCP response the DoH Server
> sends back
> via HTTPS can possibly fit into the response the DoH proxy sends back via
> UDP to
> the stub.
>
> Let's say the DoH proxy receives a 5K response over HTTPS, does it blindly
> try
> and transmit this 5K response over UDP back to the stub and just hope for
> the
> best? Or should it know this is likely to fail and act accordingly? If so,
> how
> should it act?
>
> I can't think of what a DoH proxy can sensibly do in such circumstances
> apart
> from arbitrarily truncate the response down to the UDP size indicated by
> the
> stub and *not* mark the response with TC=1.


I don't understand your logic.  From my perspective, the obvious thing for
this proxy to do is to truncate the response, and set TC=1 if truncation
occurred.  Truncating without setting TC=1 seems like a violation of the
DNS protocol.

Thus the stub loses some of the
> answer and more importantly loses knowledge of the truncation. That seems
> bad to
> me.
>
> As we've discussed previously, it's pointless returning TC=1 to the stub
> as it
> will simply re-issue an identical query as far as the DoH server is
> concerned.
>
> Note that I said "identical query as far as the DoH server is concerned".
> The
> same is not the case for the DoH proxy as the query re-issued from the stub
> *can* be disambiguated since the stub connects to the proxy via TCP.
>

Indeed.  It seems obvious to me that the proxy will not truncate the
response to a query that arrived over TCP, since truncation is not required
for DNS-over-TCP, and therefore the full query will succeed from the stub's
perspective.  To summarize, a proxy that does the simplest thing to comply
with DNS and DoH RFCs will correctly deliver full responses to the stub
without requiring any changes to either protocol.

Which offers a possible solution.
>
> Since a proxy knows whether the inbound query has come via UDP or TCP it
> can
> annotate the HTTPS request accordingly (let's invent a "Use-TCP"
> header). The DoH server acts on this header thus the flow becomes:
>
>  stub (UDP) ->        DoH proxy (HTTPS)           -> DoH server (UDP) ->
> resolver
>  stub (UDP) <- (TC=1) DoH proxy (HTTPS)           <- DoH server (UDP) <-
> (TC=1) resolver
>  stub (TCP) ->        DoH proxy (HTTPS - Use-TCP) -> DoH server (TCP) ->
> resolver
>  stub (TCP) <- (TC=0) DoH proxy (HTTPS)           <- DoH server (TCP) <-
> (TC=0) resolver
>
> IOWs TC=1 is sent all the way back to the stub for it to deal with. If the
> stub
> re-queries with TCP, the proxy forwards the query with the "Use-TCP"
> annotation
> to the DoH server which in turn instructs its resolver library to use TCP.
>
> Not only does this alleviate a DoH server from trying their best to "fully
> answer the query" in the blind, it also avoids the impossibility of
> transmitting
> a large response back to the stub over UDP. Most importantly truncation is
> no
> longer silently performed - rather it is communicated back to the stub
> which
> lets it decide what to do as has traditionally been the case.
>
> I think all stubs should work in this "Use-TCP" scenario whereas clearly
> they
> cannot in the "DoH server transparently handles TC=1" scenario.
>
> The one down-side is that a TC=1 response incurs higher latency due to the
> flow
> going all the way back to the stub for a retry, however given these TC=1
> responses are uncommon, that seems like a minor price to pay for a
> consistent
> outcome.
>
>
> Mark.
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>