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

[Mark Andrews <[e-mail]>]

> On 14 Sep 2018, at 7:12 pm, Klaus Malorny <[e-mail]> 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: [phone]              INTERNET: [e-mail]