Re: [DNSOP] TSIG - BADKEY error handling appears to be underspecified.

Mark Andrews <marka@isc.org> Mon, 17 September 2018 00:27 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B46130DFE for <dnsop@ietfa.amsl.com>; Sun, 16 Sep 2018 17:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eyo1XJNqIo7E for <dnsop@ietfa.amsl.com>; Sun, 16 Sep 2018 17:27:15 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593D7130DFD for <dnsop@ietf.org>; Sun, 16 Sep 2018 17:27:15 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 93DC93AB045; Mon, 17 Sep 2018 00:27:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 65925160066; Mon, 17 Sep 2018 00:27:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3A7E616009E; Mon, 17 Sep 2018 00:27:14 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7VU1WasQMfNb; Mon, 17 Sep 2018 00:27:14 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 72F7F160066; Mon, 17 Sep 2018 00:27:13 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <d3a331ac-b324-c53d-dac9-3f9cb1a8c139@knipp.de>
Date: Mon, 17 Sep 2018 10:27:10 +1000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <513BF18D-BAD4-4495-B9B4-293BEBEBBFA9@isc.org>
References: <A23114D1-75BE-4BA5-9C27-78B070BDBD3F@isc.org> <d3a331ac-b324-c53d-dac9-3f9cb1a8c139@knipp.de>
To: Klaus Malorny <Klaus.Malorny@knipp.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3i2IIupChYetiw6xv8Q9xonghsY>
Subject: Re: [DNSOP] TSIG - BADKEY error handling appears to be underspecified.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2018 00:27:17 -0000


> On 14 Sep 2018, at 7:12 pm, Klaus Malorny <Klaus.Malorny@knipp.de>; wrote:
> 
> On 14.09.18 00:55, Mark Andrews wrote:
>> I was testing TSIG with a well known key against TLD servers and got the following response.  Once you get past the bad class field (reported to the operator) there were a
>> number of other items:
>> * the tsig name does not match the request.
>> * the algorithm doesn’t match the algorithm in the request.
>> * time signed is not set.
>> * the fudge value is zero.
>> Should these match the request / be set for BADKEY?
>> Mark
> 
> 
> Hi Mark,
> 
> thanks for bringing this to our attention. I have fixed the DNS class, the key and algorithm name. For the latter two, it makes some sense to return the values from the request. Regarding the time and fudge, I have currently left it to zero, as IMHO they have no meaning without having a signature. But I am open to conviction…

Actually having the clients time and fudge in those fields for BADKEY provides spoofing protection for the unsigned responses. This is especially important with opportunistic TSIG,which is what TSIG with a WKK will be, as there is no longer the presumption that server is configured for the key that there was when TSIG was originally drafted.  It’s all about getting answers through acceptance filters.

For non opportunistic TSIG the client is still expected to wait for a valid TSIG response even if it sees a BADKEY response.

> By the way, the parsing error of DiG seemed to be solely caused by the wrong class; after changing it to ANY, the RDATA was parsed and displayed correctly.
> 
> Regards,
> 
> Klaus
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org