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