From owner-dns-security Sat Sep 19 18:27:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11170 for dns-security-outgoing; Sat, 19 Sep 1998 18:22:01 -0400 (EDT) From: Robert Elz To: Donald Eastlake Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: TKEY updates, time fields In-Reply-To: Your message of "Sat, 19 Sep 1998 16:50:19 -0400." <5010400027048054000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Sep 1998 08:39:24 +1000 Message-Id: <25762.906244764@munnari.OZ.AU> Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Sat, 19 Sep 1998 16:50:19 -0400 From: Donald Eastlake Message-ID: <5010400027048054000002L042*@MHS> I just don't think a ceiling of 18 hours on the life of a symetric key is reasonable. I would certainly agree with that, but I am confused, I think. Where is that 18 hour lifetime limit supposed to come from? (Yes, I know that 18 hours is (close enough to) 2^16 seconds). As I read things, the 16 bit time field in tsig isn't in any sense a key lifetime, its a clock fudge factor (also to allow for network transmission delays I guess). That is, the time indicates "now", and is supposed to be equal on the client and server, within the fudge factor. For that, an 18 hour fudge limit (actually, 9 hours before or after) is just fine. As I read tkey, there's a pair of times, which bound the key validity, one of which is probably in the past, and the other which will be at some random time in the future. These may or not need a settable clock fudge factor to allow for keys which have only just become valid (and remote clock is slower than ours) or for very short expiration times and non-synchronised clocks. What I don't see is how using a 48 bit absolute timer (which consequently will fall flat on its face somewhere about the year 9000000 AD) in any way would be imposing an 18 hour lifetime limit on the key - if anything, it seems it would instead be allowing absurdly long lifetimes. That is, unless you were planning to replace the two current 32 bit timers (Inception and Expiration) with a 48 bit value, and a 16 bit offset, and that I agree would certainly not be a good idea - but replacing both with 48 bit absolute timers should work just fine, or replacing one with a 48 bit absolute timer and the other with a shorter offset field, and allow the other to be calculated - a 32 bit field would certainly be good enough, a 24 bit field (just over 6 months) probably would be a little short. Perhaps a 32 bit field specifying tenths of seconds (13 year range)? I plan to leave them 32 bit fields but make them modulo 2**32. Could you describe again how that is supposed to work? It would certainly eliminate the year 9000000 sunset clause on the standard, but it seems to be that timers which aren't absolute cannot protect against replay attacks, all they can do is make the attacker wait a long time before a replay with a saved old packet will work. If this is so, for the cost of 16 bits, would it not be better to simply use 48 bit absolute values (none of us will care when someone has to spend mega-trillions of tollars to fix all the year 9000000 design limitations...) kre From owner-dns-security Sun Sep 20 16:03:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA14405 for dns-security-outgoing; Sun, 20 Sep 1998 16:03:28 -0400 (EDT) From: Robert Elz To: "Donald E. Eastlake 3rd" Cc: Donald Eastlake , namedroppers@internic.net, dns-security@tis.com Subject: Re: TKEY updates, time fields In-Reply-To: Your message of "Sun, 20 Sep 1998 15:56:03 -0400." <199809201956.PAA31950@torque.pothole.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Sep 1998 06:20:16 +1000 Message-Id: <3014.906322816@munnari.OZ.AU> Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Sun, 20 Sep 1998 15:56:03 -0400 From: "Donald E. Eastlake 3rd" Message-ID: <199809201956.PAA31950@torque.pothole.com> I don't see much logical difference between a start time and a stop time, ... I guess not, when you put it that way. Clearly most of them are the same, the one the "fudge" just seemed "different" to me, but I guess that really it isn't in principle - other than the sizes of the fields. TKEY RRs provide keying material for use in TSIG RRs sort of like KEY RRs provide keying material for use in connection with SIG RRs. Yes, I know. Therefore it seems, at first glance, reasonable to use the "same" variety of validity interval time fields in TKEY as in TSIG, I suppose, except that the intent of the time in TSIG (as I understand it) is to say "this data is valid *now* where now is ...", with the fudge being strictly a bound on what kind of clock inaccuracy and network delay you're willing to tolerate. A key being valid exactly "now" would make no sense at all, it really needs a range of times. [Aside: Randy - apologies for the singular "data", I just can't help it...] While that is a reasonable, if not generous, maximum life time for a TSIG, it seems to me too short for a keying material maximum life. Definitely, and I don't think anyone would suggest otherwise. My guess is that's also why the field in tsig is called a "fudge" - it isn't supposed to be seen as indicating a time interval really, rather an error bound (and yes, I know the two are really the same in some sense). It seems to be better, if one can, to use an existing time format, such as the one in TSIG or the one in SIG, rather than inventing a new one as you suggest. No, that's not what I was suggesting. I was suggesting using the same 48 bit time as exists in TSIG. Use two of those, one for start, and one for end, or save a couple of bytes and use one of those and an offset from it for the range, that makes no difference - it's still using the 48 bit time type. Furthermore, it is my understanding that at least one mode of TKEY is implemented in Windows NT Beta, so there is some reason not to change the field lengths, etc., in the current definition of TKEY. That's a motivation, but not a particularly strong one. I'm going to go ahead and submit the revised draft it with 32 bit modulo timers. Fine - but do please explicitly include the explanation of just how modulo times turn out to be safe enough in the doc, to make sure that the explanation can be properly reviewed by people who know lots more about this than I do. kre From owner-dns-security Mon Sep 21 09:59:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA17087 for dns-security-outgoing; Mon, 21 Sep 1998 09:59:37 -0400 (EDT) Message-Id: <199809201956.PAA31950@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: Robert Elz cc: Donald Eastlake , namedroppers@internic.net, dns-security@tis.com Subject: Re: TKEY updates, time fields In-reply-to: Your message of "Sun, 20 Sep 1998 08:39:24 +1000." <25762.906244764@munnari.OZ.AU> Date: Sun, 20 Sep 1998 15:56:03 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi Robert, From: Robert Elz To: Donald Eastlake Cc: namedroppers@internic.net, dns-security@TIS.COM In-Reply-To: Your message of "Sat, 19 Sep 1998 16:50:19 -0400." <5010400027048054000002L042*@MHS> Date: Sun, 20 Sep 1998 08:39:24 +1000 Message-Id: <25762.906244764@munnari.OZ.AU> Sender: owner-namedroppers@internic.net > Date: Sat, 19 Sep 1998 16:50:19 -0400 > From: Donald Eastlake > Message-ID: <5010400027048054000002L042*@MHS> > > I just don't think a ceiling of 18 hours on the life of a symetric key > is reasonable. > >I would certainly agree with that, but I am confused, I think. Where is >that 18 hour lifetime limit supposed to come from? > >(Yes, I know that 18 hours is (close enough to) 2^16 seconds). > >As I read things, the 16 bit time field in tsig isn't in any sense a key >lifetime, its a clock fudge factor (also to allow for network transmission >delays I guess). That is, the time indicates "now", and is supposed to be >equal on the client and server, within the fudge factor. For that, an 18 hour >fudge limit (actually, 9 hours before or after) is just fine. > >As I read tkey, there's a pair of times, which bound the key validity, >one of which is probably in the past, and the other which will be at some >random time in the future. These may or not need a settable clock fudge >factor to allow for keys which have only just become valid (and remote clock >is slower than ours) or for very short expiration times and non-synchronised >clocks. I don't see much logical difference between a start time and a stop time, a start time and a forward delta, an end time and backward delta, or a middle time and forward/backward fudge. In the first case you have two absolute times that might "overflow" while the rest have only one absolute time that could increase without bounds plus a time delta of some form which could reasonable be limited in the protocol specification. >What I don't see is how using a 48 bit absolute timer (which consequently >will fall flat on its face somewhere about the year 9000000 AD) in any way >would be imposing an 18 hour lifetime limit on the key - if anything, it seems >it would instead be allowing absurdly long lifetimes. That is, unless you >were planning to replace the two current 32 bit timers (Inception and >Expiration) with a 48 bit value, and a 16 bit offset, and that I agree would >certainly not be a good idea - but replacing both with 48 bit absolute >timers should work just fine, or replacing one with a 48 bit absolute timer >and the other with a shorter offset field, and allow the other to be >calculated - a 32 bit field would certainly be good enough, a 24 bit field >(just over 6 months) probably would be a little short. Perhaps a 32 bit >field specifying tenths of seconds (13 year range)? TKEY RRs provide keying material for use in TSIG RRs sort of like KEY RRs provide keying material for use in connection with SIG RRs. Therefore it seems, at first glance, reasonable to use the "same" variety of validity interval time fields in TKEY as in TSIG, which could a 48 bit start and a 16 bit forward delta (or, to be strictly the same, a 32 bit center of life time and a 16 bit fudge). However, that has the problem I specified of an 18 hours maximum keying data lifetime (or maybe 36 hours if the fudge goes both ways). While that is a reasonable, if not generous, maximum life time for a TSIG, it seems to me too short for a keying material maximum life. It seems to be better, if one can, to use an existing time format, such as the one in TSIG or the one in SIG, rather than inventing a new one as you suggest. Furthermore, it is my understanding that at least one mode of TKEY is implemented in Windows NT Beta, so there is some reason not to change the field lengths, etc., in the current definition of TKEY. > I plan to leave them 32 bit fields but make them modulo 2**32. > >Could you describe again how that is supposed to work? It would certainly >eliminate the year 9000000 sunset clause on the standard, but it seems to be >that timers which aren't absolute cannot protect against replay attacks, all >they can do is make the attacker wait a long time before a replay with a >saved old packet will work. If this is so, for the cost of 16 bits, would >it not be better to simply use 48 bit absolute values (none of us will care >when someone has to spend mega-trillions of tollars to fix all the year 9000000 >design limitations...) While the timers do not protect against replay attacks, the authentication on the message with the TKEY in it and the authentication of the SIG that signs a KEY do. In particular, the protocol specifications must require that keys be rolled over to new random keys no less often than every 2**31 seconds. (And the secops draft recommends that no key ever be used for more than 5 years, which is about 1.175 * 2**27 seconds.) The probability that you can successfully replay a TKEY (or SIG) N * 2**32 seconds later for some whole integer N>0 is the probability that you have randomly selected exactly the same key for that rollover epoch which should be the same as someone being able to randomly guess the key. Therefore this does not represent an increased threat. >kre I'm going to go ahead and submit the revised draft it with 32 bit modulo timers. If a consensus develops to do it differently, the draft can always be changed. Thanks, Doanld From owner-dns-security Mon Sep 21 09:59:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA17090 for dns-security-outgoing; Mon, 21 Sep 1998 09:59:38 -0400 (EDT) From: Donald Eastlake To: , Subject: TKEY updates, time fields Message-ID: <5010400027048054000002L042*@MHS> Date: Sat, 19 Sep 1998 16:50:19 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I'm updating draft-ietf-dnssec-tkey-*.txt, because it is about to expire. It has inception and expiration fields that need to be either (1) updated to be modulo 2**32 like draft-ietf-dnssec-secext2-*.txt or (2) modified to 48 bit inception and 16 bit life time fields as in the latest draft-ietf-dnsinc-tsig-*.txt. While TKEY is very closely associated with TSIG and my initial inclination would be to go with the TSIG fields, I just don't think a ceiling of 18 hours on the life of a symetric key is reasonable. Although many will have a shorter life, I think there will be people who will want symetric keys that are good for days if not weeks. So, unless there is a consensus otherwise, I plan to leave them 32 bit fields but make them modulo 2**32. Thanks, Donald Donald E. Eastlake, 3rd 318 Acton Street, Carlisle, MA 01741 USA 1-978-287-4877, fax 1-978-371-7148 From owner-dns-security Mon Sep 21 11:41:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA17642 for dns-security-outgoing; Mon, 21 Sep 1998 11:35:39 -0400 (EDT) From: Donald Eastlake To: , Subject: TKEY updates, time fields Message-ID: <5010400027048054000002L042*@MHS> Date: Sat, 19 Sep 1998 16:50:19 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I'm updating draft-ietf-dnssec-tkey-*.txt, because it is about to expire. It has inception and expiration fields that need to be either (1) updated to be modulo 2**32 like draft-ietf-dnssec-secext2-*.txt or (2) modified to 48 bit inception and 16 bit life time fields as in the latest draft-ietf-dnsinc-tsig-*.txt. While TKEY is very closely associated with TSIG and my initial inclination would be to go with the TSIG fields, I just don't think a ceiling of 18 hours on the life of a symetric key is reasonable. Although many will have a shorter life, I think there will be people who will want symetric keys that are good for days if not weeks. So, unless there is a consensus otherwise, I plan to leave them 32 bit fields but make them modulo 2**32. Thanks, Donald Donald E. Eastlake, 3rd 318 Acton Street, Carlisle, MA 01741 USA 1-978-287-4877, fax 1-978-371-7148 From owner-dns-security Mon Sep 21 11:41:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA17643 for dns-security-outgoing; Mon, 21 Sep 1998 11:35:40 -0400 (EDT) Message-Id: <199809201956.PAA31950@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: Robert Elz cc: Donald Eastlake , namedroppers@internic.net, dns-security@tis.com Subject: Re: TKEY updates, time fields In-reply-to: Your message of "Sun, 20 Sep 1998 08:39:24 +1000." <25762.906244764@munnari.OZ.AU> Date: Sun, 20 Sep 1998 15:56:03 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi Robert, From: Robert Elz To: Donald Eastlake Cc: namedroppers@internic.net, dns-security@TIS.COM In-Reply-To: Your message of "Sat, 19 Sep 1998 16:50:19 -0400." <5010400027048054000002L042*@MHS> Date: Sun, 20 Sep 1998 08:39:24 +1000 Message-Id: <25762.906244764@munnari.OZ.AU> Sender: owner-namedroppers@internic.net > Date: Sat, 19 Sep 1998 16:50:19 -0400 > From: Donald Eastlake > Message-ID: <5010400027048054000002L042*@MHS> > > I just don't think a ceiling of 18 hours on the life of a symetric key > is reasonable. > >I would certainly agree with that, but I am confused, I think. Where is >that 18 hour lifetime limit supposed to come from? > >(Yes, I know that 18 hours is (close enough to) 2^16 seconds). > >As I read things, the 16 bit time field in tsig isn't in any sense a key >lifetime, its a clock fudge factor (also to allow for network transmission >delays I guess). That is, the time indicates "now", and is supposed to be >equal on the client and server, within the fudge factor. For that, an 18 hour >fudge limit (actually, 9 hours before or after) is just fine. > >As I read tkey, there's a pair of times, which bound the key validity, >one of which is probably in the past, and the other which will be at some >random time in the future. These may or not need a settable clock fudge >factor to allow for keys which have only just become valid (and remote clock >is slower than ours) or for very short expiration times and non-synchronised >clocks. I don't see much logical difference between a start time and a stop time, a start time and a forward delta, an end time and backward delta, or a middle time and forward/backward fudge. In the first case you have two absolute times that might "overflow" while the rest have only one absolute time that could increase without bounds plus a time delta of some form which could reasonable be limited in the protocol specification. >What I don't see is how using a 48 bit absolute timer (which consequently >will fall flat on its face somewhere about the year 9000000 AD) in any way >would be imposing an 18 hour lifetime limit on the key - if anything, it seems >it would instead be allowing absurdly long lifetimes. That is, unless you >were planning to replace the two current 32 bit timers (Inception and >Expiration) with a 48 bit value, and a 16 bit offset, and that I agree would >certainly not be a good idea - but replacing both with 48 bit absolute >timers should work just fine, or replacing one with a 48 bit absolute timer >and the other with a shorter offset field, and allow the other to be >calculated - a 32 bit field would certainly be good enough, a 24 bit field >(just over 6 months) probably would be a little short. Perhaps a 32 bit >field specifying tenths of seconds (13 year range)? TKEY RRs provide keying material for use in TSIG RRs sort of like KEY RRs provide keying material for use in connection with SIG RRs. Therefore it seems, at first glance, reasonable to use the "same" variety of validity interval time fields in TKEY as in TSIG, which could a 48 bit start and a 16 bit forward delta (or, to be strictly the same, a 32 bit center of life time and a 16 bit fudge). However, that has the problem I specified of an 18 hours maximum keying data lifetime (or maybe 36 hours if the fudge goes both ways). While that is a reasonable, if not generous, maximum life time for a TSIG, it seems to me too short for a keying material maximum life. It seems to be better, if one can, to use an existing time format, such as the one in TSIG or the one in SIG, rather than inventing a new one as you suggest. Furthermore, it is my understanding that at least one mode of TKEY is implemented in Windows NT Beta, so there is some reason not to change the field lengths, etc., in the current definition of TKEY. > I plan to leave them 32 bit fields but make them modulo 2**32. > >Could you describe again how that is supposed to work? It would certainly >eliminate the year 9000000 sunset clause on the standard, but it seems to be >that timers which aren't absolute cannot protect against replay attacks, all >they can do is make the attacker wait a long time before a replay with a >saved old packet will work. If this is so, for the cost of 16 bits, would >it not be better to simply use 48 bit absolute values (none of us will care >when someone has to spend mega-trillions of tollars to fix all the year 9000000 >design limitations...) While the timers do not protect against replay attacks, the authentication on the message with the TKEY in it and the authentication of the SIG that signs a KEY do. In particular, the protocol specifications must require that keys be rolled over to new random keys no less often than every 2**31 seconds. (And the secops draft recommends that no key ever be used for more than 5 years, which is about 1.175 * 2**27 seconds.) The probability that you can successfully replay a TKEY (or SIG) N * 2**32 seconds later for some whole integer N>0 is the probability that you have randomly selected exactly the same key for that rollover epoch which should be the same as someone being able to randomly guess the key. Therefore this does not represent an increased threat. >kre I'm going to go ahead and submit the revised draft it with 32 bit modulo timers. If a consensus develops to do it differently, the draft can always be changed. Thanks, Doanld From owner-dns-security Tue Sep 22 11:24:52 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA21768 for dns-security-outgoing; Tue, 22 Sep 1998 11:22:36 -0400 (EDT) Message-Id: <199809221356.JAA09647@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-tkey-01.txt Date: Tue, 22 Sep 1998 09:56:54 -0400 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake Filename : draft-ietf-dnssec-tkey-01.txt Pages : 18 Date : 21-Sep-98 [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and securing Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [changes from last draft: add IANA considerations section, make time fields module 2**32, minor edits, update author info, ...] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-tkey-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-tkey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980921132612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-tkey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-tkey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980921132612.I-D@ietf.org> --OtherAccess-- --NextPart--