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, fujiw...@jprs.co.jp wrote: > >> From: Mark Andrews <ma...@isc.org> >> 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 <fujiw...@jprs.co.jp> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
