[Doh] TSIG, Padding and "Age:"

"Mark Delany" <d5e@xray.emu.st> Tue, 21 May 2019 06:11 UTC

Return-Path: <d5e@xray.emu.st>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A19212012F for <doh@ietfa.amsl.com>; Mon, 20 May 2019 23:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tC0pb8BzWUhe for <doh@ietfa.amsl.com>; Mon, 20 May 2019 23:11:25 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net []) by ietfa.amsl.com (Postfix) with ESMTP id EAEA1120118 for <doh@ietf.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
Message-ID: <20190521061122.11758.qmail@f3-external.bushwire.net>
From: "Mark Delany" <d5e@xray.emu.st>
To: "DoH WG" <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/5h0vFMHEG95s4vlie5v7K85sxS8>
Subject: [Doh] TSIG, Padding and "Age:"
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: 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.