Subject: Re: Suggested modifications to the TSIG draft

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

Hi,

From:  Olafur Gudmundsson <[email-masked]>
Message-Id:  <3.0.5.32.19980929141855.00a48cd0@localhost>
Date:  Tue, 29 Sep 1998 14:18:55 -0400
To:  [email-masked]
In-Reply-To:  <[email-masked]>

>At 05:21 PM 9/23/98 -0400, Brian Wellington wrote:
>>I've been implementing the TSIG draft, both in BIND 8.1.2 and an
>>independent implementation of DNS (in Java).  Based on this experience,
>>I've come across a number of issues that need resolution and/or
>>clarification.
>>
>>These ideas have arisen in discussions with Olafur Gudmundsson, Paul
>>Vixie, and Bob Halley.  No guarantees that everyone agreed on all changes
>>presented below.
>
>
>Given that there have been no objections to the proposed changes 
>I will go ahead and update the draft to reflect these changes,
>any objections ? 
>
>	Olafur 

Sorry not have commented earlier but these changes seem pretty
substantial and could use a bit more consideration, notwithstanding
that it would be good to get TSIG out.

>>Are there any existing implementations of TSIG, and if so, how have the
>>implementors dealt with these problems?
>>
>>Brian
>>-----------
>>
>>- [1.7] Error codes: Having different errors for BADKEY and BADSIG leaks
>>security information (specifically, the name/algorithm of exisiting keys).
>>These should be combined into one error code, which could be called
>>BADAUTH.

This a matter of degree.  Keep in mind that any working key names pass
over the net in clear form and are easily observably by bad guys.
Thus any security repesented by the key name is no more than re-usable
plain text password security.  Given this, I don't see that the harm
by having two error codes is necessarily larger than the benefit in
helping too figure out what's wrong when TSIG isn't working.
Furthermore, there is a benefit in not changing the spec.  So, while
my feelings are not that strong here, if the decision were mine, I
would not make this change.

It certainly would make sense to add a sentence somewhere saying
something like "Note that key names pass over the network in the clear
and that bad key names can produce an error code which distinguished
that condition from a bad signature.  Thus obscure or "secret" key
names should not be depended on for any security.  Security in TSIG
comes from carefully using strong key values, not key names."

>>- [3.4.1] DNS Message.  The request ID should be digested as present, not
>>as 0 (see below).

See below.

>>- [4.3] Error returns:
>>  * BADAUTH response:  The response will be unsigned, as the problem lies
>>  with the key used.  The server cannot definitively determine another
>>  key to sign the data with, so no key is used.

What is this "cannot definitively determine" stuff?  Is this a case
where because you can't do something perfectly, you don't want to do
it at all?  If there are any other keys lying around that the server
thinks the client knows about, why not sign with one of them picked at
random?  If a client is really worried about bad guys, it won't
believe an unsigned response anyway and will eventually give up
sending signed requests.  But if it tries enough times and there are
other keys and you pick one at random to sign the response, you are
maximizing the probability that you will send a valid signed response,
at least to the extent that you can without keeping state at the
server.

What is the harm in having the server send back a signed response
instead of an unsigned one?  If the signature is not understood by the
client and the client is requiring a good signature on the response as
I think it should for a signed request, both should be rejected.  On
the other hand, if the signature is understood, you have saved some
round trips and signed a key change for free.  The only problem I can
think of is that this may provide a means for repeatedly getting the
server to sign partially controllable plaintext.  If that is a
problem, and maybe just for good measure, the solution is to add a
random nonce to TSIG which is also covered by the signature.

>>  * BADTIME response:  The response is signed using the key that signed the
>>  query.  So that the client will not fail to verify the response with a
>>  TIME error, the ``Time Signed'' field of the response is copied from the
>>  query.  In order for the client to determined the server's current time,
>>  the server includes its time in the ``Other Data'' field as an unsigned
>>  48 bit value, and sets ``Other Len'' to 6.

It does not seem to me it would be beyond manageable complexity to do
a special check on BADTIME responses and not enforce the time delta on
them...  In particular, it is not clear to me that that is any more
complex that using up the "Other Data" field in this one case and
making it harder to use if anyone ever wanted to add a field to all
TSIGs.

>>- [4.5] Server TSIG checks: BADAUTH checking (both valid key and valid
>>signature) MUST be performed before BADTIME checking, so that BADTIME is
>>only returned on a message with a valid signature.

OK by me.

>>- [4.6.1] Key error handling.  The scenario described (a valid signature
>>from a different key than the query used) should no longer occur, since
>>error messages are either unsigned (BADAUTH) or signed with the same key
>>(BADTIME). This mechanism could be used if the client/server shared
>>multiple keys and the server was requesting that the client use a
>>different key.

But I think key/sig responses should be signed if another key is
available to the server.

>>- [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).

This is the most complex issue and, as I see it, the problems come
with trying to overload the TSIG with being both a DNS one hop
authentication and a DNS end-to-end authorization.  The most general
solution would be to allow two TSIGs, one end to end (with a field for
the "original" ID so it does not get lost) and one for each DNS hop,
but I can understand why that amount of complexity would seem
undesireable...

Assuming the passing of an update request or response through
intervening servers without their checking the signature if they don't
have the key is acceptable, it might do to just have a flag somehow in
the TSIG so you can tell whether to leave that TSIG in the request.
You can always check it if you know the key and algorithm. But would
not bother resigning, even if you had a key with the next recipient,
if this flag were set...

>>Other comments, not essential:
>>
>>- [2.3] Record format:
>>  * Why is the algorithm a domain name?  It would be simpler to use an
>>  IANA assigned constant for processing and name server configuration.

There is no particular reason to bottleneck this all through IANA and
thw wording that all new algorithms should be registered with IANA
should be qualified to public algorithms intended for wide use.  Local
assignment and control through an existing hierarchial scheme, as
currently in the draft, seems better to me than getting a number from
IANA.  You could also use OIDs.  But given that you are working with
domain names anyway and have routines around for manipulating and
storing data under them, why is this hard?

Probably the text
                                                                "The only
   Message Digest algorithm specified in this document is ``HMAC-MD5'' (see
   [RFC1321], [RFC2104]).  Other algorithms can be specified at later date.
   Names and definitions of new algorithms should be registered with IANA."

should be replaced by "The only Message Digest algorithm specified in this
document is "HMAC-MD5.TSIG-ALG.REG.INT." (see [RFC1321], [RFC2104]).  See
IANA Considerations section." and a new short section such as the following
should be added:

X - IANA Considerations

Key names are a matter between the parties sharing the secret key and do
not need any IANA or central approval but it is recommended that the
guidelines in this draft be followed.

Algorithm names need to be understood by the communicating parties.
Anyone can allocate names below a domain name they control.  For
instance, example.com can assign algorithm1.example.com.  However,
publicly defined algorithms inteaded for borad use should be given a
name under TSIG-ALG.REG.INT as assigned by IANA based on an RFC or
other publicly available documentation of the algorithm.

>>  * 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?

Given how they are being actually computed, I don't see that it makes
any difference.

>>- [4.4] TSIG on TCP Connection: This could use clarification and/or
>>different word choice.  The terms ``header'', ``DNS header'',
>>``envelope'', and ``message'' are all used and undefined.  It looks like
>>``header'' and ``DNS header''are used when ``envelope'' should be, and
>>``header'' should be reserved for the 12 byte header at the beginning of
>>each envelope. I assume a ``message'' is a set of envelopes containing
>>exactly one TSIG, on the last envelope.  So, each message digest contains
>>the previous digest (the TSIG signature), digests of each envelope, and
>>the TSIG Timers (calculated at the time of the TSIG signature).  Is this
>>correct?

Clearer wording is always better.

>----------------------------------------------------
>Ólafur Guðmundsson (in ISO-8859-1)	    [email-masked]    (work)
>Olafur Gudmundsson (in US ascii)       [email-masked]   (private)
>(301)-854-5700   Fax: x5363

Additonal comments:

[4.1] shouldn't the TSIG Variables say "(request)" after them rather
than "(response)"?

My Author Information (in the header at the top of the first page and
at the end of the draft) needs to be changed to show my affiliation as
"IBM" and my email address is wrong at the end (shown as "d3@..." when
it should be "dee3@...").

Thanks,
Donald

---

From: Bob Halley <[email-masked]>
Date: Tue, 06 Oct 1998 15:31:26 -0700

Donald Eastlake writes:
> it at all?

If the server is going to do any better than guess, it must choose
another key to use based on something about the request, i.e. the DNS
message or the source network address of the request.  The former
doesn't seem to hold much promise, so let's use the source network
address.  Maybe we have some way of configuring which network
addresses may use a particular key.  If not, then all we can do is
guess another key at random out of all the keys we know.  If we do
associate keys with addresses, then we could find another key that was
valid from this address.  But there's still no particular reason to
believe the requestor will understand it.  Consider a host with a
resolver using one TSIG key, and a dynamic update application using a
different TSIG key.  Only one key will ever be understood by a given
requestor from this host, so trying the other key doesn't help.

Since we can't do better than guess, why do it?  The requestor knows
what keys it understands, and is going to have to send its request
again anyway using a new key, so we only save roundtrips if the
requestor is going to try more bad keys before it hits on a good one,
and somehow the server can guess a key the requestor knows.

I agree with you that there is no particular problem with signing with
another key other than possibly giving an attacker a signature in a
situation where they control much of the plaintext.  I just see little
benefit from it.

On to another issue...

The current TSIG draft (without adding any of the proposed changes
suggested in recent namedroppers email) is vulnerable to spoofing of
BADSIG and BADTIME.

If an attacker wants to get a BADTIME or BADSIG to use in faking a
response to a particular request, they need merely create a request
with bad time values or a bad signature, submit it to a legitimate
server, and remember the response.  When a legitimate requestor issues
the request (with valid time values and a valid signature), the
attacker can respond with the previously obtained BADTIME or BADSIG
response.  Signing BADTIME and BADSIG isn't adding trust.

Such spoofing would be harder if the request id were included in the
error response signature.

So, what is the poor client to do?  How can it tell a legitimate TSIG
error response from a spoofed one?  Just aborting the request when a
BADKEY, BADSIG, or BADTIME was received would allow a denial of
service attack.  When a client who has issued a signed request
receives what appears to be a TSIG error reply to its query it could
simply record "I got a TSIG error" and proceed as if it never saw the
packet.  Either a legitimate signed response will come in later or the
request will time out.  In either case, if any TSIG errors were
received, the client would report this to the user.  The user could
then check his key and his clock, and if they look OK, he could
contact the nameserver administrator.  Either TSIG errors from that
client around that time were logged at the nameserver or they weren't,
so the administrator can distinguish between spoofing of the client
and a legitimate configuration problem with the client.

/Bob

---

From: [email-masked]
Date: Wed, 07 Oct 1998 11:40:27 +1000

> and a legitimate configuration problem with the client.
	Well noting a potential error and continuing to wait is one way
	to go.  The other is to introduce random bits into every TSIG
	transaction.  We effectivly do this for the normal query resonse
	case (section 4.2) where the queries signature is used to prime
	the response signature. 

	Now for the BAD KEY error if we had a well know NULL KEY we
	add the original sig into the calculation and effectivly stop
	blind BAD KEY attacts. The attack space is just to large for
	blind attacks to work. This doesn't stop attacks where the
	attacker can see the messages.

	Now for BAD TIME we could I can see no reason not to include
	the original signature into the response signature calculation.

	As for BAD SIG the normal reason for generating these would be
	that the secret has changed and one side is out of date. Here to
	a NULL SIG would make blind attacks not effective.

	Now if a BAD TIME also had a BAD SIG we could revert to a NULL KEY.

	Response signed with the NULL KEY would then be treated as a hint
	that something was potentially wrong but let the usual retry /
	timeout mechanisms play out. This paragraph should apply to
	UDP base requests.  TCP request should treat the errors as hard
	errors (ignoring TCP hijacking).

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

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 31 Oct 1998 10:47:26 -0500

From:  [email-masked]
Message-Id:  <[email-masked]>
To:  Bob Halley <[email-masked]>
cc:  "Donald E. Eastlake 3rd" <[email-masked]>,
            [email-masked]
In-reply-to:  Your message of "Tue, 06 Oct 1998 15:31:26 MST."
	                  <[email-masked]> 
Date:  Wed, 07 Oct 1998 11:40:27 +1000

>> and somehow the server can guess a key the requestor knows.

I agree with most of your facts, just not with the conclusions.  TSIG
is pretty much negotiated so knowing what IP address a key is
associaed with is not unreasonable.  I think the total pool of keys
available to some servers will be small enough that signing with one
picked at random is not that bad.  And there is also the advantage,
not mentioned so far, that if the signed response happens to get
logged anywhere, it may be possible to authenticate it later when
investigating anomalies.

>> situation where they control much of the plaintext.  I just see little

If there is some benefit why not do it? or at least explicitly
acknowledge it as a reaonsable thing to do if not recommending it?

>	attacker can see the messages.

BAD KEY seems like an error you have to log and ignore unless, of
course, the server has randomly picked a key you know about and signed
the response with it (which should include request signature) so you
can authenticate the BAD KEY.

>	the original signature into the response signature calculation.

Yes, I think that's the way to go so spoofed BAD TIME responses can be
detected.

>	that the secret has changed and one side is out of date. Here too

Different secrets should have different names.  The strongest thing
would be to include the request signature as a field in the signed
response.  That way the requester could tell, by checking that field
and the response signature, whether the request was diddled in transit
or the response was spoofed.

>	Now if a BAD TIME also had a BAD SIG we could revert to a NULL KEY.

I'm not sure I really like this NULL KEY idea...  TSIG needs to be
strong against an adversary who can observe and inject traffic.

Thanks,
Donald