Subject: FW: WG last call - TSIG

From: Stuart Kwan <[email-masked]>
Date: Fri, 18 Dec 1998 12:45:47 -0800

I sent this early Thursday morning but it hasn't appeared on the list yet.
I'm not sure if that's because it was never sent, never received, or there's
a huge backlog of namedroppers mail.  I will be "offline" until after last
call has ended, so I'm resending this message to be safe.

> -----Original Message-----
> From:	Stuart Kwan 
> Sent:	Thursday, December 17, 1998 1:44 AM
> To:	'Robert Elz'; [email-masked]
> Subject:	RE: WG last call - TSIG
> 
> I have a question about the incorporation of the Original ID field into
> tsig-07.
> 
> Here are Brian Wellington's summary comments on Original ID in a message
> dated 10/03/98:
> 
> >OK, what if an "original ID" field was added to the TSIG record and the
> >digest?  It would be copied from the request ID by the client.  The
> >forwarder receives the message and resends it with a new ID.  The master
> >server notices that the request ID and original request ID don't match,
> so
> >it must be a forwarded message, but since it's using the original request
> 
> >ID in the TSIG verification, it should be ok.  Its response sets the 
> >original id to the original request ID, and the meesage ID to the 
> >incoming message ID.
> 
> Section 3.4.1 seems to cover the behavior part of Brian's comment.
> However, Original ID is not included in section 3.4.2 as a TSIG variable
> included in the data to be digested.  Was this omission intentional?  I
> can't decide if it's necessary or not.
> 
> Cheers,
> - Stuart
> 
> -----Original Message-----
> From:	Robert Elz [SMTP:[email-masked]]
> Sent:	Friday, November 27, 1998 7:08 PM
> To:	[email-masked]
> Subject:	WG last call - TSIG
> 
> This is a working group last call for the TSIG draft
> 
> 	draft-ietf-dnsind-tsig-07.txt
> 
> During the past couple of months there has been considerable
> discussion of the previous version of the draft (-06).  A new
> draft in now available.   I'm no tsig expert, but it appears to
> me after re-reading the discussion, and the draft, that the
> points of agreement from the discussion have been incorporated
> into the draft.
> 
> Unless there are serious technical objections to this draft by
> December 21, 1998 (a slightly extended period to allow for the
> IETF meeting disrupting things), this draft will be forwarded to
> the AD's with a request to issue an IETF last call for PS status.
> 
> kre

---

From: Brian Wellington <[email-masked]>
Date: Sat, 19 Dec 1998 02:21:39 -0500 (EST)

> > can't decide if it's necessary or not.

   3.4.1. DNS Message

   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.  If
   the message is of a type that can be forwarded (i.e. update) and the
   message ID differs from the original message ID, the original message ID
   is substituted for the message ID.

The original ID is substituted for the header ID in cases where it
differs.  It is an error if this occurs on a non-forwardable type.

Should the text be made clearer, or the process changed?  If there is
going to be a change, I wouldn't mind seeing a new error code defined for
this case (since the three specified don't cover it too well).

Brian

---

From: [email-masked]
Date: Sun, 20 Dec 1998 10:46:18 +1100

> this case (since the three specified don't cover it too well).
	Brian you missed answering Stuart's query. Section 3.4.2 does not
	list the original ID, **** below. Is this deliberate or is it an
	over site?

    3.4.2 TSIG Variables

    Source       Field Name       Notes
    ------------------------------------------------------------------------
    TSIG RR      NAME             Key name, in canonical wire format
    TSIG RR      CLASS            (Always ANY in the current specification)
    TSIG RR      TTL              (Always 0 in the current specification)
    TSIG RDATA   Algorithm Name   in canonical wire format
    TSIG RDATA   Time Signed      in network byte order
    TSIG RDATA   Fudge            in network byte order
****TSIG RDATA   Original ID      in network byte order
    TSIG RDATA   Error            in network byte order
    TSIG RDATA   Other Len        in network byte order
    TSIG RDATA   Other Data       exactly as transmitted

	I my opinion it should be added to the signature calculation not that
	it makes any real difference other than the to the number of chunks
	feed to the digester.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian Wellington <[email-masked]>
Date: Sun, 20 Dec 1998 00:29:59 -0500 (EST)

> 	list the original ID, **** below. Is this deliberate or is it an

It was deliberate.  The original ID is digested as part of the DNS
message.  tsig-06 said that when the message is digested, the id field
in the header is zeroed out.  tsig-07 says that when the message is
digested, the id field in the header is replaced by the original id field
in the TSIG, if they differ.

So, the original id field doesn't need to be in the list of TSIG variables
digested, since it's digested as part of the DNS message.  I suppose the
original id could be digested with the TSIG variables and the header id
zeroed out, but I liked this way better.

Brian

---

From: [email-masked]
Date: Mon, 21 Dec 1998 13:17:27 +1100

> I don't think so.  3.4.2 is describing the order in which variables in the
> TSIG record are digested.  The Original ID is not digested with other TSIG
> variables, it is digested as part of the DNS message.  3.4.2 also doesn't
> include the signature, since it's not digested with the rest of the
> variables.
> 
> 3.4.2 could have a note at the end mentioning that the
> Original ID field is not digested as a normal TSIG variable, since it was
> already digested as part of the message (in 3.4.1).
> 
> 2.3 (Record Format) is the place where the location of the original ID
> should be described in a table with the rest of the variables, and it is
> there.

	Fine.

	Mark

---

From: Brian Wellington <[email-masked]>
Date: Sun, 20 Dec 1998 21:04:28 -0500 (EST)

On Mon, 21 Dec 1998 [email-masked] wrote:

> 	Fine.  But this needs to be explicitly stated in and the ****'d line
> 	added to section 3.4.2. TSIG Variables otherwise confusion will
> 	arise.

Brian

---

From: [email-masked]
Date: Mon, 21 Dec 1998 10:56:30 +1100

> > > > > >it must be a forwarded message, but since it's using the original re
> ques
> > > t
> > > > > 

	Mark