Subject: Re: Suggested modifications to the TSIG draft

From: Paul A Vixie <[email-masked]>
Date: Wed, 30 Sep 1998 18:36:25 -0700

>>  * Computing the digest becomes simpler if the signature length &
>>  signature fields are moved to the end of the record.  Is there any reason
>>  why they are in the middle?

because that's how they grouped logically.

> Jim Gilroy asked for this a while ago, but none of the authors responded.
> Eventually we relented so the protocol would move forward.  Such is life,
> but are we going to change it again?

totally different issue.  in no case will the draft stop saying "feed the
fields into the digestifier one by one" no matter where we move the fields
to.

---

From: [email-masked]
Date: Thu, 01 Oct 1998 15:29:58 +1000

> Olafur, were you planning on incorporating all of Brian's points?  Or just a
> select set?  A few comments:
> 
>> - [4.7] Special Considerations for forwarding servers: Should be removed.
>> If a server forwards a query, it should strip the incoming TSIG record,
>> and generate a new one if it shares a key with the next server.  This
>> allows the message digest to include the request id instead of 0 (see
>> above).
> 
> It may not be wise to select a new key, if someday these keys are used for
> access control.  Also, I take it that you would select a different message
> ID for the forwarded update, per RFC 2136?  Does anyone else have a comment
> here?

	The id was removed from the signature calculation to support
	UPDATE.  I know it makes things more complicated but it allows you
	to identify the ultimate client and not just the forwarder. This
	means the forwarder does not need to do access control which is what
	is required now.

	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: Thu, 1 Oct 1998 14:16:42 -0400 (EDT)

> select set?  A few comments:

I suppose I'll speak for Olafur, as he's out of the country now.  I think
the plan is to incorporate as many of the points as are deemed acceptable.
Since I'm not an author of the draft, it's not my decision...

> ID for the forwarded update, per RFC 2136?  Does anyone else have a comment

Good point.  There are several possibilities:

1) The client, forwarding server, and master server all share the key, so 
that the forwarding server can resign the packet with the same key (but a
different request ID).  I like this idea.

2) The forwarding server signs the data with a different key.  If the
forwarder trusts the message (that is, verifies the TSIG), and the master
trusts the forwarder, this would be ok.  If the forwarder signs all
forwarded updates, even those that were originally unsigned, there would
need to be a way for the master to determine the status of the original
update.  I don't know if such a way exists.

3) The forwarding server sends the message with the original TSIG
attached.  This leads to the "do we forward or respon with BADKEY?"
problem described earlier if the forwarder does not have the key.  If the
forwarder has the key, we're in step (1).

> > * Computing the digest becomes simpler if the signature length & signature
> >  fields are moved to the end of the record.  Is there any reason

Paul feels pretty strongly that the order should not change.  This is not
necessary for implementation, so I don't feel too strongly about it.

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 01 Oct 1998 18:36:01 -0400

From:  Brian Wellington <[email-masked]>
Date:  Thu, 1 Oct 1998 14:16:42 -0400 (EDT)
To:  Stuart Kwan <[email-masked]>
cc:  "'Olafur Gudmundsson'" <[email-masked]>,
            "[email-masked]'" <[email-masked]>,
            James Gilroy <[email-masked]>
In-Reply-To:  <B9D1827FDF66D111925800805F3102E3078AC4BB@RED-MSG-57>
Message-ID:  <[email-masked]>
Sender:  [email-masked]

>different request ID).  I like this idea.

I think a case might be someone with a laptop who plugs into a foreign
lan with a firewall and wants to update their DNS entry with their
dynamically assigned IP address.  They generally wouldn't want to
trust the foreign firewall with their secret key.

>update.  I don't know if such a way exists.

See above.  If you go too far down this path, you need to start
including the signer and intended verifier identies in the TSIG or
something complex like that...

>forwarder has the key, we're in step (1).

The concept in the current draft seems to be that the forwarded is
just part of the "wire" between the requester and the server.

>necessary for implementation, so I don't feel too strongly about it.

Thanks,
Donald

---

From: Brian Wellington <[email-masked]>
Date: Thu, 1 Oct 1998 15:58:40 -0400 (EDT)

> 	means the forwarder does not need to do access control which is what

It seems to me that this is something that should be handled by the UPDATE
protocol, not TSIG.  To implement any sort of access control (IP address
range, for instance), the master server needs to be able to identify the
original client.

But it's not, so TSIG will have to do something.

I don't think removing the ID is the correct solution.  It leaves TSIG
open to a number of replay attacks, since an attacker can cache a signed
response, and replay it throughout its valid lifetime (the fudge value).
If the message ID is digested, there's only a 1/64K chance that a cached
message could be a valid response, which is far better.  It's not a good
idea to reduce security overall just to support update forwarding.

We could require that the client, forwarder, and master all have access to
the signing key, as I suggested in Stuart's message.  Or we could require
that the forwarder does access control.  Or we could modify UPDATE so that
the forwarder gives the master some indication of the originator (Multiple
TSIG records, for example - the forwarder would resign the packet if the
client's TSIG verified, and the server would verify that the forwarder
signed the packet containing a valid TSIG, even if it doesn't have the key
to verify the inner TSIG).

Just more ideas...

Brian

---

From: [email-masked]
Date: Fri, 02 Oct 1998 08:31:41 +1000

> to verify the inner TSIG).
	Brian, there currently is only one time when a server forwards a
	message and that is in processing a UPDATE message.  There is no
	other time when a server forwards a message.  What most people
	think of as forwarding is just the resolver in the server responding
	to the recursion request where the server is generating a new request.

	BIND takes short cuts in generating this initial request and this
	has lead to this miss understanding.  Its also generated a lot of
	problems over the years and hampered developments of the DNS protocol
	as we have had to deal with a large broken installed base.

	Now as the UPDATE is the *only* forwarded request I'll get back to
	points above.

	1. TSIG was designed to provide UPDATE with an light weight 
	authentication mechanism compared to DNSSEC.

	2. UPDATE has support for replay detection built into protocol
	if you care to update using it.

	3. Sharing the key with the secondary weakens the security much more
	than allowing a small widening of the opportunity for replay attacks.  
	Now when I was working with CSIRO we had zones secondaried on NASA
	servers.  While we trusted NASA to not tamper with the zone data
	we would not have given them access to update the zone file which
	sharing keys would have done.

	Mark

---

From: Brian Wellington <[email-masked]>
Date: Fri, 2 Oct 1998 11:11:15 -0400 (EDT)

> 	to the recursion request where the server is generating a new request.

OK.  I was misled by the fact that BIND specifies a forwarders{} clause
in its configuration and has a file called ns_forw.c with a function
ns_forw(), none of which have anything to do with forwarding.  Silly me :)

> 	sharing keys would have done.

These are all correct.  But there needs to be a way to include the
original request id in the signed data.  Here's another suggestion:

The forwarding server receives a message.  Instead of simply copying the
message and changing the request id (RFC 2136 doesn't say anything about
the copying of the message), it adds its own TSIG record, and stores the
original request id in the other_data section.

The primary server gets the message, verifies the forwarding server's
TSIG, puts the original request id back, then verifies the originator's
TSIG.

I'm still not sure how the forwarding server is supposed to know to
forward the message as opposed to returning a BADKEY/BADAUTH error, since
the draft is unclear (from 3.2, the a BADKEY error should be returned
before it can be determined whether the server should forward the data)

3.2 TSIG processing on incoming messages

If the algorithm name or key name is unknown to the recipient, or if the
message digests do not match, the whole DNS Message must be discarded.  A
response with RCODE 9 (NOTAUTH) should be sent back to the originator with
TSIG ERROR 17 (BADKEY), if no key is available to sign this message it
must be sent unsigned (Signature Size == 0 and empty signature).

4.7. Special considerations for forwarding servers

A server acting as a Forwarding Server of a DNS message, should check for
the existence of the TSIG record.  If the name on the TSIG is not of a
secret that the server shares with the originator the server will forward
the message unchanged including the TSIG.

Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 03 Oct 1998 10:10:08 +1000

> TSIG, puts the original request id back, then verifies the originator's

	Nice idea but it won't work if the forwarding server is not
	TSIG aware as such a server WILL change the request id, see
	rfc2136 Section 6 Forwarding.  What ever we do has to work with
	non TSIG aware servers.

	Mark

---

From: Brian Wellington <[email-masked]>
Date: Sat, 3 Oct 1998 11:51:35 -0400 (EDT)

And quoting Donald:
> I am opposed to any use whatsoever of the "Other" field in this TSIG
> standard.  While I'm not convinced any additions are necessry, if it
> is necessary to add flags or an "original ID" or an "error data" field
> to TSIG, add those fields, don't muck up "Other".

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.

Since only UPDATEs can be forwarded, it should be a TSIG error to reecive 
a non-UPDATE packet with request ID != original request ID.

The question is, though, does this help security?  I think it does.  
Including the original request ID still greatly reduces the chance of 
replay/spoofing attacks, since a false response has to contain the 
matching original ID, or it will be rejected by the client.

Of course, this means adding a new field, which might not go over too well...

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 03 Oct 1998 09:40:26 -0400

Thanks,
Donald

From:  Randy Bush <[email-masked]>
Message-Id:  <[email-masked]>
To:  Brian Wellington <[email-masked]>
cc:  Stuart Kwan <[email-masked]>, Olafur Gudmundsson <[email-masked]>,
            namedroppers <[email-masked]>,
            James Gilroy <[email-masked]>
In-reply-to:  Your message of "Fri, 02 Oct 1998 11:11:15 -0400."
	                  <[email-masked]>
 
Date:  Sat, 03 Oct 1998 10:10:08 +1000

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 04 Oct 1998 09:13:19 -0400

As to how much problem implementers or the other authors of the TSIG
draft will have with adding an Original ID u_int16_t field, I can't
say.  But I think it is the best solution.  In most cases, it would be
checked against the DNS message ID and it would be an error if they
were different and so, of course, either one could be used for
signature calculations.  UPDATE, at the server and forwarders only,
would be a special case and permit the message and TSIG Original IDs
to be different.  When an UPDATE response got back to the requester,
it would require the IDs be equal...

Thanks,
Donald

From:  Brian Wellington <[email-masked]>
Date:  Sat, 3 Oct 1998 11:51:35 -0400 (EDT)
To:  [email-masked]
cc:  Stuart Kwan <[email-masked]>, Olafur Gudmundsson <[email-masked]>,
            namedroppers <[email-masked]>,
            James Gilroy <[email-masked]>
In-Reply-To:  <[email-masked]>
Message-ID:  <[email-masked]>

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 04 Oct 1998 16:33:11 -0700

> Or am I missing something here?

message-id is part of a tuple.  <addr,port,id>.  there is no reason to
expect that the same key will not be used by some other <addr,port>,
even with the same signing key, during the lifetime of the transaction
you're trying to secure.

---

From: Brian Wellington <[email-masked]>
Date: Sun, 4 Oct 1998 19:02:56 -0400 (EDT)

On Sun, 4 Oct 1998, Paul A Vixie wrote:
> if we're going to add an original-id, then we also need to add
> original-port and original-addr -- which means we get squarely
> into the NAT question.  let's find a different way to solve this.

Not necessarily.  Since there's no guaranteed mapping between TSIG keys 
and IP addresses, neither the server or client needs to know the real 
address of the remote end.  As long as the identity (as obtained through 
the signature) is maintained, it doesn't matter if the packet flowed 
through a NAT.

Brian

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 04 Oct 1998 10:05:01 -0700

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 04 Oct 1998 21:19:02 -0700

that makes sense.  if bob has no objection, then i will have no objection.

---

From: Brian Wellington <[email-masked]>
Date: Sun, 4 Oct 1998 23:46:14 -0400 (EDT)

> even with the same signing key, during the lifetime of the transaction

The reason to add the original id (at least, the reason I want to add it) 
is to prevent error messages from being too generic - the error message's 
request id should match the query's id, and this should be verifiable 
through the signature.  The fact that the message id can be grouped with 
the address and port to form a unique triple doesn't seem relevant in 
this context, since the original id field doesn't affect the triple seen 
at either the forwarding server or the master server.  The master server 
sees the same <id, addr, port> triple as it would without the original id 
field; the only change is that an additional field is added to the digest.

If this doesn't address the problem you're describing (I'm having a little
trouble parsing the second sentence), could you please give an example? 
Thanks... 

Brian