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

From: Stuart Kwan <[email-masked]>
Date: Mon, 26 Oct 1998 10:14:56 -0800

Olafur,

Thank you for taking the time to summarize the recent discussion on the
list.  I'm hoping that this is the last pass we have to make on the draft
before we submit it to the IESG.  I suggest that we bar further changes to
the draft unless specific security-related problems are identified.  There
are implementors out there that are eager to get started - or in our case,
to get finished.  Let's get onto standard's track.

That said, I agree with Donald wrt his comments on points 1, 2, and 6:

- For point 1 (error codes):  The existing error codes are useful for
debugging, and key names are transmitted in the clear anyway.  Agree with
Donald that we should leave the spec as-is.

- For point 2 (original-ID):  Adding the original-ID field appears to make
the protocol more to replay attacks.  Agree that it should be added.

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

Cheers,
- Stuart

> -----Original Message-----
> From:	Donald E. Eastlake 3rd [SMTP:[email-masked]]
> Sent:	Monday, October 26, 1998 7:24 AM
> To:	Olafur Gudmundsson
> Cc:	[email-masked]
> Subject:	Re: Suggested modifications to the TSIG draft[round 2] 
> 
> Olafur,
> 
> From:  Olafur Gudmundsson <[email-masked]>
> Date:  Tue, 20 Oct 1998 17:01:44 -0400
> Message-Id:  <[email-masked]>
> To:  [email-masked]
> 
> >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.
> 
> 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.
> 
> >---
> >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.
> 
> 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.
> 
> >---
> >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.
> 
> 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.
> 
> >---
> >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
> 
> 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.
> 
> >---
> >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.
> 
> 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.
> 
> >---
> >Point 7: Rewording "[4.4] TSIG on TCP Connection" for clarity
> >
> >Discussion:  There was none.
> >
> >Status: The draft will be modified.
> 
> OK.
> 
> >---
> >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.
> 
> Since I objected to the changes that would cause the scenario not to
> occur,
> I implicitly objected to this change.
> 
> Thanks,
> Donald

---

From: Lea Viljanen <[email-masked]>
Date: Tue, 27 Oct 1998 08:21:08 -0500

> Donald that we should leave the spec as-is.

On the other hand DNSSEC uses numeric algorithm constants, why not
do it uniformly across the DNS board? It would help reuse.

-- 
Lea 'LadyBug' Viljanen                  Fact without theory is trivia.
[email-masked]                    Theory without fact is bullshit.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 27 Oct 1998 09:06:08 -0500

I don't think anyone ever claimed it would be a big disaster either way,
just that there isn't any reason to change.  There are a bunch of
differences between TSIG and DNSSEC.

(1) The algorithm spaces are disjoint.  DNSSEC algorithms are public
key while TSIG are secret key, so its not like you get duplicate names
(constant and domain name) for the same thing since the same algorithm
can't be used in both.

(2) TSIG algorithms are pretty much negotiated on a pairwise basis
outside the protcool, so it is reasonable to have easy private names.
Only pairs of hosts that have agreed to TSIG each other need to worry
about this.  DNSSEC is a global security system where any secure
resolver in the Internet might want to understand the security RRs
served up by any server.  Thus it is made very difficult to add new
algorithms to the one byte algorithm space of DNSSEC, requiring a
standards action, the highest level of bureaucratic difficulty
available in the IETF.  However, an escape hatch is left through the
on "private algorithm" code and, indeed, you can use domain names to
label DNSSEC private algorithms.

(3) Interia.  DNSSEC is already out at Proposed.  While that could
certainly be changed, it needs a reason.  There is code implementing
TSIG and DNSSEC.  Why change it?

This is not the only difference.  They also use different time of
validity formats, for example.  Why would it be worth much to try to
force these two disjoint sets of algorithm codes into the same
encoding?

Thanks,
Donald

From:  Lea Viljanen <[email-masked]>
Message-Id:  <[email-masked]>
To:  Stuart Kwan <[email-masked]>
cc:  "'Donald E. Eastlake 3rd'" <[email-masked]>,
            Olafur Gudmundsson <[email-masked]>, [email-masked],
            [email-masked]
In-reply-to:  Your message of "Mon, 26 Oct 1998 10:14:56 EST." 
	      <B9D1827FDF66D111925800805F3102E3078AC784@RED-MSG-57>
Date:  Tue, 27 Oct 1998 08:21:08 -0500
Sender:  [email-masked]

---

From: Brian Wellington <[email-masked]>
Date: Thu, 29 Oct 1998 17:53:01 -0500 (EST)

> (constant and domain name) for the same thing since the same algorithm

Right.  It would make sense to avoid reusing constants, if possible.  If
the TSIG algorithm space was from 1 - 64K, the first 256 could be unused.

> label DNSSEC private algorithms.

But there's no advantage of "easy private names" over "easy private
numbers," since both are simply values.  The "easy private name" doesn't
convey any information to the server other than a value, so there's no
reason to make it a long, difficult to parse value.

Adding a new algorithm type is non-trivial, since it requires changes to
the name server.  Since, as you said, the algorithm identifier is only
useful between a pair of hosts, using a privately chosen number is
possible also.  We could do:
0 - 255: unused
256 - 32767: IANA assigned
32768-65535: reserved for private use

If two hosts wanted to define a new algorithm, they could simply pick a
number in the 32K-64K range and use it.  It doesn't matter if it's in use
anywhere else.

> TSIG and DNSSEC.  Why change it?

I'm not proposing changing DNSSEC.  This is a very minimal change to TSIG,
and since there are already other changes that are being done (the
original id field, for instance), it's a good time to do this one.

> force these two disjoint sets of algorithm codes into the same

The same encoding doesn't imply that the processing is the same.  Using a
numeric code isn't a special type of encoding.  The TSIG error value is
also a 2 byte integer.  This doesn't mean that it's in any way related to
the algorithm, it's just that an integer constant is a convenient way of
storing a value.

Not to change the subject too much, but Olafur had an interesting idea
earlier today.  Since the key is only shared between two hosts, it's
reasonable to assume that the hosts know the algorithm already.  If the
TSIG record contained only the key name, that would be sufficient.  The
server already looks up the secret based on the key name; it could also
look up the algorithm based on key name.  This would solve the problem of
whether to use a domain name or a constant - it wouldn't need either.

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 31 Oct 1998 14:33:11 -0500

From:  Brian Wellington <[email-masked]>
Date:  Thu, 29 Oct 1998 17:53:01 -0500 (EST)
To:  "Donald E. Eastlake 3rd" <[email-masked]>
cc:  [email-masked]
In-Reply-To:  <[email-masked]>
Message-ID:  <[email-masked]>

>the TSIG algorithm space was from 1 - 64K, the first 256 could be unused.

Actually, since the spaces are disjoint, if you used integers for both
of them, I can't that see much reason to bother avoiding re-using low
integers but I suppose it would avoid some possible confusions in
documents, etc.

>reason to make it a long, difficult to parse value.

There is an advantage to "distributed allocation anything" over
"centrally allocated anything".  And time and again, for naming,
having multiple levels has proven to be better in the long run than
one or two levels.  IANA assigned is basicly a one level allocation
scheme.  When you need global agreement it's great.  When you don't,
it's a pain and possible source of error (not necessarily IANA making
an error but the error of just going ahead and using a "centrally
allocated" value and never actually getting around to checking with
IANA and eventually conflicting).

>number in the 32K-64K range and use it.  It doesn't matter if it's in use

I think there is a bit more grey here.

A few algorithms will be global and implemented in most shipping code
and be the most commonly used.

Somw algorithms may truely be implemented on exactly two hosts and
used only between that pair.

But I would guess that most algorithms in the world will be
"organization wide" algorithms.  For example, one would guess that
some number of intelligence agencies, corporations in the computer
security field, research centers, etc. might design their own
algorithms (or, more often, re-use some appropriate algorithm they had
already designed) and use them on a number of hosts, at least tens if
not hundreds or thousands or hosts.  When you have "organizational
algorithms" like this, inevitably there will be some cases of shared
nodes and the like. Keep in mind also the possibility of fowarded
commands like UPDATE.  Suppose a source of such commands needs to be
able to use one algorithm space for talking to its local firewall DNS
server but a second algorithm space to talk though that to an external
dynamic zone server.  If "private" algorithms might be used, things
start to get complex keeping integers straight.  But there is no
problem at all using algorithms in *.company.example locally and
algorithms in *.dns-server.example for updates that get forwarded to
dns-server (and manybe algorithms in *.nsa.gov for a few special
queries it does to yet another server...)

All in all, I still think things are cleaner with domain names for
algorithms.

>original id field, for instance), it's a good time to do this one.

I know you weren't suggesting changing DNSEC but I was answering
another comment as to "why not make them the same".

>the algorithm, it's just that an integer constant is a convenient way of

Errors are somewhat of a different case.  While an entire error
indication including all the details need not be globally meaningful,
enough of it needs to be understandable that the process receiving the
error message can tell what to do.  It would have made sense for DNS
errors to have, from the begining, been domain names (you might have
even had an ERR class where you could store TXT for them, etc.) but in
that case, you would still have wanted the top level label to be
globally defined in standards documents and the lower level labels to
be "subtype" information.  Be that as it may, DNS errors have always
been numeric so we are somewhat stuck with globally meaningful
numbers.

>whether to use a domain name or a constant - it wouldn't need either.

Really?  I guess there are lots of ways of implementing this but I
always thought of the key name as just refering to a pile (actually
vector) of bits.  Many of the TKEY techniques just transfer or derive
a sematic free pile of bits.  It's really part of the algorithm how
you use those bits.  So I've always thought of the key and algorithm
names as orthogonal...

Thanks,
Donald