[Doh] TSIG, Padding and "Age:"
"Mark Delany" <email@example.com> Tue, 21 May 2019 06:11 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A19212012F for <firstname.lastname@example.org>; Mon, 20 May 2019 23:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC0pb8BzWUhe for <email@example.com>; Mon, 20 May 2019 23:11:25 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [22.214.171.124]) by ietfa.amsl.com (Postfix) with ESMTP id EAEA1120118 for <firstname.lastname@example.org>; Mon, 20 May 2019 23:11:24 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 863333B05A; Tue, 21 May 2019 16:11:22 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558419082; bh=Fbg/bJBS2XrOpNNEaBmJhJeO8h0=; h=Comments:Received:Date:Message-ID:From:To:Subject:MIME-Version: Content-Type:Content-Disposition; b=qLC6V0QzZjYel0/Qbw1gmdUs50tE7ZHiRr1sITTEEjj4PcBbYQiGVtHGKexRseFeQ tcKO3WHlmSctT2wwXhvCVQDBDYvDCqXlWSdPVsv+Z6hKSDUuVHNm5SXxgTGJ498lNz A1g6psMW//AXDqnHeVmRs03DqSfQXcjIUbowbnFo=wbnFo=
Comments: QMDA 0.3a
Received: (qmail 11759 invoked by uid 1001); 21 May 2019 06:11:22 -0000
Date: 21 May 2019 06:11:22 +0000
From: "Mark Delany" <email@example.com>
To: "DoH WG" <firstname.lastname@example.org>
Content-Type: text/plain; charset=utf-8
Subject: [Doh] TSIG, Padding and "Age:"
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2019 06:11:26 -0000
Sorry. More hand-wringing. Section 9 of RFC8484 (DoH) says "servers can also add DNS padding [RFC7830] if the DoH client requests it in the DNS query". However section 3.4 of RFC2845 (TSIG) says that essentially the whole message is protected by the hash calculation (bar a few irrelevant odds and sods) which means that a DoH server adding padding will break the TSIG message digest. Therefore is it correct to say that a DoH server cannot add padding if the DNS message contains a TSIG RR? I see no mention of this constraint in either RFC8484 or RFC7830 so it might be easy to miss unless you dig deep. If my reading is correct, would a proviso in Section 9 be helpful for implementors? If TSIG is in play - and I don't really know until someone here confirms it - does the TSIG constraint on message modification also conflict with Section 5.1 of RFC8484 which states: "DoH clients MUST account for the Age response header field's value" ... and modify TTLs? Would that section similarly benefit from the proviso of "MUST account for the Age ... unless TSIG is present" or perhaps more generally "no modifications if the message is cryptographically protected"? Dunno how you do that with unknowable future crptographic protections, but oh well. I tell ya. Once you step into the waters of modifying in-flight DNS messages it seems like crocodiles all the way down. Mark.