Re: [Doh] Clarification for a newbie DoH implementor

"Mark Delany" <d5e@xray.emu.st> Fri, 19 April 2019 00:25 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 0D4211200CD for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 17:25:35 -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 arXFa5bbqOTx for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 17:25:33 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8624512004C for <doh@ietf.org>; Thu, 18 Apr 2019 17:25:33 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 20F983B01C; Fri, 19 Apr 2019 10:25:30 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1555633530; bh=XwNByD05N2rhkVfRsxLs3Nk1BIU=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=U0TENPxERP0hf0zuzUH3KMPcJZ0eh5HTkePSyt1nJoml7Gx9hCGtAMwcbATaNRBjS qIzGNHizN5UdtT3G79XuMsRl51UaaDsGxy80biUxdaPvNXz8lf4WPS5F/Y2J+awU3u iPDnuqBsyBpEuVQcuF7jupJ5uaobwUqSqnHep+KQ=ep+KQ=
Comments: QMDA 0.3a
Received: (qmail 72953 invoked by uid 1001); 19 Apr 2019 00:25:30 -0000
Date: Fri, 19 Apr 2019 00:25:30 +0000
Message-ID: <20190419002530.72952.qmail@f3-external.bushwire.net>
From: Mark Delany <d5e@xray.emu.st>
To: doh@ietf.org
References: <20190418071238.68406.qmail@f3-external.bushwire.net> <0e241cc8-dd4c-f93d-92b6-83dd62791bc4@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <0e241cc8-dd4c-f93d-92b6-83dd62791bc4@nic.cz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/W3_8wrdnD6lfPZxQNO6aqszYWT8>
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: Fri, 19 Apr 2019 00:25:35 -0000

On 18Apr19, Vladim??r ??un??t allegedly wrote:
> Hello!
> Reactions to particular parts inline.?? I omitted those where I can't say
> too much.

Thanks.

> The RFC only bounds to minimum TTL *in answer section*, but I believe
> that's a mistake as you can't just ignore authority section at least.??

I agree, particularly as an "Age" response might come from a caching
HTTP server which is oblivious to the payload. Since "Age" is saying
the whole payload has aged thus it should logically apply to all TTLs
inside.

> I'm not so sure about this, but my point of view is, shortly, that
> padding is a per-hop thing.?? It depends on the particular transport

Yeah. I guess the thing is that a DNS message didn't typically
traverse multiple hops until DoH came along so the question never
arose. As you well know, most often a message triggers new messages
rather than being forwarding directly. But I agree that padding seems
like a per-hop/per-transport value.

As it turns out I don't think a DoH proxy has to care about
pre-existing padding as it should be able to arbitrarily add a second
padding to the message to meet the modulo size requirements. Is there
anything that says two paddings options in one message are illegal? It
might be more efficient to replace the existing padding, but RFC7830
is silent on the matter of multiple occurrences.

  (It's also interesting that padding has been placed inside the DNS
  message as opposed to something appended to the HTTP payload. Both
  work just as well to mitigate the traffic analysis risk. However
  this in-message approach forces a proxy implementation to
  disassemble and reassemble the message and thus have a fairly full
  understanding of the DNS message structure rather than just append a
  blob of zeros to a blob of HTTP payload. That's a lot of extra
  complexity to add a few zero bytes. Oh well, that ship has well and
  truly sailed!)


> > For now the implementation doesn't add DNS padding for GET requests. Should I
> > change that?
> 
> That's certainly about base64url padding.?? It could get clarified in the
> RFC, but I suspect most people don't get to reading errata or
> "corrected" RFC versions.

Or the original RFCs for that matter :-)

In retrospect I think GET should have padding as it mitigates the same
risks as POST but it also might reduce cacheability if some proxys pad
and others don't... And the RFC authors did worried a bit about HTTP
cacheability as witness by the zero ID for GET rule. All in all tho,
since GET is discouraged it's unlikely to be a big deal.


Thanks again for your responses.


Mark.