Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[Mark Andrews <[e-mail]>]

You specify a well known TSIG key (e.g. name=“.”, algorithm=hmac-sha256, key=<32-zero-bytes>)
then you use it when you don’t have a more specific key.  If the server support the WKK you
will get back a TSIG signed response that can’t have been forged by a off path attacker if it
matched the response.  There should be enough entropy in a TSIG query without add more but one
can add more by putting random data in the other field prior to generating the request’s hmac.
Otherwise you should get back a BADKEY error if the server supports TSIG and FORMERR, NOTIMP
(without a TSIG record) or a non-TSIG response if the server does not implement TSIG.  Clients
can remember of they get a TSIG response and reject non-TSIG responses in the future or treat
each transaction as independent.  I would expect public DNS resolvers to formally state when
they support this.

The pairwise table I generated was to show what current servers do when presented with a
unknown, unexpected TSIG key.  There are a number of mis-implementation of TSIG shown.  A
few underspecified parts of the TSIG specification which I raise earlier.  There are firewalls
that unnecessarily block requests with TSIG present and there are mis-implementations of STD 13
shown.

If we proceed down this path we will need to get CVE’s issues against all the firewalls and
nameserver implementation that block/drop requests with TSIG presents they should be issued 
for firewalls anyway as it they break the ability to use TSIG.  Servers that mis-implement
TSIG or STD 13 need to be identified and fixed.  A date for removal of workarounds for the
mis-implementations needs to be set (+5 years from publishing should be enough time) along
with a campaign to find at inform the server operators of broken servers.  Tests for WKK
behaviour should be added to delegated server tests and if we don’t go down this path vendors
that implement TSIG at least should be add BADKEY tests to their QA procedures, similarly
vendors that don’t implement TSIG need to add TSIG queries to their QA procedures.

The raw data for the table is available at https://ednscomp.isc.org and is regenerated towards
the end of the month.

Mark

> On 4 Mar 2019, at 10:52 pm, [e-mail] wrote:
> 
>> From: Mark Andrews <[e-mail]>
>> Or one can use TSIG with a well known key to get a cryptograph hash of the response.  Below is how
>> how the servers for the Alexa to 1 Million handle unexpected TSIG.  It’s well under a day to add
>> this to a recursive server that supports TSIG already.  It’s a couple of minutes of configuration
>> time to add it to a authoritative server that supports TSIG already.
> 
> Do you mean adding new method like DNS Cookies ?
> 
> I have a question.
> 
> If a resolver want to take measures,
> does the resolver configure TSIG to communicate all authoritative servers ?
> 
> --
> Kazunori Fujiwara, JPRS <[e-mail]>
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]