Subject: Suggested modifications to the TSIG draft[round 2]

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 20 Oct 1998 17:01:44 -0400

This is a followup to the message from several weeks ago suggesting
modifications to the TSIG draft.  There have been several discussions, and I'd
like to summarize the pprogress so that final decisions can be made and the
draft updated accordingly.

Below is a list of points and what I feel the status is after the discussions.

---
Point 1: Replacing the BADSIG and BADKEY error codes with BADAUTH, and
reordering the error checks so that BADAUTH is always checked before BADTIME.

Discussion: Very little.

Status: Accepted, the draft should be modified.

---
Point 2: The message ID should be included in the TSIG calculation to improve
security.

Discussion: Due to concerns with forwarding servers, a new field, Original ID,
was proposed to be added to the TSIG record, which would be copied from the
message ID.  In the case of a forwarded update, this field would be copied into
the message ID as part of the verification.  This idea seemed to go over well.

Status: Accepted, the draft should be modified.

---
Point 3: BADAUTH responses should be unsigned.

Discussion:  This allows spoofed replies.  However, we can not be sure that the
client and server share a key, so there is no way to sign the response.  Bob
Halley's message described this scenario in detail.  The suggestion is that
since no verifiable response can be sent, the lack of a response indicates
failure.

Status: Unknown, but it appears that this is accepted.

---
Point 4: BADTIME response signatures

Discussion: If a server recieves a TSIG signed query with invalid time and
sends a BADTIME response, the client will see the response as having an invalid
time and discard the packet.  Brian suggested using the time_signed field of a
BADTIME packet to store the client's time and the other_data field to store the
server's time or a delta.  Donald objects to using the other_data field, and
suggested adding a new field.

Status: Unknown

---
Point 5: Moving fields to put the signature at the end.

Status: Dropped

---
Point 6: Replacing the algorithm ID domain name with constants.

Discussion:  There was none.

Status: Since no one objects, it appears to be accepted.

---
Point 7: Rewording "[4.4] TSIG on TCP Connection" for clarity

Discussion:  There was none.

Status: The draft will be modified.

---
Point 8: Changes to "[4.6.1] Key error handling" reflecting the fact that the
described scenario (a valid signature with a different key than in the request)
will no longer occur when both client and server are compliant.

Discussion:  There was none.

Status: The draft will be modified.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 26 Oct 1998 10:24:01 -0500

Olafur,

From:  Olafur Gudmundsson <[email-masked]>
Date:  Tue, 20 Oct 1998 17:01:44 -0400
Message-Id:  <[email-masked]>
To:  [email-masked]

>Status: Accepted, the draft should be modified.

No one ever answered my remarks on this point, that I can recall.  To
repeat them:

The information revealed in this case could help someone guess a key
*name* but is of no help in guessing any of the key. Since key names
are passed over the network in the clear, I don't see this as much of
a security problem.  It is not like the SSL error codes case where
information was leaked that made it easier to guess the key itself.
Having these two error codes is a benefit to debugging and deployment
and is presumably already in some code.  While this benefit and the
effort of changing the existing code aren't huge, the security risk
isn't either.  I am inclined not to change this part of the spec.

>Status: Accepted, the draft should be modified.

I think this is the way to go.  Although UPDATE is the only command
currently forwarded, draft-dnssec-rollover-00.txt proposes a ROLLOVER
command and a new type of NOTIFY that would be forwarded and might
have TSIGs.

Basicly you add an "original-ID" field to TSIG, set it to the ID when
you originate a TSIG and include it in the signature calculation.
When checking a TSIG on most commands, you check that the ID and
original-ID are equal.  When checking a TSIG that is a forwardable
command, you don't require them to be equal and you use the
original-ID to check the signature if you know the key (for
simiplicity you would probably implement it to always use the
original-ID for signature check since its the same as the actual ID in
other cases anyway).  Creating a response, you preserve the
original-ID from the request.  When checking a TSIG on a response, if
you are going to forward the response, you use the original-ID to
check the TSIG if you know the key and if you are not forwarding the
response, you require that the ID and original-ID be equal.

>Status: Unknown, but it appears that this is accepted.

I think some more discussion is needed here.  Sure, you can never
guarantee that the client and server share a key.  That's exactly as
true for non-error responses as it is for error responses.  But
signing the response is considered reasonable in the non-error case
and I still consider it reasonable in the error case.  See subsequent
message.

>suggested adding a new field.

I can't understand why the processing flow simply can't be changed so
that when you are about to discard a packet due to bad time you first
check to see if it is a BADTIME error and if so log it.  That seems a
lot easier than faking the time of transmission, mucking up the
"other" field, etc.

>Status: Since no one objects, it appears to be accepted.

No one answered my objections.

Unnecessary additional central coordination and fixed length fields
whose values can be used up are bad.  I would support this if we were
not dealing with software that already understands domain names and
can deal with them.  Having a distributed naming system to avoid
mandatory central coordination is good. Not changing the current spec
unnecessarily is good.  I don't see a need for a change here.

>Status: The draft will be modified.

OK.

>Status: The draft will be modified.

Since I objected to the changes that would cause the scenario not to occur,
I implicitly objected to this change.

Thanks,
Donald

---

From: Brian Wellington <[email-masked]>
Date: Mon, 26 Oct 1998 17:53:06 -0500 (EST)

> isn't either.  I am inclined not to change this part of the spec.

I must have somehow missed your earlier message.  This sounds reasonable,
and when combined with Stuart's comments, seems like the right choice.

>> Point 2: The message ID should be included in the TSIG calculation to
>> improve security.
>>
>> Discussion: Due to concerns with forwarding servers, a new field,
>> Original ID, was proposed to be added to the TSIG record, which would be
>> copied from the message ID.  In the case of a forwarded update, this
>> field would be copied into the message ID as part of the verification.
>> This idea seemed to go over well.
>>

Good.  This seems to be agreed upon then.

>> Discussion: This allows spoofed replies.  However, we can not be sure
>> that the client and server share a key, so there is no way to sign the
>> response.  Bob Halley's message described this scenario in detail.  The
>> suggestion is that since no verifiable response can be sent, the lack of
>> a response indicates failure.
>>

If it's a non-error response, then it's in response to a verified message. 
A verified message tells us that the server and client share the signing
key. 

An error message (BADSIG/BADKEY) tells us that the server does not share
the signing key.  We could attempt to find another key that they do share,
but as Bob said, there's no guarantee that even if the client shares
another key with the server, the requesting application on the client
knows about that key.  I'm not convinced that attempting to find a shared
key is worthwhile.

>> Discussion: If a server recieves a TSIG signed query with invalid time
>> and sends a BADTIME response, the client will see the response as having
>> an invalid time and discard the packet.  Brian suggested using the
>> time_signed field of a BADTIME packet to store the client's time and the
>> other_data field to store the server's time or a delta.  Donald objects
>> to using the other_data field, and suggested adding a new field.
>> 
>> Status: Unknown
> 

First, this is open to a trivial replay attack.  If you're not verifying
the time of a BADTIME message, there's nothing to prevent infinite
replays.  With my proposal of encoding the client's time in the time
signed field, the client can check to see if the time signed value is near
its own current time.

As for mucking up the "other" field - it's not being used for anything
right now.  This proposal would define the "other" field in the context of
a BADTIME message.  Is there another proposed use for the "other" field
which would conflict with this?  I don't think it's worthwhile to add a
new field which is only used for BADTIME.

Stuart Kwan says:
>> - For point 6 (algorithm constants):  I don't think using IANA-assigned
>> numeric values is any more useful than using domain names.  Agree with
>> Donald that we should leave the spec as-is.

My opinion is diametrically opposed to Stuart's.  I don't think using
domain names is any more useful than using constants.  Yes, we are dealing
with software that can understand domain names.  But all we can do with
the domain name now is match it against a known pattern, without
introducing a new DNS record and dynamic loading of new code (no, I'm not
seriously suggesting this).  If all we're doing is pattern matching, why
do a fairly complicated name comparison when a numeric comparison achieves
the same effect?

Many of the DNSSEC documents make the point that "Current DNS
implementations are optimized for small transfers".  In this case, though,
the name "HMAC-MD5.SIG-ALG.REG.INT" is 26 (assuming I can count) bytes
which will not normally be compressed, where the same information can
be obtained from a 1 or 2 byte constant.

An interesting problem arises if the TSIG key name and algorithm are
both close to 256 characters - the TSIG record itself may be larger than
the UDP packet size, so a TSIG signed response with 'tc' set cannot even
be sent.

Central coordination isn't too complicated, since there are very few
assigned values (fewer than the already assigned error values).  The fixed
length shouldn't be a problem, unless there will be more than 2^16
algorithms, which is highly unlikely.

>> Point 8: Changes to "[4.6.1] Key error handling" reflecting the fact that
>> the described scenario (a valid signature with a different key than in
>> the request) will no longer occur when both client and server are
>> compliant.
>>

This text should be present if it can happen, and not present if it cannot
happen.  Therefore, its inclusion is fully dependent on the resolution of
point (3) above.

At least we're getting closer to a solution...

Brian