[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tsig-04 Time expire/Time Signed



(1) It's not 110 years, I get more like 136.099 years when I calculate it.

(2) There isn't any problem with SIG.  The text in the current draft says:

"The SIG is valid from the "signature inception" time until the "signature
expiration" time.  Both are unsigned numbers of seconds since the start of
1 January 1970, GMT, ignoring leap seconds.  Ring arithmetic is used as
for DNS SOA serial numbers [RFC 1982] which means that these times can
never be more than about 136.09 years in the future. A SIG RR may have an
expiration time numerically less than the inception time if the expiration
time is near the 32 bit wrap around point and/or the signature is long
lived." 

(3) RFC 2065 specified to ignore leap seconds but does not include the
ring arithemtic wording.  But it is to be obsoleted by the current DNSSEC
draft. 

(4) It seems easy enough to fix TSIG by adopting similar wording.

Donald

=====================================================================
Donald E. Eastlake 3rd     +1 978-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 978-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.privacy.org/ipc



Date: Sun, 31 May 1998 09:17:25 -0400
From: Tom Limoncelli <tal@research.bell-labs.com>
To: Mark.Andrews@cmis.CSIRO.AU
Cc: namedroppers@internic.net
Subject: Re: tsig-04 Time expire/Time Signed

Mark.Andrews@cmis.CSIRO.AU wrote:
> 
>  These fields are specified as unsigned 32 bit ints.  Now these
>  have fields have a limited lifetime of ~110 years (with
>  potential implementation problems in 40 years time).  Now while
>  most of us are unlikely to be around in 110 years that is a chance
>  that the TSIG will still be in use in 110 years time.  Remeber lots
>  of current code is already ~40 years old and is still in use.
> 
>Now SIG has a similar problem to this and I'm not sure what they
>intended to do about this.

I'm stating the obvious but... while other protocols come and go DNS is
so ingrained in all code that preventing such time/date problems now is
worth the problems we prevent in the future.  I'm tempted to say that
major DNS problems can only be fixed when we change IP stacks (IPv4 to
IPv6, IPv6 to IPv7) but somehow I doubt even that is true.  Could we
change the resolution (multiple by 4 before using this value, divide by
4 before storing this value), add another 8 bits, or something?

Either that or everyone on this mailing list has to promise to not have
grandchildren.  1/2 :-)

110 years just isn't a long time.

--Tom