Subject: Re: Please advance draft-ietf-dnsind-tsig-09.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 15 Jul 1999 15:24:13 -0700

I've reviewed the draft and come up with some questions and issues
(some of which might be due to my poor understanding of this stuff).

   Erik

---

RFC 2119 ref missing.

Time signed (singnature inception) uint48 vs. uint32 in 
RFC 2535. Why a different number of bits?
The draft uses "time" semantics vs. serial number arithmetic in 2535.
Why the difference?

Section 3.1: add that ARCOUNT is incremented since 3.2 says that it
is decremented.

Section 3.1/3.2: What happens if TSIG not at end of additional section?
Should it be required to add at the end and the packet dropped
if it is not at the end?

3.2: sending message (with TSIG) in response to message with 
unknown alg or key can resulting in infinite ping-pong.
Need to not send errors in response to messages with
RCODE != 0? RCODE != NOAUTH? (See below - document is unclear and/or
internally inconsistent in the description on errors.)

3.4: Would it be useful to state that the order the pieces
of that are feed through the digest function is the same as the order
of the sections (3.4.1, 3.4.2, etc). Or is the order implicit in the
list of data items specified in section 4.1 and 4.2?

4.1: Shouldn't "TSIG Variables (response)" be "(request)"?

4.3 seems inconsistent with the text in 3.2 which says
"if no key is available to sign this message it must be 
sent unsigned" (the text at least implies that errors
will be signed if a key is available).

4.3: How does the resolver know whether or not the request
signature is included in the digest?
Is the test RCODE != NOAUTH?
It would be useful to state this explicitly.

But if RCODE is NOAUTH the response must not be signed - I'm
confused! (Section 4.5 seems to explain this - so the earlier
sections need to be made consistent.)

4.4 talks about "treat this the same way as any other
interrupted transfer", however I can't find anything
in the DNS RFCs that specifies how interrupted
transfers should be handled.
Need to make sure that the whole transfer (or at least 
everything after the last correct TSIG) is ignored
when a later TSIG is missing or incorrect.

4.6 tells the client to discard anything not signed
i.e. the BADSIG and BADKEY errors will be (silently)
discarded. Doesn't this imply that the client will
retransmit and then time out i.e. the software out the
client which invokes the resolver will not see the specific
error?

---

---

From: Terry Lambert <[email-masked]>
Date: Fri, 16 Jul 1999 11:11:31 -0700

> The draft uses "time" semantics vs. serial number arithmetic in 2535.

I'm not a security heavyweight by any means, but I had the
same question.

FWIW, many OS's are going to 64 bits for time_t (i.e. all
time values.

A number of them are also increasing the resoloution of the
time from seconds to nanoseconds; this is required, even
today, on high clock speed machines for timestamp dependent
operations, such as "make".  Consider an OS that uses the
cycle counter register on a CPU, with some scale and delta,
to arrive at its idea of system time, rather than a (slow)
I/O bus access.  On a 500 MHz processor, this is a resolution
of 2 microseconds, with little room for growth.

A 64 (63) bit nanosecond value yields ~584 (292) years until
we, once again, have to worry about the epoch because of our
time_t size.

If this (the 48 bits) is an attempt to "Y2038-proof" things,
and the intent is, indeed, to use a timestamp rather than
serial number arithmatic, I have three comments:

1)	This value should be at least 64 bits

2)	Some sub-second resoloution should be selected

3)	As NFS has adequately demonstrated over the years,
	protocols which use timestamps, but which do not
	contain both the stamp and the current system
	time of the machine providing the stamp, are
	subject to clock-drift based errors.  Therefore
	a second field, indicating current system time,
	should be added to provide delta stamps, and avoid
	requirements for also implementing inter-host
	timesync.  The system time would be held to the
	"Fudge" range for the agregate delta.

As Erik points out, this could all be avoided by using
serial number arithmatic (the logical choice, if there
isn't some overriding philosophical reason for using a
timestamp).

One other (mostly unrelated) comment: 3.3 mentions "Fudge"
in the context of replay vulnerability before its use is
defined (in 4.5.2).  Maybe this should be reordered?

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: [email-masked]
Date: Sun, 18 Jul 1999 13:47:02 +1000

> 1)	This value should be at least 64 bits

	Why?  Isn't 8919403 years enough?
> 2)	Some sub-second resoloution should be selected
	Why?  The timestamp is for authenticating this transaction
	not for sequencing of transactions.  1 second is a good
	resolution as it covers the majority of transmission paths
	around the world.  Even with optimal transmission paths
	~300ms is the lowest resolution you would want.

> 	"Fudge" range for the agregate delta.

	This just shows that you don't understand why the time
	stamp in there in the first place.  It is there so that
	replay attacks only have a limited life time where they
	can be effective.

> isn't some overriding philosophical reason for using a

	Serial number arithmetic still has the time sycronisation
	problems.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 19 Jul 1999 11:42:28 -0400

>(some of which might be due to my poor understanding of this stuff).

will add that. 

>RFC 2535. Why a different number of bits?

The difference has to do with time rollover, 32 bits rollover every 
130 years or so, someone in the working group suggested this over the
serial bit arithmetic that was specified previously. 
The working group meeting where this was suggested thought this was a 
good idea. I do not care one way or the other all this costs is 2 bytes on
the wire. 

>The draft uses "time" semantics vs. serial number arithmetic in 2535.

See above, I think it was Mark Andrews that suggested this approach. 
This is not worth fighting over, but reading the draft I noticed that
the expression of time 0 has Y2K problem, will fix.

>Section 3.1: add that ARCOUNT is incremented since 3.2 says that it
The text says 
"stored in a TSIG which is appended to the additional data section", 
If this is not clear enough we can explain what append means ? 
In my mind append is "adding TSIG record to outgoing packet and 
update section counter"

>Should it be required to add at the end and the packet dropped

There is a long and short answer to this question.
I prefer the short one, the rule should something like:
"TSIG MUST be the last record in the additional section, multiple TSIG
records are NOT allowed, if TSIG is not at the last RR the packet is dropped
and error FORMERR is returned. 

The long answer relates to the possible case of allowing multiple TSIG's,
I think that should be punted until EDNS2 or later.

>internally inconsistent in the description on errors.)

I do not see this happening, only server can generate these errors,
client does not send back errors at all, it retries with a different key.

>list of data items specified in section 4.1 and 4.2?

It is the second, it is specified in section 4.1 
>4.1: Shouldn't "TSIG Variables (response)" be "(request)"?

yes.

>will be signed if a key is available).

You are right, the text is not clear it assumes the definition in
section 3.2 what unsinged means (sig size =0 and no signature). 

>It would be useful to state this explicitly.

No the test is RCODE != NOERR and (Error!= BADKEY or Error != BADSIG)
NOAUTH can be returned for DNS reasons.

>sections need to be made consistent.)

See above.

>when a later TSIG is missing or incorrect.

The RFC's leave this detail out, the standard practice is to
IGNORE/DISCARD interrupted transfers.

>client which invokes the resolver will not see the specific

No it tells the client do drop anything NOT containing TSIG. 

	Olafur

----------------------------------------------------
Olafur Gudmundsson 	    		[email-masked]  (work)
443-259-2389 (NEW PHONE NUMBER)	[email-masked]   (private)
301-854-6889  x2389 (if you can not dial 443 area code)

---

From: Terry Lambert <[email-masked]>
Date: Mon, 19 Jul 1999 10:16:54 -0700

[email-masked] wrote:
> Terry lambert wrote:

[ ... ]

>         Why?  Isn't 8919403 years enough?

For one thing, it's more expensive on many architectures to
deal with 48 bit values.  It's been a long time since I've
seen a running Harris H-800... Ut-oh, I am dating myself.  8-).

For another thing, the size isn't an atomic supported
by most C compilers.  64 bits is supported by all 64 bit
and 128 bit machines, and is even supported on many 32
bit machines (e.g. everywhere there is a GNU compiler).
Making it 64 bits avoid the bitwise aritmatic which would
otherwise be necessary practically everywhere.

Finally, I don't know how to think of "byte order" for 48
bit values.

>         ~300ms is the lowest resolution you would want.

This actually argues against a "Fudge" larger than one, except
under extrodinary conditions (e.g. "off planet"), but IFF you
know the difference between your local time and the remote
host's local time.

>         replay attacks only have a limited life time where they

As I said, I'm no security heavyweight.  But I think that
in practice, there will be a tendancy to use a larger "Fudge"
without a mechanism to account for clock drift.

I believe this significantly increases the window in which
a replay attack would work, and that the issue of acceptable
clock drift should be seperated from the issue of signature
lifetime to reduce the vulnerability.

>         Serial number arithmetic still has the time sycronisation

I don't understand this comment.  The suggested use of serial
number arithmatic by Erik, to my mind, is not to obtain an
equivalent timestamp for a time to live for the signature (I
would rename "Fudge" to "TTL"), but instead to obtain a
non-repeating, monotonically increasing value.  This, in
itself, should guard against replay attacks, since a replay
would not monotonically increase.

I guess this does open an issue of substitution based denial
of service attacks, but I believe that the signature itself
should guard against someone giving an unreasonably large
serial number to an "attack" seeking to make the recipient
stop listening to the legitimate source because of their
serial number being seen as "retrograde".

-- Terry Lambert

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 19 Jul 1999 11:42:28 -0400

will add that. 

The text says 

yes.

See above.

	Olafur