Re: tsig-04 incompatable w/ RFC 2136 Section 6

[Paul Vixie <vixie@wisdom.rc.vix.com>]

Mark.Andrews@cmis.CSIRO.AU writes:
> 	RFC 2136 Section 6 requires that the message ID be changed whereas
> 	tsig-04 specifically prevents it being changed.  My suggested
> 	solution to the is to zero the message ID when computing and
> 	checking the signature.  This does make a replay attack easier
> 	though the time field should provide reasonable protection
> 	against this.
> 
> 	RD could also be a problem though I've yet to dream up an
> 	appropriate senario.

RFC 2136 section 4 pertains to forwarding, and your exception points up the
fact that while in QUERY, the T in TSIG stands for a hop-by-hop "T"ransaction,
in UPDATE, the T in TSIG stands for (and has to stand for) an end-to-end
"T"ransaction.  Ouch!  That hurts.  Your solution seems like the best one.
Unfortunately for my ideology, this strikes right at the heart of my previous
disagreement with the Microsoft folks over how to best code and describe the
TSIG algorythm.  Maybe they won't notice :-)..

@@ -321,7 +321,8 @@
 .\" \w'TSIG Variables'u+2m
 A whole and complete DNS message in wire format, before the TSIG RR has been
 added to the additional data section and before the DNS Message Header's
-ARCOUNT field has been incremented to contain the TSIG RR.
+ARCOUNT field has been incremented to contain the TSIG RR, but substituting
+0x0000 as the request ID (due to possible request forwarding).
 .IP "TSIG Variables"
 .TS
 tab(|);
-- 
Paul Vixie
La Honda, CA			"Many NANOG members have been around
<paul@vix.com>			 longer than most." --Jim Fleming
pacbell!vixie!paul		 (An H.323 GateKeeper for the IPv8 Network)