Received: from tis.com by magellan.TIS.COM id aa08723; 28 Oct 93 10:44 EDT Received: from magellan.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA29195; Thu, 28 Oct 93 10:44:51 EDT Received: from [127.0.0.1] by magellan.TIS.COM id aa08710; 28 Oct 93 10:44 EDT Reply-To: James M Galvin To: dns-security@tis.com Subject: DNS Security Sub-Working Group Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 28 Oct 1993 10:44:33 -0400 From: James M Galvin Message-Id: <9310281044.aa08710@magellan.TIS.COM> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" The DNS Security Sub-Working Group will meet at the Houston IETF. The exact placement within the DNS meeting has not been determined, yet. Unfortunately, it took somewhat longer than desirable for Rob and I to get together on when the meeting should be. Rob prefers that the sub-group meet prior to the DNS working group meeting so we can bring "results" for discussion rather than having an open meeting. The problem is that it is really late to be scheduling a meeting time. So, I'm going to try to organize a meeting time for the security subgroup. If you would like to attend, please send me a note saying so and tell me when you are available. I will find a time that is convenient for the most people and post an announcement, on the message board at the IETF. Sorry, but that is the best I can do at this time. On to the real work.... What I've done is to go through all of the mail I've seen on DNS security from the following places: namedroppers, ipsec, dns-security, and firewalls. From the mail I've identified the issues and have summarized them below. I would like to point out that one thing we have not done yet is to identify the threats against which we are providing protection, and then to document them. For the meeting agenda I would like to propose the following: o identification of threats (and justifying rationale) in preparation for a document o review of issues - do we understand the issues documented - is this the right set of issues o development of plan and schedule for deliverables, not to exceed two more IETF meetings I have cc'ed the namedroppers list on this message for information only. Please keep the discussion on the dns-security@tis.com mailing list. If you are not on the list and wish to join please send a message to dns-security-request@tis.com. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Resolved Issues For DNS Security 1. The DNS application should support security services itself, i.e., it can not depend on the security services of another layer, for example, IP. In support of this position is the point made first by Steve Bellovin. Network-level security provides identification and authentication, but not authorization. The DNS requires authorization. Christian Huitema also noted that the source of the DNS data is not the DNS, per se, but some administrator. Thus, the data needs to be signed by this administrator, not the DNS. Unresolved Issues for DNS Security 1. On the firewalls mailing list, there was a fair amount of discussion of the use of the DNS in firewalled environments. I would like to suggest that this group take as an action item to produce an informational document that addresses this issue. 2. Insofar as PEM is a technology that provides key management services, the DNS could make use of it to distribute certificates. However, it has also been suggested that the DNS could distribute its own certificates by specifying a new resource record. The following subissues are relevant to this discussion. a. If the DNS is "secure", could we store/distribute just keys in/with it, or do we need certificates? b. If we store certificates, and even large keys, their distribution or inclusion in DNS replies may exceed the maximum size allowed. Two suggestions have been made. First, we could propose a parallen DNS-like server that does not have the limitation. Second, we could specify MX-like records that point to "key" manager services. c. Could SNMP be used to distribute the key/certificates? 3. In order for key management to be effective, the key must be "bound" to an object that identifies it. For example, in PEM the public keys are embodied in a certificate that binds the distinguished name of owner of the public key to the key. In the case of DNS, the question is should the key be bound to the address (or other data) record, the domain name, or both? ------- =_aaaaaaaaaa0--   Received: from tis.com by magellan.TIS.COM id aa19460; 28 Oct 93 19:23 EDT Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA10115; Thu, 28 Oct 93 19:23:37 EDT Received: by relay.tis.com; id AA10940; Thu, 28 Oct 93 19:21:06 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.0mjr) id sma010938; Thu Oct 28 19:20:51 1993 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 28 Oct 1993 16:23:13 -0700 Date: Thu, 28 Oct 1993 16:23:13 -0700 From: Jon Postel Message-Id: <199310282323.AA04622@zephyr.isi.edu> To: dns-security@tis.com Subject: DNS Security Sub-Working Group Cc: postel@isi.edu Jim: I'd like to be in the meeting. I could be available in the early afternoon of Wed or morning or early afternoon of Thurs. --jon.   Received: from tis.com by magellan.TIS.COM id aa20332; 28 Oct 93 23:08 EDT Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA13953; Thu, 28 Oct 93 23:08:52 EDT Received: by relay.tis.com; id AA12108; Thu, 28 Oct 93 23:06:21 EDT Received: from brazos.is.rice.edu(128.42.42.2) by relay via smap (V1.0mjr) id sma012106; Thu Oct 28 23:05:47 1993 Received: by brazos.is.rice.edu (AA10333); Thu, 28 Oct 93 22:08:15 CDT From: William Manning Message-Id: <9310290308.AA10333@brazos.is.rice.edu> Subject: mtg To: dns-security@tis.com Date: Thu, 28 Oct 1993 22:08:14 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 190 I'll be there. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892   Received: from tis.com by magellan.TIS.COM id aa28090; 1 Nov 93 13:32 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA12928; Mon, 1 Nov 93 13:31:49 EST Received: by relay.tis.com; id AA15279; Mon, 1 Nov 93 13:29:11 EST Received: from mgm.ctt.bellcore.com(128.96.128.250) by relay via smap (V1.0mjr) id sma015273; Mon Nov 1 13:28:12 1993 Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA18712 (5.65c/IDA-1.4.4 for ); Mon, 1 Nov 1993 13:30:45 -0500 Received: by shadow.secure.bellcore.com id AA27326 (5.65c/IDA-1.4.4 for dns-security@tis.com); Mon, 1 Nov 1993 12:43:54 -0500 Date: Mon, 1 Nov 1993 12:43:54 -0500 From: Steve Lunt Message-Id: <199311011743.AA27326@shadow.secure.bellcore.com> To: dns-security@tis.com Subject: Re: DNS Security Sub-Working Group It seems that from this initial charter that several goals/security services are being confused. > Unresolved Issues for DNS Security > > 2. Insofar as PEM is a technology that provides key management services, > the DNS could make use of it to distribute certificates. ... As I understand things, PEM is designed for store-and-forward environments, and key management defined therein is intended to support that environment. Perhaps direct use of authentication mechanisms as defined within the Internet (e.g., Kerberos V5) which are intended for on-line, peer-to-peer authentication should be used instead. > The following subissues are relevant to this discussion. > > a. If the DNS is "secure", could we store/distribute just keys > in/with it, or do we need certificates? I see the DNS as being useful in acting as a name service in support of Kerberos V5 (e.g., realm-to-Kerberos server mappings, hostname-to-realm name mappings, etc.) and perhaps for other authentication mechanisms as well. I don't think that we need to define yet another authentication mechanism specifically for a particular application. > b. If we store certificates, and even large keys, their distribution > or inclusion in DNS replies may exceed the maximum size allowed. > Two suggestions have been made. First, we could propose a > parallen DNS-like server that does not have the limitation. > Second, we could specify MX-like records that point to "key" > manager services. Again, I don't think the DNS is the place to store this kind of stuff. > c. Could SNMP be used to distribute the key/certificates? Especially not here! -- Steve Steven J. Lunt lunt@bellcore.com Information Technology Security RRC 1L-213 Bellcore 444 Hoes Lane (908) 699-4244 Piscataway, NJ 08854   Received: from tis.com by magellan.TIS.COM id aa00213; 8 Nov 93 17:18 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA02814; Mon, 8 Nov 93 17:18:35 EST Received: by relay.tis.com; id AA00504; Mon, 8 Nov 93 17:15:50 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma000490; Mon Nov 8 17:14:59 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA08911 (5.65c/IDA-1.4.4 for ); Tue, 9 Nov 1993 09:17:39 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA29649; Tue, 9 Nov 93 09:18:31 EST Message-Id: <9311082218.AA29649@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Thoughts from Houston meeting Date: Tue, 09 Nov 93 09:18:30 +1100 From: David Woodgate These are some completely random thoughts I've had since the Houston meeting. I'd just like to see if they make any sense to anyone else. I probably haven't been added to this list yet, so I don't know if any postings have been made since the group's meeting last week. So I apologise if I'm repeating anything that's already been said. (i) Performance vs Guaranteed Authentication I'm not sure that we discussed performance issues last week. As the use of network services can frequently involve many successive DNS lookups, significant increases in resolution time would appear to the users as major reductions in service performance. However, guaranteed security is paramount ( otherwise there is not much point in undertaking this exercise ). I believe that an additional requirement for any proposals is that the mechanisms be logically efficient, while not compromising authentication requirements. (ii) Extent of authentication Authentication will ultimately have to be guaranteed down to individual RRs - it has to be possible to uniquely and independently authenticate each record ( i.e. I don't want to have to download an entire zone to authenticate one record ). ( I know this goes a bit further than the requirement agreed at the meeting, which only extended down to individual nodes in a zone. ) I don't see this as necessarily difficult - for example, in a public key system, if certificates are only registered against SOAs, then the primary zone server when issuing records could apply a standard hash function to a record and encrypt the hashed result with the SOA's private key, and issue the resulting signature with the record. Note that this doesn't require any additional info to be added to the RR in the actual zone file, so this would have minimum administrative overhead. Then, wherever the authentication process is being undertaken, the authenticator hashes the RR info ( minus signature ) in the same way as the issuing server, and then uses the public key of the SOA to decrypt the signature, and compares the hash in the signature with its own calculation of the hash. This should protect against signatures being "snipped" off RRs and attached to false RRs. (iii) Guarantee of Currency This came from the revocation requirement. The only way I can think of to guarantee currency is by checking the serial number of the SOA at the origin of the SOA ( i.e. the primary zone server ). This is naturally irritating as it doesn't allow for redundancy in the case of network failures, however logically even a well-intentioned and official secondary can't give a 100% guarantee of currency except at zone refresh time, and in any case we've decided on a requirement not to trust the secondaries. One possible mechanism for implementing this would be to include the serial number of the SOA in an RR signature such as suggested in (ii). At authentication, the signature would be decrypted and the serial number retrieved. This would then be compared with the serial number of the SOA collected directly from the zone origin. Note that correct identification of the zone primary server would be a critical requirement, and would need to be a network address rather than a DNS name ( otherwise you can potentially enter resolution loops ). These addresses could either be included in the RR signature or in the public certificate. Also note that there is an assumption that address spoofing is not an issue. ( i.e. when I believe I'm connecting to the primary server, I am connecting to that server ). (iv) Network Failure handling. Just to clarify what was agreed at the meeting, I assume that the network failure requirement was to ensure continued operation in the event of network failure, rather than to ensure continued authenticated operation. That is, if there was network failure and authentication ceased to be an available option, then if resolution continued but with responses indicating that authentication was unavailable then this would be an acceptable proposal to the group. ( i.e. the programs take the responsibility for deciding how to handle unauthenticated resolutions ) This, of course, would require that programs have their interface altered to be able to distinguish between authenticated and unauthenticated resolutions, which would reduce the likelihood of a DNS security scheme being widely utilised. On the other hand, the alternative is to hang a program as soon as authenticated resolution cannot be achieved, which is probably unacceptable except in the most stringent environments. What probably should happen is that any proposals should have options for the handling of resolutions in the event of authentication being unavailable, and scope for future development in this. That's enough for now. David Woodgate davidw@its.csiro.au   Received: from tis.com by magellan.TIS.COM id aa00643; 9 Nov 93 2:02 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA16776; Tue, 9 Nov 93 02:02:11 EST Received: by relay.tis.com; id AA03645; Tue, 9 Nov 93 01:59:27 EST Received: from unknown(131.112.4.4) by relay via smap (V1.0mjr) id sma003643; Tue Nov 9 01:58:56 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 9 Nov 93 15:56:14 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311090656.AA01639@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: David Woodgate Date: Tue, 9 Nov 93 15:56:12 JST Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311082218.AA29649@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 9, 93 9:18 am X-Mailer: ELM [version 2.3 PL11] > These are some completely random thoughts I've had since the Houston > meeting. I'd just like to see if they make any sense to anyone else. At Houston, as there are too much meetings, I missed the DNS-security meeting. > Authentication will ultimately have to be guaranteed down to individual > RRs - it has to be possible to uniquely and independently authenticate > each record ( i.e. I don't want to have to download an entire > zone to authenticate one record ). ( I know this goes a bit further than > the requirement agreed at the meeting, which only extended down to > individual nodes in a zone. ) I think the unit should be set of all records of a single zone with the same RR type, which is also the current unit of DNS reply. > (iii) Guarantee of Currency > > This came from the revocation requirement. The only way I can think of to > guarantee currency is by checking the serial number of the SOA at the > origin of the SOA ( i.e. the primary zone server ). Or, as suggested in DNS WG meeting, use authenticated time (by, for example, authenticated ntp), which, I think, is better. > Also note that there is an assumption that address spoofing is not an > issue. ( i.e. when I believe I'm connecting to the primary server, I am > connecting to that server ). Is it acceptable? > (iv) Network Failure handling. > > Just to clarify what was agreed at the meeting, I assume that the network > failure requirement was to ensure continued operation in the event of > network failure, rather than to ensure continued authenticated operation. Really? > That is, if there was network failure and authentication ceased to be an > available option, then if resolution continued but with responses > indicating that authentication was unavailable then this would be > an acceptable proposal to the group. It seems to me that, whenever resolution is possible, authentication is also possible. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa01600; 9 Nov 93 10:20 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA29852; Tue, 9 Nov 93 10:20:36 EST Received: by relay.tis.com; id AA06762; Tue, 9 Nov 93 10:17:52 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma006755; Tue Nov 9 10:17:14 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA27838 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 02:19:39 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA22065; Wed, 10 Nov 93 02:20:31 EST Message-Id: <9311091520.AA22065@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Tue, 09 Nov 93 15:56:12 +0200." <9311090656.AA01639@necom830.cc.titech.ac.jp> Date: Wed, 10 Nov 93 02:20:31 +1100 From: David Woodgate >Or, as suggested in DNS WG meeting, use authenticated time (by, for example, >authenticated ntp), which, I think, is better. I still don't think this helps. Suppose the primary server timestamps an record - just because you receive it and can decode the time that the RR was issued doesn't mean that the record is still current at the primary ( refer Einstein :-) ). If you say that immediacy is not important, as long as the record was current to within an "acceptable" time, you then still have to argue over what is acceptable. Given that the delay between a record change and its propagation effectively represents a window of opportunity for malicious activity, such a delay cannot be long. I'm also concerned about the implications of interdependence between low level services ( here DNS and NTP ). I believe that it increases the complexity of the network mechanics and subsequently reduces its reliability. ( For example, you can't authenticate without timestamping, you can't timestamp without authentication ( to look up reliable time servers ) ). In addition, I'm not sure that authenticated NTP has the widespread deployment required to reasonably make it an integral part of DNS authentication. davidw   Received: from tis.com by magellan.TIS.COM id aa02017; 9 Nov 93 11:34 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA06208; Tue, 9 Nov 93 11:34:48 EST Received: by relay.tis.com; id AA07388; Tue, 9 Nov 93 11:32:03 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma007382; Tue Nov 9 11:31:56 1993 Received: by inet-gw-2.pa.dec.com; id AA06542; Tue, 9 Nov 93 08:34:38 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA16982 for dns-security@tis.com; Tue, 9 Nov 93 11:34:37 -0500 Message-Id: <9311091634.AA16982@skidrow.lkg.dec.com> To: David Woodgate Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Tue, 09 Nov 93 09:18:30 +1100." <9311082218.AA29649@steps.its.CSIRO.AU> Date: Tue, 09 Nov 93 11:34:37 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: David Woodgate To: dns-security@tis.com >... >(i) Performance vs Guaranteed Authentication > >I'm not sure that we discussed performance issues last week. As the use of >network services can frequently involve many successive DNS lookups, >significant increases in resolution time would appear to the users as major >reductions in service performance. However, guaranteed security is >paramount ( otherwise there is not much point in undertaking this exercise >). It was listed as a candidate requirement that the number of DNS queries not increase due to security. The amount of data retrieved will necessarily increase due to signature information. Another requirement was that the private key not be given to secondaries, etc., which implies pre-calculation of signatures, so there should not be any significant increase in query time. If RSA is used, it can be profiled so that decoding the signature is relatively fast in return for more effort in the precalculated encoding. >I believe that an additional requirement for any proposals is that the >mechanisms be logically efficient, while not compromising authentication >requirements. >(ii) Extent of authentication >Authentication will ultimately have to be guaranteed down to individual >RRs - it has to be possible to uniquely and independently authenticate >each record ( i.e. I don't want to have to download an entire >zone to authenticate one record ). ( I know this goes a bit further than >the requirement agreed at the meeting, which only extended down to >individual nodes in a zone. ) Although the meeting agreed that authentication of the bundle of RRs asscoiated with a particular name was adequate, I agree that authentication of the individual RRs is the way to go. I don't think anyone has proposed that you have to do a whole zone tranfer to get authentication. >I don't see this as necessarily difficult - for example, in a public key >system, if certificates are only registered against SOAs, then the primary >zone server when issuing records could apply a standard hash function to a >record and encrypt the hashed result with the SOA's private key, and >issue the resulting signature with the record. Note that this doesn't >require any additional info to be added to the RR in the actual zone file, >so this would have minimum administrative overhead. >Then, wherever the authentication process is being undertaken, the >authenticator hashes the RR info ( minus signature ) in the same way as the >issuing server, and then uses the public key of the SOA to decrypt the >signature, and compares the hash in the signature with its own calculation >of the hash. This should protect against signatures being "snipped" off >RRs and attached to false RRs. >(iii) Guarantee of Currency >This came from the revocation requirement. The only way I can think of to >guarantee currency is by checking the serial number of the SOA at the >origin of the SOA ( i.e. the primary zone server ). Isn't the DNS is built on the theory that currency within the TTL for an RR that is from a non-expired zone is adquate. There is no way to provide any absolute guarantee that data is exactly current so we will just have to see how well we can do. >This is naturally irritating as it doesn't allow for redundancy in the >case of network failures, however logically even a well-intentioned and >official secondary can't give a 100% guarantee of currency except at zone >refresh time, and in any case we've decided on a requirement not to trust >the secondaries. It was a requirement not to trust the secondaries with the private key but the information to authenticate the data must be with the data and secondaries are really not in that different a position than caches. >One possible mechanism for implementing this would be to include the >serial number of the SOA in an RR signature such as suggested in (ii). At >authentication, the signature would be decrypted and the serial number >retrieved. This would then be compared with the serial number of the SOA >collected directly from the zone origin. Yes, I think you need the serial # of the source zone in the RR signature. >Note that correct identification of the zone primary server would be a >critical requirement, and would need to be a network address rather than a >DNS name ( otherwise you can potentially enter resolution loops ). These >addresses could either be included in the RR signature or in the public >certificate. Since the whole thing is hierarchial, you may need IP addresses for root (or some other level if you are going to trust it to do authenticated upward retrievals for you) but I don't see that you need them elsewhere. The data is supposed to be authenticatable no matter where it is from. >Also note that there is an assumption that address spoofing is not an >issue. ( i.e. when I believe I'm connecting to the primary server, I am >connecting to that server ). Address spoofing is not particularly diffent from just injecting wrong data in response to queries. Either it authenticates, in which case you believe it, or it does not, in which case you discard it. There should be no need for authentication of who you are talking too. If they have the right keys, you believe them. The public key of root or whoever it is you are going to ultimately trust has to be distributed by some scheme outside of the main DNS security protocol. >(iv) Network Failure handling. >Just to clarify what was agreed at the meeting, I assume that the network >failure requirement was to ensure continued operation in the event of >network failure, rather than to ensure continued authenticated operation. >That is, if there was network failure and authentication ceased to be an >available option, then if resolution continued but with responses >indicating that authentication was unavailable then this would be >an acceptable proposal to the group. ( i.e. the programs take the >responsibility for deciding how to handle unauthenticated resolutions ) I thought the requirement was to be able to manually configure the public keys for a few nodes so you could operate with authenticated queries to those nodes anything reachable below them even if network failures stopped you from getting to any root servers, etc. >This, of course, would require that programs have their interface altered >to be able to distinguish between authenticated and unauthenticated >resolutions, which would reduce the likelihood of a DNS security scheme >being widely utilised. On the other hand, the alternative is to hang a >program as soon as authenticated resolution cannot be achieved, which is >probably unacceptable except in the most stringent environments. Until almost all DNS servers are secure, you will have the problem of getting back unauthenticated data which programs might wish to treat differently from authenticated data. Using only authenticated data when it is available will still be an improvement. Probably there should be some indicate at the entry in a zone where a subzone originates, along with the NS records, to indicate that the subzone is secure in which case unauthenticated responses for it should be considered bogus. >What probably should happen is that any proposals should have options for >the handling of resolutions in the event of authentication being >unavailable, and scope for future development in this. >That's enough for now. > David Woodgate > davidw@its.csiro.au Donald   Received: from tis.com by magellan.TIS.COM id aa02084; 9 Nov 93 11:39 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA06849; Tue, 9 Nov 93 11:39:46 EST Received: by relay.tis.com; id AA07419; Tue, 9 Nov 93 11:37:02 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma007414; Tue Nov 9 11:36:06 1993 Received: by inet-gw-2.pa.dec.com; id AA06852; Tue, 9 Nov 93 08:38:49 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA17015 for dns-security@tis.com; Tue, 9 Nov 93 11:38:48 -0500 Message-Id: <9311091638.AA17015@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Tue, 09 Nov 93 15:56:12 +0200." <9311090656.AA01639@necom830.cc.titech.ac.jp> Date: Tue, 09 Nov 93 11:38:47 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: David Woodgate Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311082218.AA29649@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 9, 93 9:18 am ... >> Authentication will ultimately have to be guaranteed down to individual >> RRs - it has to be possible to uniquely and independently authenticate >> each record ( i.e. I don't want to have to download an entire >> zone to authenticate one record ). ( I know this goes a bit further than >> the requirement agreed at the meeting, which only extended down to >> individual nodes in a zone. ) > >I think the unit should be set of all records of a single zone with the >same RR type, which is also the current unit of DNS reply. Isn't there a problem with truncation? I think you need to go to individual RRs. >> (iii) Guarantee of Currency >> >> This came from the revocation requirement. The only way I can think of to >> guarantee currency is by checking the serial number of the SOA at the >> origin of the SOA ( i.e. the primary zone server ). > >Or, as suggested in DNS WG meeting, use authenticated time (by, for example, >authenticated ntp), which, I think, is better. I also think, unfortunately, that absolute time will have to enter into the scheme. ... Masataka Ohta Donald   Received: from tis.com by magellan.TIS.COM id aa02128; 9 Nov 93 11:41 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA07035; Tue, 9 Nov 93 11:41:46 EST Received: by relay.tis.com; id AA07430; Tue, 9 Nov 93 11:39:02 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma007428; Tue Nov 9 11:38:58 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA29130 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 03:41:40 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA26223; Wed, 10 Nov 93 03:42:32 EST Message-Id: <9311091642.AA26223@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 00:48:31 +0200." <9311091548.AA04765@necom830.cc.titech.ac.jp> Date: Wed, 10 Nov 93 03:42:32 +1100 From: David Woodgate >> Given that the delay between a record change and its >> propagation effectively represents a window of opportunity for malicious >> activity, such a delay cannot be long. > >Could you explain how it can be a problem? Imagine an organisation that runs DNS with a TTL of 3600 ( this is low, my standard TTL is 24 hours ). Further, imagine I have an access point on the network and a computer at my disposal. I notice a DNS change - say a popular computer changes IP address. I quickly change the IP address of my own computer to the old address of the popular computer, and for the next hour I sit there pretending to be the popular computer, collecting passwords from the login attempts of people who didn't know about the address change and are still working on cached RRs. Yes, this is paranoid. But then isn't that the point of designing security enhancements? ( Otherwise we could leave things as they are ). It can be argued that the systems manager responsible for the popular machine in the example above could reduce TTL prior to making the change. However, I think that it is our role as protocol designers to make the securing of systems as easy as possible ( i.e. with the least amount of manual intervention being required ). davidw   Received: from tis.com by magellan.TIS.COM id aa02225; 9 Nov 93 11:49 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA07781; Tue, 9 Nov 93 11:49:47 EST Received: by relay.tis.com; id AA07516; Tue, 9 Nov 93 11:47:03 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma007513; Tue Nov 9 11:46:47 1993 Received: by inet-gw-2.pa.dec.com; id AA07559; Tue, 9 Nov 93 08:49:29 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA17111 for dns-security@tis.com; Tue, 9 Nov 93 11:49:29 -0500 Message-Id: <9311091649.AA17111@skidrow.lkg.dec.com> To: David Woodgate Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 02:20:31 +1100." <9311091520.AA22065@steps.its.CSIRO.AU> Date: Tue, 09 Nov 93 11:49:28 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: David Woodgate To: dns-security@tis.com In-Reply-To: Your message of "Tue, 09 Nov 93 15:56:12 +0200." <9311090656.AA01639@necom830.cc.titech.ac.jp> >>Or, as suggested in DNS WG meeting, use authenticated time (by, for example, >>authenticated ntp), which, I think, is better. >I still don't think this helps. Suppose the primary server timestamps an >record - just because you receive it and can decode the time that the RR was >issued doesn't mean that the record is still current at the primary ( refer >Einstein :-) ). >If you say that immediacy is not important, as long as the record was >current to within an "acceptable" time, you then still have to argue over >what is acceptable. Given that the delay between a record change and its >propagation effectively represents a window of opportunity for malicious >activity, such a delay cannot be long. Seems to me that the DNS is full of time fields which define just how critical currency is for a particular zone / RR. >I'm also concerned about the implications of interdependence between low >level services ( here DNS and NTP ). I believe that it increases the >complexity of the network mechanics and subsequently reduces its >reliability. ( For example, you can't authenticate without timestamping, >you can't timestamp without authentication ( to look up reliable time >servers ) ). In addition, I'm not sure that authenticated NTP has the >widespread deployment required to reasonably make it an integral part of >DNS authentication. I'm also concerned about having to bring in NTP. The current NTP authentication scheme used symetric cryptograhpy with a shared secret key, I believe, so it really isn't suitable. But it is hard to see how you can avoid some use of absolute time. If TTL's are crytograhically protected so they can't change unless you have the private key to recalculate the signature, then you need an absolute time to go with the TTL one way or another to tell what it really means. If TTL's are not protected, anyone can change them, although I suppose they could be considered invalid if extended beyond the current time plus the zone's refresh or something. > davidw Donald   Received: from tis.com by magellan.TIS.COM id aa02526; 9 Nov 93 12:48 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA12523; Tue, 9 Nov 93 12:48:56 EST Received: by relay.tis.com; id AA08038; Tue, 9 Nov 93 12:46:12 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma008034; Tue Nov 9 12:45:23 1993 Received: by inet-gw-2.pa.dec.com; id AA11372; Tue, 9 Nov 93 09:48:05 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA17527 for dns-security@tis.com; Tue, 9 Nov 93 12:48:04 -0500 Message-Id: <9311091748.AA17527@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Authentication granuality ( was Re: Thoughts from Houston meeting ) In-Reply-To: Your message of "Wed, 10 Nov 93 02:17:22 +0200." <9311091717.AA05222@necom830.cc.titech.ac.jp> Date: Tue, 09 Nov 93 12:48:04 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: dee@skidrow.lkg.dec.com (Donald E. Eastlake 3rd) In-Reply-To: <9311091638.AA17015@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Nov 9, 93 11:38 am >> >> Authentication will ultimately have to be guaranteed down to individual >> >> RRs - it has to be possible to uniquely and independently authenticate >> >> each record ( i.e. I don't want to have to download an entire >> >> zone to authenticate one record ). ( I know this goes a bit further than >> >> the requirement agreed at the meeting, which only extended down to >> >> individual nodes in a zone. ) >> > >> >I think the unit should be set of all records of a single zone with the >> >same RR type, which is also the current unit of DNS reply. >> >> Isn't there a problem with truncation? > >Yes, of course. About 100 bytes will be lost for the authentication. > >I think we need TCP or something like that. Anyway, number of queries >still do not change. But should the problem be addressed by this WG? True, long answers are not an explicit part of the DNS security charter but the problem seems to be getting more and more in the way. >> I think you need to go to >> individual RRs. > >Unfortunately, for the consistent operation of DNS related systems, it >is important to get all the RRs with the same type at once. > >For example, having part of MX RRs causes mail loop. Humm... doesn't this only apply to the answer section of the response? So all of the answer RRs of a particular type have to be present and have the same TTL. If an RR is of a type that could appear in the additional info section, you might not get a complete set but still want to authenticate some of them (Type A RR's are a good example when MXs are the answer). Furthermore, these considerations do not apply for inverse queries which can never guarantee completeness anyway so if you want authenticated inverse query answers, you need authentication to the RR level also. > Masataka Ohta Donald   Received: from tis.com by magellan.TIS.COM id aa02509; 9 Nov 93 12:47 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA12466; Tue, 9 Nov 93 12:47:56 EST Received: by relay.tis.com; id AA08028; Tue, 9 Nov 93 12:45:12 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma008022; Tue Nov 9 12:44:45 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA00408 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 04:47:26 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA29657; Wed, 10 Nov 93 04:48:18 EST Message-Id: <9311091748.AA29657@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 02:28:42 +0200." <9311091728.AA05276@necom830.cc.titech.ac.jp> Date: Wed, 10 Nov 93 04:48:18 +1100 From: David Woodgate >That's what can happen now, while the popular computer is powered down. The >seecurity hole has nothing to do with DNS. Your scenario of the popular computer being down has nothing to do with DNS. My scenario was that the DNS *had* changed, but people relying on it were still receiving false information. This is therefore DNS's problem. >Then, with the secure DNS, TCP connection to the popular computer is >authenticated using public key and the session will be protected with >session key. So, your scheme won't work, even if the computer is replaced >during the secure TCP session. This assumes that secure DNS is going to be used in conjunction with secure IP ( i.e. the IPSP protocol ). I'd expect that we just want to concentrate on the security implications of DNS by itself ( as much as possible ). davidw   Received: from tis.com by magellan.TIS.COM id aa02553; 9 Nov 93 12:59 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA13318; Tue, 9 Nov 93 12:58:58 EST Received: by relay.tis.com; id AA08124; Tue, 9 Nov 93 12:56:14 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma008114; Tue Nov 9 12:55:21 1993 Received: by inet-gw-2.pa.dec.com; id AA12128; Tue, 9 Nov 93 09:58:03 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA17637 for dns-security@tis.com; Tue, 9 Nov 93 12:58:02 -0500 Message-Id: <9311091758.AA17637@skidrow.lkg.dec.com> To: David Woodgate Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 03:42:32 +1100." <9311091642.AA26223@steps.its.CSIRO.AU> Date: Tue, 09 Nov 93 12:58:02 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: David Woodgate To: dns-security@tis.com In-Reply-To: Your message of "Wed, 10 Nov 93 00:48:31 +0200." <9311091548.AA04765@necom830.cc.titech.ac.jp> > >>> Given that the delay between a record change and its >>> propagation effectively represents a window of opportunity for malicious >>> activity, such a delay cannot be long. >> >>Could you explain how it can be a problem? > >Imagine an organisation that runs DNS with a TTL of 3600 ( this is low, >my standard TTL is 24 hours ). Further, imagine I have >an access point on the network and a computer at my disposal. I notice a >DNS change - say a popular computer changes IP address. I quickly change >the IP address of my own computer to the old address of the popular >computer, and for the next hour I sit there pretending to be the popular >computer, collecting passwords from the login attempts of people who >didn't know about the address change and are still working on cached RRs. That's just the way DNS works. >Yes, this is paranoid. But then isn't that the point of designing security >enhancements? ( Otherwise we could leave things as they are ). I think the important goal is to have authenicated DNS data, not to try to do things DNS wasn't designed to do. >It can be argued that the systems manager responsible for the popular >machine in the example above could reduce TTL prior to making the change. >However, I think that it is our role as protocol designers to make the >securing of systems as easy as possible ( i.e. with the least amount of >manual intervention being required ). It's really the network managers responsibility to be sure that no one can grab and old address like that. How is this different from just unplugging or crashing a machine at IP address X and then masquerading as it? Or just listening to the local Ethernet and grabbing password? DNS security is not going to solve all problems. If you try to telnet to x.y.z, DNS security can make sure that you get authentic info (within some time window) as to the existence of x.y.z and the IP address to connect to. That's it. It's up to the IPSEC working group to come up with an IP network level security protocol that authenticates that you are really, for example, sending packets to and getting packets back from that host and that these are encrypted if you don't want anyone in between to see the password you type. > davidw Donald   Received: from tis.com by magellan.TIS.COM id aa02581; 9 Nov 93 13:06 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA13827; Tue, 9 Nov 93 13:06:00 EST Received: by relay.tis.com; id AA08191; Tue, 9 Nov 93 13:03:15 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma008184; Tue Nov 9 13:02:28 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA00791 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 05:05:09 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA00840; Wed, 10 Nov 93 05:06:01 EST Message-Id: <9311091806.AA00840@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Tue, 09 Nov 93 12:58:02 CDT." <9311091758.AA17637@skidrow.lkg.dec.com> Date: Wed, 10 Nov 93 05:06:01 +1100 From: David Woodgate >DNS security is not going to solve all problems. True, but that doesn't mean that we shouldn't solve ( or at least attempt to solve ) DNS's security problems. ( After all, we are supposed to be a working group on DNS security! :-) ) davidw   Received: from tis.com by magellan.TIS.COM id aa02686; 9 Nov 93 13:23 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA15253; Tue, 9 Nov 93 13:22:59 EST Received: by relay.tis.com; id AA08362; Tue, 9 Nov 93 13:20:16 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma008341; Tue Nov 9 13:19:33 1993 Received: by inet-gw-2.pa.dec.com; id AA14074; Tue, 9 Nov 93 10:22:15 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA17943 for dns-security@tis.com; Tue, 9 Nov 93 13:22:14 -0500 Message-Id: <9311091822.AA17943@skidrow.lkg.dec.com> To: David Woodgate Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 04:48:18 +1100." <9311091748.AA29657@steps.its.CSIRO.AU> Date: Tue, 09 Nov 93 13:22:14 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: David Woodgate To: dns-security@tis.com In-Reply-To: Your message of "Wed, 10 Nov 93 02:28:42 +0200." <9311091728.AA05276@necom830.cc.titech.ac.jp> >>That's what can happen now, while the popular computer is powered down. The >>seecurity hole has nothing to do with DNS. >Your scenario of the popular computer being down has nothing to do with >DNS. My scenario was that the DNS *had* changed, but people relying on it >were still receiving false information. This is therefore DNS's problem. There is no way we are going to magically make DNS update propagation instantaneous. We could come up with a protocol where you did a DNS resolution to an IP address, say, then set up the TCP connection, then went back and checked that nothing had happened before you used the TCP connection, or something gross like that, but is really hopeless. What if it was a UDP packet you wanted to send? What if someone cuts off and replaces the remote machine between TCP packets? True, these threats are not DNS threats, exactly, but finding a magic way to fix them is DNS doesn't eliminate the same type of threat from non-DNS sources and is bacily impossible anyway. >>Then, with the secure DNS, TCP connection to the popular computer is >>authenticated using public key and the session will be protected with >>session key. So, your scheme won't work, even if the computer is replaced >>during the secure TCP session. >This assumes that secure DNS is going to be used in conjunction with >secure IP ( i.e. the IPSP protocol ). I'd expect that we just want to >concentrate on the security implications of DNS by itself ( as much as >possible ). Secure DNS and secure IP are different. DNS security just protects the authenticity of DNS information. The threats you are worried about, however, can only be fixed with IPSP or something like it. > davidw Donald PS: Further thought: What if DNS changes during a TCP connection? There is no inherent timeout built into TCP. To have a hope of "solving" this you need to remember every response sent out by DNS and reliably contact every inquirer and update them when the data changes. It's absolutely hopless! DNS security should provide some revocation mechanism but there will be strong limits on how much it can do.   Received: from tis.com by magellan.TIS.COM id aa02723; 9 Nov 93 13:35 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA16101; Tue, 9 Nov 93 13:35:02 EST Received: by relay.tis.com; id AA08494; Tue, 9 Nov 93 13:32:17 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma008490; Tue Nov 9 13:31:56 1993 Received: by inet-gw-2.pa.dec.com; id AA14981; Tue, 9 Nov 93 10:34:39 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA18067 for dns-security@tis.com; Tue, 9 Nov 93 13:34:38 -0500 Message-Id: <9311091834.AA18067@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) In-Reply-To: Your message of "Wed, 10 Nov 93 03:08:59 +0200." <9311091809.AA05537@necom830.cc.titech.ac.jp> Date: Tue, 09 Nov 93 13:34:38 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: dee@skidrow.lkg.dec.com (Donald E. Eastlake 3rd) Cc: dns-security@tis.com In-Reply-To: <9311091748.AA17527@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Nov 9, 93 12:48 pm >> True, long answers are not an explicit part of the DNS security charter >> but the problem seems to be getting more and more in the way. >Yes, we will need lengthy public keys everywhere just as the current >A records. At least, the host requirement RFC should be re-written >so that TCP, not SHUOLD but MUST, be supported. TCP is a general solution but pretty expensive in terms of resources. I have some ideas on how to indicate you can accept larger UDP packets which I'll try writing up as a draft. >> >> I think you need to go to >> >> individual RRs. >> > >> >Unfortunately, for the consistent operation of DNS related systems, it >> >is important to get all the RRs with the same type at once. >> > >> >For example, having part of MX RRs causes mail loop. >> >> Humm... doesn't this only apply to the answer section of the response? >Can you be sure something like MX won't appear in the additional >section in the future? If stuff is in the additional info section and the truncate bit is set, you know its incomplete. If it has to be consistent for your application, you just toss it, I guess. But in common cases like an MX query that also returns As, having the As for some of the MXed to hosts can clearly help in some cases and it is not important if you didn't get them all. >> So all of the answer RRs of a particular type have to be present and >> have the same TTL. If an RR is of a type that could appear in the >> additional info section, you might not get a complete set but still >> want to authenticate some of them (Type A RR's are a good example when >> MXs are the answer). > >Partial A records will, for example, make current weakly authenticated >gethostbyaddr() fail. But aren't there lots of way you can get partial A records? Like incomplete / out of date glue records? What do you mean "fail"? >> Furthermore, these considerations do not apply >> for inverse queries which can never guarantee completeness anyway so >> if you want authenticated inverse query answers, you need authentication >> to the RR level also. >Can't it be authenticated by the authenticated forward query? Yes, but a goal was not to have to do additional queries. >Anyway, I have never used the inverse query. Do you really need it? I don't know how much, if at all, inverse queries are used but they are part of the standard and it seems reasonable to support authentication of them. > Masataka Ohta Donald >PS >Perhaps we now are sharing most of the opinion except on copyright. :-) Perhaps so.   Received: from tis.com by magellan.TIS.COM id aa03853; 9 Nov 93 15:04 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA04555; Tue, 9 Nov 93 15:04:03 EST Received: by relay.tis.com; id AA09729; Tue, 9 Nov 93 15:01:17 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma009720; Tue Nov 9 15:01:00 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA08815 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 07:03:42 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA09297; Wed, 10 Nov 93 06:15:37 EST Message-Id: <9311091915.AA09297@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Tue, 09 Nov 93 13:22:14 CDT." <9311091822.AA17943@skidrow.lkg.dec.com> Date: Wed, 10 Nov 93 06:15:37 +1100 From: David Woodgate >There is no way we are going to magically make DNS update propagation >instantaneous. Exactly. Which is why if you want to guarantee the currency of the DNS record at resolution time, you need to check back directly to the primary source of the SOA ( i.e. back to my original point. ) Whether this would be an unacceptable overhead is a matter for this group to decide. >We could come up with a protocol where you did a DNS >resolution to an IP address, say, then set up the TCP connection, >then went back and checked that nothing had happened before you used >the TCP connection, or something gross like that, but is really hopeless. And irrelevant. All we are concentrating on is the validity of the data *at the time of resolution* ( which is all that DNS requires, methinks ). Changes in state after that point is not a DNS concern. >Secure DNS and secure IP are different. DNS security just protects >the authenticity of DNS information. Precisely. >The threats you are worried about, >however, can only be fixed with IPSP or something like it. I obviously chose a bad example. What I was trying to indicate was that if there is a potential to pick up invalid data ( and data which is not current is invalid ) during the process of a supposedly secure/authenticated DNS transaction, then the security measures have failed in their purpose ( and the working group has not met its objectives ). davidw   Received: from tis.com by magellan.TIS.COM id aa01749; 9 Nov 93 10:53 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA02590; Tue, 9 Nov 93 10:53:41 EST Received: by relay.tis.com; id AA07069; Tue, 9 Nov 93 10:50:57 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma007065; Tue Nov 9 10:50:30 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 00:48:32 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311091548.AA04765@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: David Woodgate Date: Wed, 10 Nov 93 0:48:31 JST Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311091520.AA22065@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 10, 93 2:20 am X-Mailer: ELM [version 2.3 PL11] > >Or, as suggested in DNS WG meeting, use authenticated time (by, for example, > >authenticated ntp), which, I think, is better. > > I still don't think this helps. Suppose the primary server timestamps an > record - just because you receive it and can decode the time that the RR was > issued doesn't mean that the record is still current at the primary ( refer > Einstein :-) ). > > If you say that immediacy is not important, No, of course. > as long as the record was > current to within an "acceptable" time, you then still have to argue over > what is acceptable. For individual queries, TTL is the acceptable time. For zone transfer, SOA expire period is the acceptable time. Both are configurable by local administrators. > Given that the delay between a record change and its > propagation effectively represents a window of opportunity for malicious > activity, such a delay cannot be long. Could you explain how it can be a problem? > I'm also concerned about the implications of interdependence between low > level services ( here DNS and NTP ). I believe that it increases the > complexity of the network mechanics and subsequently reduces its > reliability. ( For example, you can't authenticate without timestamping, > you can't timestamp without authentication ( to look up reliable time > servers ) ). Use glue (that is, configure the public key of NTP servers by hand or by floppy disk or through network with slight authentication such as passwords or check sums). > In addition, I'm not sure that authenticated NTP has the > widespread deployment required to reasonably make it an integral part of > DNS authentication. May be, it is better to attach GSP receivers to all the workstations. MO   Received: from tis.com by magellan.TIS.COM id aa02385; 9 Nov 93 12:23 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA10264; Tue, 9 Nov 93 12:22:50 EST Received: by relay.tis.com; id AA07750; Tue, 9 Nov 93 12:20:06 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma007728; Tue Nov 9 12:19:14 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 02:17:23 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311091717.AA05222@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: "Donald E. Eastlake 3rd" Date: Wed, 10 Nov 93 2:17:22 JST Cc: dns-security@tis.com In-Reply-To: <9311091638.AA17015@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 9, 93 11:38 am X-Mailer: ELM [version 2.3 PL11] > >> Authentication will ultimately have to be guaranteed down to individual > >> RRs - it has to be possible to uniquely and independently authenticate > >> each record ( i.e. I don't want to have to download an entire > >> zone to authenticate one record ). ( I know this goes a bit further than > >> the requirement agreed at the meeting, which only extended down to > >> individual nodes in a zone. ) > > > >I think the unit should be set of all records of a single zone with the > >same RR type, which is also the current unit of DNS reply. > > Isn't there a problem with truncation? Yes, of course. About 100 bytes will be lost for the authentication. I think we need TCP or something like that. Anyway, number of queries still do not change. But should the problem be addressed by this WG? > I think you need to go to > individual RRs. Unfortunately, for the consistent operation of DNS related systems, it is important to get all the RRs with the same type at once. For example, having part of MX RRs causes mail loop. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa02437; 9 Nov 93 12:33 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA11095; Tue, 9 Nov 93 12:33:55 EST Received: by relay.tis.com; id AA07880; Tue, 9 Nov 93 12:31:10 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma007874; Tue Nov 9 12:30:33 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 02:28:43 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311091728.AA05276@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: David Woodgate Date: Wed, 10 Nov 93 2:28:42 JST Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311091642.AA26223@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 10, 93 3:42 am X-Mailer: ELM [version 2.3 PL11] > >> Given that the delay between a record change and its > >> propagation effectively represents a window of opportunity for malicious > >> activity, such a delay cannot be long. > > > >Could you explain how it can be a problem? > > Imagine an organisation that runs DNS with a TTL of 3600 ( this is low, > my standard TTL is 24 hours ). Further, imagine I have > an access point on the network and a computer at my disposal. I notice a > DNS change - say a popular computer changes IP address. I quickly change > the IP address of my own computer to the old address of the popular > computer, and for the next hour I sit there pretending to be the popular > computer, collecting passwords from the login attempts of people who > didn't know about the address change and are still working on cached RRs. That's what can happen now, while the popular computer is powered down. The seecurity hole has nothing to do with DNS. Then, with the secure DNS, TCP connection to the popular computer is authenticated using public key and the session will be protected with session key. So, your scheme won't work, even if the computer is replaced during the secure TCP session. > Yes, this is paranoid. No. Not enough. > But then isn't that the point of designing security > enhancements? ( Otherwise we could leave things as they are ). Sure. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa02649; 9 Nov 93 13:14 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA14440; Tue, 9 Nov 93 13:14:01 EST Received: by relay.tis.com; id AA08293; Tue, 9 Nov 93 13:11:17 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma008285; Tue Nov 9 13:10:51 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 03:09:01 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311091809.AA05537@necom830.cc.titech.ac.jp> Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) To: "Donald E. Eastlake 3rd" Date: Wed, 10 Nov 93 3:08:59 JST Cc: dns-security@tis.com In-Reply-To: <9311091748.AA17527@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 9, 93 12:48 pm X-Mailer: ELM [version 2.3 PL11] > True, long answers are not an explicit part of the DNS security charter > but the problem seems to be getting more and more in the way. Yes, we will need lengthy public keys everywhere just as the current A records. At least, the host requirement RFC should be re-written so that TCP, not SHUOLD but MUST, be supported. > >> I think you need to go to > >> individual RRs. > > > >Unfortunately, for the consistent operation of DNS related systems, it > >is important to get all the RRs with the same type at once. > > > >For example, having part of MX RRs causes mail loop. > > Humm... doesn't this only apply to the answer section of the response? Can you be sure something like MX won't appear in the additional section in the future? > So all of the answer RRs of a particular type have to be present and > have the same TTL. If an RR is of a type that could appear in the > additional info section, you might not get a complete set but still > want to authenticate some of them (Type A RR's are a good example when > MXs are the answer). Partial A records will, for example, make current weakly authenticated gethostbyaddr() fail. > Furthermore, these considerations do not apply > for inverse queries which can never guarantee completeness anyway so > if you want authenticated inverse query answers, you need authentication > to the RR level also. Can't it be authenticated by the authenticated forward query? Anyway, I have never used the inverse query. Do you really need it? Masataka Ohta PS Perhaps we now are sharing most of the opinion except on copyright. :-)   Received: from tis.com by magellan.TIS.COM id aa03089; 9 Nov 93 14:30 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA02281; Tue, 9 Nov 93 14:30:11 EST Received: by relay.tis.com; id AA09044; Tue, 9 Nov 93 14:27:27 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma009039; Tue Nov 9 14:26:43 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 04:25:01 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311091925.AA05830@necom830.cc.titech.ac.jp> Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) To: "Donald E. Eastlake 3rd" Date: Wed, 10 Nov 93 4:25:00 JST Cc: dns-security@tis.com In-Reply-To: <9311091834.AA18067@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 9, 93 1:34 pm X-Mailer: ELM [version 2.3 PL11] > TCP is a general solution but pretty expensive in terms of resources. A little more packet and a lot more CPU, the latter does not matter in this case. > I have some ideas on how to indicate you can accept larger UDP packets > which I'll try writing up as a draft. Good luck. > >Can you be sure something like MX won't appear in the additional > >section in the future? > > If stuff is in the additional info section and the truncate bit is > set, you know its incomplete. Thus, the entire content is thrown away. > But in common cases like an > MX query that also returns As, having the As for some of the MXed to > hosts can clearly help in some cases and it is not important if you > didn't get them all. Do you want to do so? > >Partial A records will, for example, make current weakly authenticated > >gethostbyaddr() fail. > > But aren't there lots of way you can get partial A records? Not so much. > Like > incomplete / out of date glue records? That is the rare case. I think the treatment of glue records should be done much more careful than currently implemented. Anyway, to reduce partial records, nameservers are coded to prefer authoritative answer. > What do you mean "fail"? If there are some A records, it is assumed that there is no other As. > >> Furthermore, these considerations do not apply > >> for inverse queries which can never guarantee completeness anyway so > >> if you want authenticated inverse query answers, you need authentication > >> to the RR level also. > > >Can't it be authenticated by the authenticated forward query? > > Yes, but a goal was not to have to do additional queries. OK. > >Anyway, I have never used the inverse query. Do you really need it? > > I don't know how much, if at all, inverse queries are used but they > are part of the standard and it seems reasonable to support > authentication of them. OK. But inverse queries are purely optional. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa04989; 9 Nov 93 19:13 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA00699; Tue, 9 Nov 93 19:13:46 EST Received: by relay.tis.com; id AA12330; Tue, 9 Nov 93 19:11:02 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma012299; Tue Nov 9 19:10:03 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 09:07:55 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311100008.AA06914@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: David Woodgate Date: Wed, 10 Nov 93 9:07:50 JST Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311091915.AA09297@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 10, 93 6:15 am X-Mailer: ELM [version 2.3 PL11] > And irrelevant. All we are concentrating on is the validity of the data Wrong. All we need is public keys with corresponding secure private keys. As long as the private keys are secure, whether the public keys are a bit out of date or not does not matter at all. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa06430; 10 Nov 93 10:26 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA20115; Wed, 10 Nov 93 10:26:56 EST Received: by relay.tis.com; id AA18001; Wed, 10 Nov 93 10:24:12 EST Message-Id: <9311101524.AA18001@relay.tis.com> Received: from ccv1.bbn.com(128.89.4.29) by relay via smap (V1.0mjr) id sma017995; Wed Nov 10 10:23:37 1993 To: Masataka Ohta Cc: David Woodgate , dns-security@tis.com, davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of Wed, 10 Nov 93 09:07:50 +0200. <9311100008.AA06914@necom830.cc.titech.ac.jp> Date: Wed, 10 Nov 93 10:24:41 -0500 From: Steve Kent Masataka, I beg to difer with your assetion that "As long as the private keys are secure, whether the public keys are a bit out of date or not does not matter at all." What we are trying to do is to protect the information provided through the DNS, countering attacks on the integrity of that data. One means by which we may achieve this goal is by ensuring the accuracy of the binding between a public key and identifying information, and transitively, the binding between DNS data and its authorized supplier. Steve   Received: from tis.com by magellan.TIS.COM id aa06535; 10 Nov 93 11:07 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA21847; Wed, 10 Nov 93 11:07:00 EST Received: by relay.tis.com; id AA18293; Wed, 10 Nov 93 11:04:16 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma018290; Wed Nov 10 11:03:38 1993 Received: by inet-gw-2.pa.dec.com; id AA25407; Wed, 10 Nov 93 08:06:15 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA24613 for dns-security@tis.com; Wed, 10 Nov 93 11:06:13 -0500 Message-Id: <9311101606.AA24613@skidrow.lkg.dec.com> To: Masataka Ohta Cc: "Donald E. Eastlake 3rd" , dns-security@tis.com Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) In-Reply-To: Your message of "Wed, 10 Nov 93 04:25:00 +0200." <9311091925.AA05830@necom830.cc.titech.ac.jp> Date: Wed, 10 Nov 93 11:06:13 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: dee@skidrow.lkg.dec.com (Donald E. Eastlake 3rd) In-Reply-To: <9311091834.AA18067@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Nov 9, 93 1:34 pm >> TCP is a general solution but pretty expensive in terms of resources. >A little more packet and a lot more CPU, the latter does not matter >in this case. I agree that the CPU does not matter much. But you are replacing a query packet and a response packet with at least six TCP packets so you are tripling the number of packets to use TCP in the case where a somewhat longer UDP packet would do. >> >Can you be sure something like MX won't appear in the additional >> >section in the future? >> If stuff is in the additional info section and the truncate bit is >> set, you know its incomplete. >Thus, the entire content is thrown away. It is not always necessary to do that. >> >Partial A records will, for example, make current weakly authenticated >> >gethostbyaddr() fail. >> But aren't there lots of way you can get partial A records? >Not so much. >> Like >> incomplete / out of date glue records? >That is the rare case. I think the treatment of glue records should >be done much more careful than currently implemented. >Anyway, to reduce partial records, nameservers are coded to prefer >authoritative answer. >> What do you mean "fail"? >If there are some A records, it is assumed that there is no other As. >> >> Furthermore, these considerations do not apply >> >> for inverse queries which can never guarantee completeness anyway so >> >> if you want authenticated inverse query answers, you need authentication >> >> to the RR level also. >> >Can't it be authenticated by the authenticated forward query? >> Yes, but a goal was not to have to do additional queries. >OK. >> >Anyway, I have never used the inverse query. Do you really need it? >> I don't know how much, if at all, inverse queries are used but they >> are part of the standard and it seems reasonable to support >> authentication of them. >OK. But inverse queries are purely optional. So it does not matter if you don't implement them but you might as well be able to implement them to give authenticated answers. I think it will turn out to cost little to authenticate to the RR level. > Masataka Ohta Donald   Received: from tis.com by magellan.TIS.COM id aa06561; 10 Nov 93 11:15 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA22570; Wed, 10 Nov 93 11:15:02 EST Received: by relay.tis.com; id AA18357; Wed, 10 Nov 93 11:12:17 EST Message-Id: <9311101612.AA18357@relay.tis.com> Received: from ccv1.bbn.com(128.89.4.29) by relay via smap (V1.0mjr) id sma018352; Wed Nov 10 11:11:52 1993 To: Masataka Ohta Cc: David.Woodgate@its.csiro.au, dns-security@tis.com, davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of Thu, 11 Nov 93 00:57:08 +0200. <9311101557.AA12014@necom830.cc.titech.ac.jp> Date: Wed, 10 Nov 93 11:14:05 -0500 From: Steve Kent Masataka, When changing a public key in a certificate-based system, for whatever reason, the common practice is to employ a certificate revocation list, to announce the date of termination of use of the old key. Since we agree on the need to bind public keys to identifying info, e.g., a domain name, use of a certificate to do this, and then storing the certificate in the DNS, would be a standard approach to addressing this aspect of the problem. Steve   Received: from tis.com by magellan.TIS.COM id aa06610; 10 Nov 93 11:35 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA23405; Wed, 10 Nov 93 11:35:05 EST Received: by relay.tis.com; id AA18542; Wed, 10 Nov 93 11:32:20 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma018534; Wed Nov 10 11:31:48 1993 Received: by inet-gw-2.pa.dec.com; id AA27784; Wed, 10 Nov 93 08:34:30 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA24830 for dns-security@tis.com; Wed, 10 Nov 93 11:34:30 -0500 Message-Id: <9311101634.AA24830@skidrow.lkg.dec.com> To: David Woodgate Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 06:15:37 +1100." <9311091915.AA09297@steps.its.CSIRO.AU> Date: Wed, 10 Nov 93 11:34:30 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: David Woodgate To: dns-security@tis.com In-Reply-To: Your message of "Tue, 09 Nov 93 13:22:14 CDT." <9311091822.AA17943@skidrow.lkg.dec.com> > >>There is no way we are going to magically make DNS update propagation >>instantaneous. >Exactly. Which is why if you want to guarantee the currency of the DNS >record at resolution time, you need to check back directly to the primary >source of the SOA ( i.e. back to my original point. ) Whether this would >be an unacceptable overhead is a matter for this group to decide. No. No amount of checking can ever make sure that the data is "valid" in your sense at the completion of whatever checking you are doing. Because just before you think you are finished (i.e., have received the final packet involved) things could have changed again. >>We could come up with a protocol where you did a DNS >>resolution to an IP address, say, then set up the TCP connection, >>then went back and checked that nothing had happened before you used >>the TCP connection, or something gross like that, but is really hopeless. >And irrelevant. All we are concentrating on is the validity of the data >*at the time of resolution* ( which is all that DNS requires, methinks ). >Changes in state after that point is not a DNS concern. What do you mean by "timne of resolution"? When you send a query? When the query is received? When the response is sent? When the response is received? The original data can certainly be authoritatively changed between any two of these points in time. Whatever your definition, why do you think it essential to have absolutely perfect zero latency at the time of resolution when the data can change a microsecond later, well before any reasonable application could have actually used it? I suppose you could then sit there being happy because DNS was secure by your defintion but the application, if it stupidly requires the impossible absolutely always 100% up to date date, is still using invalid data by your definition, may still conenct to the wrong host, etc. So what's the point? You can define away this problem but it does not make it any less real. >>Secure DNS and secure IP are different. DNS security just protects >>the authenticity of DNS information. >Precisely. Authenticity means origin authentication which means the data was issued by the owner of the data. Not that the latency of updates is zero. >>The threats you are worried about, >>however, can only be fixed with IPSP or something like it. >I obviously chose a bad example. What I was trying to >indicate was that if there is a potential to pick up invalid data ( and >data which is not current is invalid ) during the process of a supposedly >secure/authenticated DNS transaction, then the security measures have >failed in their purpose ( and the working group has not met its >objectives ). The DNS defines permissible latency periods for update propagation. Data that has been current within those periods is *valid* by the DNS definition regardless of changes in the most authoritative version. The primary objective of this WG as decided at Houston was to provide data origin authentication. (It was also decided that some sort of recocation mechanism was a candidate requirement to announce such things as the compromise of private key. Such a compromise could allow someone to masquerade as the owner and thus invalidate the data origin authentication. And the requirment was, I think that such revocation should propagate with the same sort of time constant as the RR TTL's, etc.) The security measures do not have to make DNS perform any better than it would have with the current implementation except to be immune to spoofing by entities masquerading as DNS servers, entities masquerading as the owner of the data, DNS servers diddled not to decrement the TTL, entities injecting packets with forged source and destination addresses, etc. If it achieves this, i.e., achieves data origin authentication, it will have succeeded. > davidw Donald   Received: from tis.com by magellan.TIS.COM id aa08714; 10 Nov 93 16:26 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA06357; Wed, 10 Nov 93 16:26:28 EST Received: by relay.tis.com; id AA00638; Wed, 10 Nov 93 16:23:43 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma000632; Wed Nov 10 16:22:42 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA19932 (5.65c/IDA-1.4.4 for ); Thu, 11 Nov 1993 08:25:24 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA03625; Thu, 11 Nov 93 08:26:17 EST Message-Id: <9311102126.AA03625@steps.its.CSIRO.AU> To: dns-security@tis.com Cc: davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Wed, 10 Nov 93 11:34:30 CDT." <9311101634.AA24830@skidrow.lkg.dec.com> Date: Thu, 11 Nov 93 08:26:16 +1100 From: David Woodgate I think I've been leading people off the track a bit. The issue with currency is not how to minimise latency ( although I admit that that is how I've been making it look ). The real issue is how to cope with a server that maliciously holds a record indefinitely, without decrementing TTL. Timestamping the signature was one option suggested at Houston. I am suggesting that direct comparison with the primary server is another. The problem with timestamping is that you either need to: (i) Assume the use of authenticated time, and believe that everyone else is using it. Otherwise, suppose a primary DNS server had its clock become greatly advanced with respect to the rest of the world. A malicious server could collect a record from the primary ( with the advanced timestamp ), and then hold it until the record became valid ( i.e. until the world's time matched the timestamp in the record ). In other words, how do you ensure that the server's timestamp was valid in the first place? or (ii) Get records directly from the primary! :-) Then the maximum effect of client and server being out of sync would be to either reduce the TTL or invalidate records altogether ( when using the right timestamping techniques ). So I would claim that direct checking of the primary server is more reliable than timestamping, for the purpose of ensuring that a record has not been intentionally held by an intermediate server. davidw   Received: from tis.com by magellan.TIS.COM id aa06516; 10 Nov 93 11:04 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA21672; Wed, 10 Nov 93 11:04:00 EST Received: by relay.tis.com; id AA18284; Wed, 10 Nov 93 11:01:16 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma018268; Wed Nov 10 11:00:16 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 11 Nov 93 00:57:10 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311101557.AA12014@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: Steve Kent Date: Thu, 11 Nov 93 0:57:08 JST Cc: David.Woodgate@its.csiro.au, dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311101521.AA11883@necom830.cc.titech.ac.jp>; from "Steve Kent" at Nov 10, 93 10:24 am X-Mailer: ELM [version 2.3 PL11] > Masataka, > > I beg to difer with your assetion that "As long as the private > keys are secure, whether the public keys are a bit out of date or not > does not matter at all." OK. > What we are trying to do is to protect the > information provided through the DNS, countering attacks on the > integrity of that data. OK. > One means by which we may achieve this goal is > by ensuring the accuracy of the binding between a public key and > identifying information, and transitively, the binding between DNS > data and its authorized supplier. We should ensure the accurate binding between authentication information (public key) and identification information (domain name). An old public key, whose correspondiing private key is still secret, is good enough as the authentication information. Of course, when changing a key, the following steps are necessary so that authentication with either old or new key is possible. But it has nothing to do with a security hole. It is necessary so that authentication succeeds even with old key. 1) add new key to DNS 2) use old key but accept both new and old key until the change propagates 3) remove old key from DNS 4) use new key but accept both new and old key until the change propagates Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa10369; 10 Nov 93 23:46 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA21253; Wed, 10 Nov 93 23:46:06 EST Received: by relay.tis.com; id AA03879; Wed, 10 Nov 93 23:43:22 EST Received: from commsun.its.csiro.au(152.83.8.2) by relay via smap (V1.0mjr) id sma003877; Wed Nov 10 23:42:47 1993 Received: from steps.its.csiro.au by commsun.its.CSIRO.AU with SMTP id AA28695 (5.65c/IDA-1.4.4 for ); Thu, 11 Nov 1993 15:45:31 +1100 Received: by steps.its.CSIRO.AU (4.1/SMI-4.0) id AA25764; Thu, 11 Nov 93 15:46:24 EST Message-Id: <9311110446.AA25764@steps.its.CSIRO.AU> To: dns-security@tis.com, davidw@its.csiro.au Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Thu, 11 Nov 93 12:28:32 +0200." <9311110328.AA14629@necom830.cc.titech.ac.jp> Date: Thu, 11 Nov 93 15:46:23 +1100 From: David Woodgate >As already pointed out by Donald, you recursively need direct comparison >to the parent of the primary server to confirm that the server is the >current primary Not necessarily - it depends what information is kept with the public key certificate. If a certificate on a trusted certificate authority contains the info { zone, public key, primary server address }, then the trusted server address is retrieved at the same time as the trusted public key. ( So no additional lookups would be required ). So theoretically I think it's possible without excessive lookups. I just wonder about the feasibility of checking back to the primary server for each DNS call ( but then I wonder about the feasibility of timestamps ). davidw   Received: from tis.com by magellan.TIS.COM id aa10233; 10 Nov 93 22:21 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA19847; Wed, 10 Nov 93 22:21:02 EST Received: by relay.tis.com; id AA03393; Wed, 10 Nov 93 22:18:17 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma003391; Wed Nov 10 22:17:41 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 11 Nov 93 12:13:52 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311110314.AA14531@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: Steve Kent Date: Thu, 11 Nov 93 12:13:51 JST Cc: David.Woodgate@its.csiro.au, dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311101610.AA12087@necom830.cc.titech.ac.jp>; from "Steve Kent" at Nov 10, 93 11:14 am X-Mailer: ELM [version 2.3 PL11] > Masataka, > > When changing a public key in a certificate-based system, for > whatever reason, the common practice is to employ a certificate > revocation list, to announce the date of termination of use of the old > key. Can we consult the revocation list every time we use a key? Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa10283; 10 Nov 93 22:27 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA19873; Wed, 10 Nov 93 22:27:02 EST Received: by relay.tis.com; id AA03424; Wed, 10 Nov 93 22:24:17 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma003422; Wed Nov 10 22:23:52 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 11 Nov 93 12:20:31 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311110320.AA14573@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: "Donald E. Eastlake 3rd" Date: Thu, 11 Nov 93 12:20:29 JST Cc: David.Woodgate@its.csiro.au, dns-security@tis.com In-Reply-To: <9311101634.AA24830@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 10, 93 11:34 am X-Mailer: ELM [version 2.3 PL11] > The primary objective of this WG as decided at Houston was to provide > data origin authentication. Can someone tell me what was decided in Houston? Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa10301; 10 Nov 93 22:35 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA19985; Wed, 10 Nov 93 22:35:02 EST Received: by relay.tis.com; id AA03463; Wed, 10 Nov 93 22:32:17 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma003460; Wed Nov 10 22:31:16 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 11 Nov 93 12:28:34 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311110328.AA14629@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: David Woodgate Date: Thu, 11 Nov 93 12:28:32 JST Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311102126.AA03625@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 11, 93 8:26 am X-Mailer: ELM [version 2.3 PL11] > The issue with currency is not how to minimise latency ( although I admit If the latency WERE the security hole, minimizing it is NO good. The enire scheme is broken. > I am suggesting that direct comparison > with the primary server is another. As already pointed out by Donald, you recursively need direct comparison to the parent of the primary server to confirm that the server is the current primary, usually up to the root name servers, which makes your scheme quite impractical. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa10419; 11 Nov 93 0:25 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA22063; Thu, 11 Nov 93 00:25:09 EST Received: by relay.tis.com; id AA04107; Thu, 11 Nov 93 00:22:24 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma004105; Thu Nov 11 00:22:07 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 11 Nov 93 14:19:48 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311110520.AA15309@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: David Woodgate Date: Thu, 11 Nov 93 14:19:46 JST Cc: dns-security@tis.com, davidw@its.csiro.au In-Reply-To: <9311110446.AA25764@steps.its.CSIRO.AU>; from "David Woodgate" at Nov 11, 93 3:46 pm X-Mailer: ELM [version 2.3 PL11] > >As already pointed out by Donald, you recursively need direct comparison > >to the parent of the primary server to confirm that the server is the > >current primary > > Not necessarily - it depends what information is kept with the public key > certificate. If a certificate on a trusted certificate authority contains > the info { zone, public key, primary server address }, And TIME STAMP. > then Then, IF you have TRUSTED TIME, you can trust the certificate is the current one. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa11522; 11 Nov 93 10:25 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA05805; Thu, 11 Nov 93 10:25:40 EST Received: by relay.tis.com; id AA07556; Thu, 11 Nov 93 10:22:54 EST Message-Id: <9311111522.AA07556@relay.tis.com> Received: from ccv1.bbn.com(128.89.4.29) by relay via smap (V1.0mjr) id sma007554; Thu Nov 11 10:22:06 1993 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of Thu, 11 Nov 93 12:13:51 +0200. <9311110314.AA14531@necom830.cc.titech.ac.jp> Date: Thu, 11 Nov 93 10:24:29 -0500 From: Steve Kent Masakata, The model usually adopted in certificate-based systems is that one caches certificates and CRLs to avoid unnecessary fetches from directories, more or less the same idea underlying the DNS caching model. Certificates and CRLs (both the PEM version CRL and the most recently proposed X.509 CRL) carry the equivalent of validity intervals, expressed in GMT, to advise users when they MUST acquire newer versions. Users are free to fetch the latest version at any time, and the tradeoff of security vs. responsiveness can be different for different users and expressed in terms of their individual cache management parameters. So, yes, in principle, one checks the relevant CRLs every time one uses a key from a certificate. However, if one maintains a cache so that all of the entries have always been checked against the most recent CRLs available in the cache (and one fetches CRLs when the timestamp indicates that new ones will be available), then the checking is implicit in the cache management disclipline and there is no additional overhead when an entry is fetched from the cache. Steve   Received: from tis.com by magellan.TIS.COM id aa11210; 11 Nov 93 8:34 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA00513; Thu, 11 Nov 93 08:34:32 EST Received: by relay.tis.com; id AA06683; Thu, 11 Nov 93 08:31:47 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma006681; Thu Nov 11 08:31:18 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 11 Nov 93 22:28:58 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311111329.AA17524@necom830.cc.titech.ac.jp> Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) To: "Donald E. Eastlake 3rd" Date: Thu, 11 Nov 93 22:28:56 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9311101606.AA24613@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 10, 93 11:06 am X-Mailer: ELM [version 2.3 PL11] > >> TCP is a general solution but pretty expensive in terms of resources. > >A little more packet and a lot more CPU, the latter does not matter > >in this case. > > I agree that the CPU does not matter much. But you are replacing a query > packet and a response packet with at least six TCP packets so you are > tripling the number of packets to use TCP in the case where a somewhat > longer UDP packet would do. Yes, yes, yes. > >> >Can you be sure something like MX won't appear in the additional > >> >section in the future? > >> If stuff is in the additional info section and the truncate bit is > >> set, you know its incomplete. > >Thus, the entire content is thrown away. > > It is not always necessary to do that. Theoretically, I agree, no. But, the information is most certainly thrown away when the information is passed to application through library routines. Application rarely minds whether the result of lookup is from additonal section or not and always expect full set of the RRs. Also, as the truncated information can not be cached, it does not worth doing so. The fundamental problem of RR-wise authentication is that some malicious server can construct a subset of actual RRs and let others believe it is the full set. Though I don't think it is useful to compromize a system, it can, at least, cause mail loop. BTW, don't we need an authentication for the negatiive authoritative answer such as "no such records are available for the specified domain"? If some host is made believes that no public key is available for some hosts, it may back off to unauthenticated communication. The other problem of finely grained authentication is the total packet length. Each authentication unit has minimum length (say, 128 bytes) according to its key length. So, more coarsely grained record will result in much less packet size. > So it does not matter if you don't implement them but you might as well > be able to implement them to give authenticated answers. I think it will > turn out to cost little to authenticate to the RR level. That's fine. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa14162; 12 Nov 93 0:11 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA19903; Fri, 12 Nov 93 00:11:46 EST Received: by relay.tis.com; id AA15256; Fri, 12 Nov 93 00:09:00 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma015253; Fri Nov 12 00:08:13 1993 Received: by inet-gw-2.pa.dec.com; id AA26025; Thu, 11 Nov 93 21:06:19 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA09589 for dns-security@tis.com; Fri, 12 Nov 93 00:06:20 -0500 Message-Id: <9311120506.AA09589@skidrow.lkg.dec.com> To: Masataka Ohta Cc: "Donald E. Eastlake 3rd" , dns-security@tis.com Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) In-Reply-To: Your message of "Thu, 11 Nov 93 22:28:56 +0200." <9311111329.AA17524@necom830.cc.titech.ac.jp> Date: Fri, 12 Nov 93 00:06:20 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Ohta-san, From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9311101606.AA24613@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Nov 10, 93 11:06 am >> >> TCP is a general solution but pretty expensive in terms of resources. >> >A little more packet and a lot more CPU, the latter does not matter >> >in this case. >> >> I agree that the CPU does not matter much. But you are replacing a query >> packet and a response packet with at least six TCP packets so you are >> tripling the number of packets to use TCP in the case where a somewhat >> longer UDP packet would do. > >Yes, yes, yes. >> >> >Can you be sure something like MX won't appear in the additional >> >> >section in the future? >> >> If stuff is in the additional info section and the truncate bit is >> >> set, you know its incomplete. >> >Thus, the entire content is thrown away. >> >> It is not always necessary to do that. > >Theoretically, I agree, no. > >But, the information is most certainly thrown away when the information >is passed to application through library routines. > >Application rarely minds whether the result of lookup is from additonal >section or not and always expect full set of the RRs. Also, as the truncated information can not be cached, it does not worth doing so. > >The fundamental problem of RR-wise authentication is that some malicious >server can construct a subset of actual RRs and let others believe it is >the full set. Though I don't think it is useful to compromize a system, >it can, at least, cause mail loop. You are actually begining to convince me that the granularity of authentication could be all RR's with the same domain name, type, class, and TTL. (If the TTLs are different, the user has already either screwed up or correctly declared that you can usefully have an incomplete set. Even if all existing RRs have problems with out a complete set, there may be some future RR types for which this is not true.) >BTW, don't we need an authentication for the negatiive authoritative >answer such as "no such records are available for the specified domain"? >If some host is made believes that no public key is available for some >hosts, it may back off to unauthenticated communication. You are talking about a denial of service attack. These are notoriously hard to defend against. To authenticate the entire response, including header and query(s) would mean that the responding node has the private key on-line, something to be avoided. On the other hand, if the authoritative servers don't have the private key on line, since the entire response is not authenticated, anyone who could intercept the query could fabricate a negative repsonse showing nothing found. It seems like there are some responses for which your really have to have authentication, such as a zone transfer, or else someone along the path could edit out blocks, but possibly there are few such transactions where total response authentication is important. >The other problem of finely grained authentication is the total packet >length. Each authentication unit has minimum length (say, 128 bytes) >according to its key length. So, more coarsely grained record will >result in much less packet size. I had a scheme where it would not have used up that much packet space in many cases. But my scheme is also applicable to the granularity you are suggesting and the packets will be made smaller but autenticating bigger chunks. >> So it does not matter if you don't implement them but you might as well >> be able to implement them to give authenticated answers. I think it will >> turn out to cost little to authenticate to the RR level. > >That's fine. > > Masataka Ohta Donald   Received: from tis.com by magellan.TIS.COM id aa14028; 11 Nov 93 22:02 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA17384; Thu, 11 Nov 93 22:02:40 EST Received: by relay.tis.com; id AA14529; Thu, 11 Nov 93 21:59:54 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma014521; Thu Nov 11 21:59:23 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 12 Nov 93 11:57:04 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311120257.AA20674@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: Steve Kent Date: Fri, 12 Nov 93 11:57:02 JST Cc: dns-security@tis.com In-Reply-To: <9311111520.AA18061@necom830.cc.titech.ac.jp>; from "Steve Kent" at Nov 11, 93 10:24 am X-Mailer: ELM [version 2.3 PL11] > The model usually adopted in certificate-based systems is that > one caches certificates and CRLs to avoid unnecessary fetches from > directories, more or less the same idea underlying the DNS caching > model. In DNS, timeout period of each record is controlled by individual servers. Who controls the timeout period of CRL? > Certificates and CRLs (both the PEM version CRL and the most > recently proposed X.509 CRL) carry the equivalent of validity > intervals, expressed in GMT, to advise users when they MUST acquire > newer versions. The scheme is good if the validity period of certificate is a lot longer than the validity period of CRL. Another assumption of the scheme is that new CRL is accessible before the relatively short validity period of the current CRL expires. > Users are free to fetch the latest version at any > time, and the tradeoff of security vs. responsiveness can be different > for different users and expressed in terms of their individual cache > management parameters. With DNS, I think the validity period of CRL corresponds to TTL. Then, if some server want to know more precise information, it can get authoritative information by asking to original name servers. If some record does not present, it might be negatively cached. Masataka Ohta   Received: from tis.com by magellan.TIS.COM id aa14945; 12 Nov 93 9:54 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA03986; Fri, 12 Nov 93 09:54:46 EST Received: by relay.tis.com; id AA18742; Fri, 12 Nov 93 09:52:00 EST Message-Id: <9311121452.AA18742@relay.tis.com> Received: from ccv1.bbn.com(128.89.4.29) by relay via smap (V1.0mjr) id sma018738; Fri Nov 12 09:51:51 1993 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of Fri, 12 Nov 93 11:57:02 +0200. <9311120257.AA20674@necom830.cc.titech.ac.jp> Date: Fri, 12 Nov 93 09:54:05 -0500 From: Steve Kent Masataka, The issuer of a CRL controls its validity period, and that issuer is the same entity who issues the certificates that can be revoked by the CRL. Yes, one expects the validity period for certificates to be much longer than the rate of CRL issuance, or the scheme doesn't work well. Steve   Received: from tis.com by magellan.TIS.COM id aa14436; 12 Nov 93 7:13 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA27334; Fri, 12 Nov 93 07:12:56 EST Received: by relay.tis.com; id AA17109; Fri, 12 Nov 93 07:10:10 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma017088; Fri Nov 12 07:09:21 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 12 Nov 93 21:07:12 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311121207.AA23707@necom830.cc.titech.ac.jp> Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) To: "Donald E. Eastlake 3rd" Date: Fri, 12 Nov 93 21:07:11 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9311120506.AA09589@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 12, 93 12:06 am X-Mailer: ELM [version 2.3 PL11] > >BTW, don't we need an authentication for the negatiive authoritative > >answer such as "no such records are available for the specified domain"? > >If some host is made believes that no public key is available for some > >hosts, it may back off to unauthenticated communication. > > You are talking about a denial of service attack. These are > notoriously hard to defend against. To authenticate the entire > response, including header and query(s) would mean that the responding > node has the private key on-line, something to be avoided. On the > other hand, if the authoritative servers don't have the private key on > line, since the entire response is not authenticated, anyone who could > intercept the query could fabricate a negative repsonse showing > nothing found. It seems like there are some responses for which your > really have to have authentication, such as a zone transfer, or else > someone along the path could edit out blocks, but possibly there are > few such transactions where total response authentication is > important. If a negative response contains authenticated information of a list of all the RR types the domain have, I think the negative response on the non-existence of certain RR type can be authenticated. But, I have no idea on how NXDOMAIN reply from (unauthorized) secondary servers could be authenticated without trusting secondaries. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa19121; 19 Nov 93 13:31 EST Received: from magellan.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA16338; Fri, 19 Nov 93 13:30:58 EST Received: from localhost.tis.com by magellan.TIS.COM id aa19115; 19 Nov 93 13:31 EST Reply-To: James M Galvin To: dns-security@tis.com Subject: summary from Houston IETF Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_baaaaaaaaa0" Date: Fri, 19 Nov 1993 13:31:08 -0500 From: James M Galvin Message-Id: <9311191331.aa19115@magellan.TIS.COM> ------- =_baaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Introduction I've completed my update of the mailing list according to those who have sent mail to "dns-security-request". Unfortunately, those who checked the signup sheet have not been added since I need to wait for the Secretariat to forward those addresses to me. Anyway, enclosed below is my version of the summary of the meeting we had at the Houston IETF. In a separate note I will indicate the immediate priorities of this group. Enjoy, Jim ------- =_baaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Summary of Houston IETF Meeting The DNS Security design team of the DNS working group met for one morning at the Houston IETF. What follows is a summary of that meeting. The discussion began with a call for the threats that the members of the group were most concerned about. The list included the following: disclosure of the data - some expressed a desire to be able to encrypt the data in responses modification of the data masquerade of the origin of the data masquerade of a secondary - some expressed a desire to be able to reliably identify both peers in a zone transfer; this would provide the basis for controlling access to zone transfers During the discussion of these threats it was agreed to accept the following assumptions: DNS data is "public" backward/co-existence compatibility is required With respect to the first, accepting it set aside any further discussion of the threat of disclosure of the data. The second assumption is included explicitly to remind everyone that we do not want parallel DNS systems in the Internet. In addition, it was explicitly agreed that we would not address authentication of secondaries or access control issues. Thus, the current list of desired security services is: data integrity data origin authentication. It was noted that a digital signature mechanism would support the desired services. The meeting continued with a brainstorming period during which the desired functional requirements of a secure DNS were collected. This list does not represent mandatory functionality but, rather, it is desired functionality. It was agreed that this list was subject to discussion on the mailing list for a period of time that would conclude on November 30. The requirements are listed here in no particular order. - sites must be able to support at least their internal users in the presence of external network failures - it should be possible for a site to pre-configure other authoritative servers without having to query the "system" to find the server - it should be possible to request services only from security enhanced servers, only from non-security enhanced servers, or a indicate that either is acceptable - it should be possible to recognize security enhanced responses - it should be possible to assign cryptographic keys (make use of the security services) to leaf nodes in the DNS tree, i.e., fully qualified domain names - it should be possible to not trust secondary servers - a mechanism must exist for revoking cryptographic keys that works within the DNS time-to-live framework - security services should be supported with no additional DNS queries beyond what would be required if security was not supported - it must be possible to ensure that cached data expires according to its TTL The meeting concluded with agreement on the following three milestones. 1. The desired functional requirements are to be reviewed and agreed upon by November 30. 2. Strawman proposals that meet as many of the desired requirements as possible are due by January 31, 1994. 3. The group would produce a single, draft proposal at the next IETF meeting, March 1994. ------- =_aaaaaaaaaa0-- ------- =_baaaaaaaaa0--   Received: from sol.tis.com by magellan.TIS.COM id aa19205; 19 Nov 93 13:45 EST Received: from magellan.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA17265; Fri, 19 Nov 93 13:45:08 EST Received: from localhost.tis.com by magellan.TIS.COM id aa19199; 19 Nov 93 13:45 EST Reply-To: James M Galvin To: dns-security@tis.com Subject: New Business Date: Fri, 19 Nov 1993 13:45:17 -0500 From: James M Galvin Message-Id: <9311191345.aa19199@magellan.TIS.COM> There are 3 items to be completed on this mailing list before the next IETF meeting. 1. creation of a DNS security working group 2. review of functional requirements 3. distribution of strawman proposals 1. creation of a DNS security working group After the DNS security design team met I was approached by the service applications area director (Dave Crocker) and asked about making the security design team a working group distinct from the DNS working group. I agreed to chair the working group and as such was directed to begin the process of creating the working group. The first step is to draft a charter. I will do this and distribute it here for review on monday, 11/22. If anyone else feels strongly about whether I should be chair or if they would prefer to chair the working group, please contact either Dave Crocker or myself. 2. review of functional requirements As agreed at the meeting we had in Houston, I have distributed a summary that includes the desired functional requirements. That list is now open for discussion. Please use this mailing list to suggestions additions, deletions, or modifications to items on the list. You have until November 30 before the list is considered complete. 3. distribution of strawman proposals Recall from our meeting we agreed that once the list of requirements stabilizes, folks will have until January 31 to develop and distribute strawman proposals that meet as many of the desired functional requirements and support the required security services. As soon as they are available, we should use this mailing list to begin discussing their relative merits. The objective is to be able to produce a single proposal that represents the output of the working group at the Seattle IETF. That's it for now. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa23469; 24 Nov 93 7:37 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA26356; Wed, 24 Nov 93 07:36:50 EST Received: by relay.tis.com; id AA11466; Wed, 24 Nov 93 07:33:58 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma011464; Wed Nov 24 07:33:14 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 24 Nov 93 21:31:05 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311241231.AA16973@necom830.cc.titech.ac.jp> Subject: Re: Authentication granuality ( was Re: Thoughts from Houston meeting ) To: "Donald E. Eastlake 3rd" Date: Wed, 24 Nov 93 21:31:04 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9311120506.AA09589@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 12, 93 12:06 am X-Mailer: ELM [version 2.3 PL11] > To authenticate the entire > response, including header and query(s) would mean that the responding > node has the private key on-line, something to be avoided. Can't we assume that the nodes have their private keys on-line? The keys are quite frequently necessary for various authentication such as initiating secure TCP connection, I think. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24627; 24 Nov 93 8:53 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA28703; Wed, 24 Nov 93 08:52:55 EST Received: by relay.tis.com; id AA12252; Wed, 24 Nov 93 08:50:03 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma012242; Wed Nov 24 08:49:48 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 24 Nov 93 22:48:07 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311241348.AA17364@necom830.cc.titech.ac.jp> Subject: Re: summary from Houston IETF To: galvin@tis.com Date: Wed, 24 Nov 93 22:48:06 JST Cc: dns-security@tis.com In-Reply-To: <9311191331.aa19115@magellan.TIS.COM>; from "James M Galvin" at Nov 19, 93 1:31 pm X-Mailer: ELM [version 2.3 PL11] > - it should be possible to not trust secondary servers It seems to me that we must trust secondary servers for the authoritative answer of non existent domain. > - a mechanism must exist for revoking cryptographic keys that works > within the DNS time-to-live framework Isn't revoking related to DNS expire, not time-to-live, period? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa07086; 28 Nov 93 3:30 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA04544; Sun, 28 Nov 93 03:30:22 EST Received: by relay.tis.com; id AA07839; Sun, 28 Nov 93 03:27:29 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma007837; Sun Nov 28 03:27:08 1993 Received: by inet-gw-2.pa.dec.com; id AA17055; Sun, 28 Nov 93 00:26:34 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA05708 for dns-security@tis.com; Sun, 28 Nov 93 03:26:46 -0500 Message-Id: <9311280826.AA05708@skidrow.lkg.dec.com> To: David Woodgate Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Thu, 11 Nov 93 08:26:16 +1100." <9311102126.AA03625@steps.its.CSIRO.AU> Date: Sun, 28 Nov 93 03:26:46 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp David, From: David Woodgate To: dns-security@tis.com Cc: davidw@its.csiro.au In-Reply-To: Your message of "Wed, 10 Nov 93 11:34:30 CDT." <9311101634.AA24830@skidrow.lkg.dec.com> > >I think I've been leading people off the track a bit. > >The issue with currency is not how to minimise latency ( although I admit >that that is how I've been making it look ). >The real issue is how to cope with a server that maliciously holds a >record indefinitely, without decrementing TTL. Timestamping the signature >was one option suggested at Houston. I am suggesting that direct comparison >with the primary server is another. How to handle this is a very important question and there is no answer that does not involve trade offs. If you don't cryptographically protect the TTL, anyone caching the RR can do anything to it. If you do cryptographcially protect it, they only someone holding the private key, which you would prefer not to have on line, can change it. If it can't change, then the obvious thing to do is to convert it to an absolute time out by including a time stamp. But this has plenty of its own problems, some of which you point out. If you always have to go to the primary server, there is no point in caching at all. This seems completely contrary to the main concept of being able to independently authenticate the origin of data no matter where you find it and the idea of multiple servers/caches to spread the load. >The problem with timestamping is that you either need to: >(i) Assume the use of authenticated time, and believe that everyone > else is using it. Otherwise, suppose a primary DNS server had its > clock become greatly advanced with respect to the rest of the > world. A malicious server could collect a record from the primary > ( with the advanced timestamp ), and then hold it until the record > became valid ( i.e. until the world's time matched the timestamp > in the record ). In other words, how do you ensure that the > server's timestamp was valid in the first place? >or >(ii) Get records directly from the primary! :-) Then the maximum effect > of client and server being out of sync would be to either > reduce the TTL or invalidate records altogether ( when using the > right timestamping techniques ). An additional problem is that the presence of the time stamp means that many/most replies will be "different", at least they will if you have a "small" time granularity. This means that any server time stamping responses must have the private key on line or maybe have a (massive?) number of RR's with time stamps pre-signed... >So I would claim that direct checking of the primary server is more >reliable than timestamping, for the purpose of ensuring that a record has >not been intentionally held by an intermediate server. > > davidw >Message-Id: <9311110446.AA25764@steps.its.CSIRO.AU> >To: dns-security@tis.com, davidw@its.csiro.au >Subject: Re: Thoughts from Houston meeting >In-Reply-To: Your message of "Thu, 11 Nov 93 12:28:32 +0200." > <9311110328.AA14629@necom830.cc.titech.ac.jp> >Date: Thu, 11 Nov 93 15:46:23 +1100 >From: David Woodgate > > >>As already pointed out by Donald, you recursively need direct comparison >>to the parent of the primary server to confirm that the server is the >>current primary > >Not necessarily - it depends what information is kept with the public key >certificate. If a certificate on a trusted certificate authority contains >the info { zone, public key, primary server address }, then the trusted >server address is retrieved at the same time as the trusted public key. >( So no additional lookups would be required ). Having hard addresses buried in the certificates strikes me as a bad idea. I thought we were trying for data origin authentication where what was being authenticated was the authority of the source in terms of DNS zones. Other than denial of service possibilities, it should not matter if a server wanders from one address to another or if there is someone out there spoofing addresses on packets or the like. >So theoretically I think it's possible without excessive lookups. I just >wonder about the feasibility of checking back to the primary server for >each DNS call ( but then I wonder about the feasibility of timestamps ). I also worry about time stamps. There may yet be a way to use serial numbers... > davidw Donald   Received: from sol.tis.com by magellan.TIS.COM id aa17953; 29 Nov 93 13:02 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA13739; Mon, 29 Nov 93 13:01:42 EST Received: by relay.tis.com; id AA17622; Mon, 29 Nov 93 12:58:49 EST Message-Id: <9311291758.AA17622@relay.tis.com> Received: from ccv1.bbn.com(128.89.4.29) by relay via smap (V1.0mjr) id sma017620; Mon Nov 29 12:58:24 1993 To: "Donald E. Eastlake 3rd (Beast)" Cc: David Woodgate , dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of Sun, 28 Nov 93 03:26:46 -0500. <9311280826.AA05708@skidrow.lkg.dec.com> Date: Mon, 29 Nov 93 12:59:07 -0500 From: Steve Kent Donald, I think the best bet is to include absolute TTL values as part of the signed records from the authoritative source. This doesn't require use of online keys since the records can be signed offline (in advance). It doesn't require precise, secure distributed time sources if one expects the records will be relatively stable. However, it does introduce the usual "CRL problem," i.e., when an authoritative server wants to revoke a binding that is still valid, it has no easy means of ensuring that old records will be superceded. This gives rise to a tradeoff in setting TTL values. The tradeoff was always there, but in a security context the concerns about the presistance of old racords are potentially greater. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa23453; 29 Nov 93 21:30 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA08150; Mon, 29 Nov 93 21:30:33 EST Received: by relay.tis.com; id AA21296; Mon, 29 Nov 93 21:27:40 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma021290; Mon Nov 29 21:27:32 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 30 Nov 93 11:24:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311300224.AA14537@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: Steve Kent Date: Tue, 30 Nov 93 11:24:40 JST Cc: dee@skidrow.lkg.dec.com, David.Woodgate@its.csiro.au, dns-security@tis.com In-Reply-To: <9311291758.AA17622@relay.tis.com>; from "Steve Kent" at Nov 29, 93 12:59 pm X-Mailer: ELM [version 2.3 PL11] > Donald, > > I think the best bet is to include absolute TTL values as part > of the signed records from the authoritative source. An certificate expires with expiration period in SOA, not with TTL period. Otherwise, secodary servers are meaningless. > This doesn't > require use of online keys since the records can be signed offline (in > advance). We DO require online encryption by private keys for secure TCP/UDP. Moreover, one of the purpose of secure DNS is to make TCP/UDP secure. OK? BTW, though we need online encryption by private keys, we don't need private keys online. An encryption box connected to a host through RS232C (dumb interface is better, because it is secure) or SCSI (interface program of the box might be buggy) will be suffice to make a private key not online but encryption by the private key online. The box should have separate RS232C port to allow offline access to the private key (thus, IC cards are no good). The box might have its own logging facilities. > It doesn't require precise, secure distributed time sources > if one expects the records will be relatively stable. Precision is not a matter from the beginning. A minuite of precision will be enough for most purposes. We need secure time, it does not have to be so precise at all. > However, it > does introduce the usual "CRL problem," i.e., when an authoritative > server wants to revoke a binding that is still valid, it has no easy > means of ensuring that old records will be superceded. I don't think CRL schem works with DNS, because of secondaries. Instead, if someone want redemption, he should modify database of the primary and ask administrators of secondaries to clear thier zone copies. Or he may ask an administrator of the parent zone to remove NS records of secondaries with bogus copies. Then, after the TTL of the bogus records or the NS records of bogus secondaries expires, redemption succeeds. Isn't it enough? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa26333; 30 Nov 93 10:30 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA28492; Tue, 30 Nov 93 10:30:10 EST Received: by relay.tis.com; id AA00709; Tue, 30 Nov 93 10:27:15 EST Message-Id: <9311301527.AA00709@relay.tis.com> Received: from ccv1.bbn.com(128.89.4.29) by relay via smap (V1.0mjr) id sma000691; Tue Nov 30 10:26:56 1993 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of Tue, 30 Nov 93 11:24:40 +0200. <9311300224.AA14537@necom830.cc.titech.ac.jp> Date: Tue, 30 Nov 93 10:21:13 -0500 From: Steve Kent Masakata, A concern about online key use has to do with the keys used by authorities to sign DNS records. There are considerable vulnerabilites posed by having these keys comrpomised. This is different from the impact of compromise of keys for individual hosts. While one can imagine peripheral cryptographic hardware technology to support this sort of requirement (in fact, my company sells such technology), it is unrealistic to expect widespread use of such technology in the Internet for a long time. Thus many of us prefer a design which does not require keys to be available for realtime signing of DNS records. Ultimately, however, we will have to see what tradeoffs result from such design preferences. I'm not sure I understand your comments about CRL issues in this context. Could you elaborate? Steve   Received: from sol.tis.com by magellan.TIS.COM id aa26598; 30 Nov 93 11:32 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA02735; Tue, 30 Nov 93 11:32:08 EST Received: by relay.tis.com; id AA01170; Tue, 30 Nov 93 11:29:15 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma001165; Tue Nov 30 11:28:38 1993 Received: by inet-gw-2.pa.dec.com; id AA22568; Tue, 30 Nov 93 07:57:20 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA05484 for dns-security@tis.com; Tue, 30 Nov 93 10:57:34 -0500 Message-Id: <9311301557.AA05484@skidrow.lkg.dec.com> To: Masataka Ohta Cc: Steve Kent , David.Woodgate@its.csiro.au, dns-security@tis.com Subject: Re: Thoughts from Houston meeting In-Reply-To: Your message of "Tue, 30 Nov 93 11:24:40 +0200." <9311300224.AA14537@necom830.cc.titech.ac.jp> Date: Tue, 30 Nov 93 10:57:34 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: kent@bbn.com (Steve Kent) Cc: dee@skidrow.lkg.dec.com, David.Woodgate@its.csiro.au, dns-security@tis.com In-Reply-To: <9311291758.AA17622@relay.tis.com>; from "Steve Kent" at Nov 29, 93 12:59 pm X-Mailer: ELM [version 2.3 PL11] >> Donald, >> >> I think the best bet is to include absolute TTL values as part >> of the signed records from the authoritative source. >An certificate expires with expiration period in SOA, not with TTL period. >Otherwise, secodary servers are meaningless. I think Steve Kent was speaking of RR's, not certificates. >> This doesn't >> require use of online keys since the records can be signed offline (in >> advance). >We DO require online encryption by private keys for secure TCP/UDP. > >Moreover, one of the purpose of secure DNS is to make TCP/UDP secure. > >OK? > >BTW, though we need online encryption by private keys, we don't need >private keys online. > >An encryption box connected to a host through RS232C (dumb interface is >better, because it is secure) or SCSI (interface program of the box might >be buggy) will be suffice to make a private key not online but encryption >by the private key online. The box should have separate RS232C port to >allow offline access to the private key (thus, IC cards are no good). >The box might have its own logging facilities. This helps somewhat in that someone can't steal the key and use it elsewhere if they subvert the host; however, if you were thinking of having two way communications with this box, that is still less secure than having only one way communication from the box to the DNS server; i.e., keeping and updating the zone file on the box and carrying the signed/authenticated version over to the server periodically. >> It doesn't require precise, secure distributed time sources >> if one expects the records will be relatively stable. > >Precision is not a matter from the beginning. A minuite of precision will >be enough for most purposes. We need secure time, it does not have to be >so precise at all. I don't see the level of precision as making too much difference. If you are going to use real time, then it seems to me that the servers have to speak some sort of time protocol. Surveys have found that a noticeable fraction of machines have times that are off by days or weeks. This involves a significant increase in complexity whether the time protocol is trying to synchronize within a minute or within a second. Integrating the time protocol seems like the main problem to me rather than the moderately well understood details of trying to get the time protocol to work to any particular level of precision. >> However, it >> does introduce the usual "CRL problem," i.e., when an authoritative >> server wants to revoke a binding that is still valid, it has no easy >> means of ensuring that old records will be superceded. > >I don't think CRL schem works with DNS, because of secondaries. > >Instead, if someone want redemption, he should modify database of the >primary and ask administrators of secondaries to clear thier zone >copies. Or he may ask an administrator of the parent zone to remove >NS records of secondaries with bogus copies. Then, after the TTL of >the bogus records or the NS records of bogus secondaries expires, >redemption succeeds. Isn't it enough? That plus having some sort of contagious revokation RR that gets propagated is probably the best you can do. However, many people will still be unhappy that a wrong record can sit around for a long time if some server holds on to it and keeps using it and ignores these revokations/changes. A misbehaving server can certainly ignore TTL expirations if it wants to. And it is not clear how the parent zone will know that it needs to remove the NS records. It might take a long time to notice that the secondary is misbehaving. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa28832; 30 Nov 93 22:19 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA07063; Tue, 30 Nov 93 22:19:14 EST Received: by relay.tis.com; id AA06324; Tue, 30 Nov 93 22:16:21 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma006311; Tue Nov 30 22:15:29 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 1 Dec 93 12:13:10 +0900 From: Masataka Ohta Return-Path: Message-Id: <9312010313.AA20394@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: Steve Kent Date: Wed, 1 Dec 93 12:13:09 JST Cc: dns-security@tis.com In-Reply-To: <9311301526.AA17916@necom830.cc.titech.ac.jp>; from "Steve Kent" at Nov 30, 93 10:21 am X-Mailer: ELM [version 2.3 PL11] > Masakata, > > A concern about online key use has to do with the keys used by > authorities to sign DNS records. There are considerable > vulnerabilites posed by having these keys comrpomised. Could you elaborate? > This is > different from the impact of compromise of keys for individual hosts. It seems to me that, if a private key of a host of parent zone is compromized forged information on public keys for child zones could be delivered. > While one can imagine peripheral cryptographic hardware > technology to support this sort of requirement (in fact, my company > sells such technology), it is unrealistic to expect widespread use of > such technology in the Internet for a long time. If there are considerable valunerabilities, it is unrealistic, I think, not to expect widespead use of technologies to avoid the valunerabilities. > Thus many of us > prefer a design which does not require keys to be available for > realtime signing of DNS records. Ultimately, however, we will have to > see what tradeoffs result from such design preferences. Some protocols such as DHC expect timely registration of DNS. > I'm not sure I understand your comments about CRL issues in > this context. Could you elaborate? If SOA expire is for 2 weeks, information from secondaries should be relied for 2 weeks if a primary is disconnected from the network, which means that a new, daily updated, CRL can not be received. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa28855; 30 Nov 93 22:44 EST Received: from relay.tis.com by TIS.COM (4.1/SUN-5.64) id AA07344; Tue, 30 Nov 93 22:44:13 EST Received: by relay.tis.com; id AA06474; Tue, 30 Nov 93 22:41:20 EST Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.0mjr) id sma006472; Tue Nov 30 22:40:22 1993 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 1 Dec 93 12:37:02 +0900 From: Masataka Ohta Return-Path: Message-Id: <9312010337.AA20529@necom830.cc.titech.ac.jp> Subject: Re: Thoughts from Houston meeting To: "Donald E. Eastlake 3rd" Date: Wed, 1 Dec 93 12:37:00 JST Cc: kent@bbn.com, David.Woodgate@its.csiro.au, dns-security@tis.com In-Reply-To: <9311301557.AA05484@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Nov 30, 93 10:57 am X-Mailer: ELM [version 2.3 PL11] > >> I think the best bet is to include absolute TTL values as part > >> of the signed records from the authoritative source. > >An certificate expires with expiration period in SOA, not with TTL period. > >Otherwise, secodary servers are meaningless. > > I think Steve Kent was speaking of RR's, not certificates. Who signs the RR's? > This involves a significant increase in complexity whether the > time protocol is trying to synchronize within a minute or within a > second. It will be necessary to add a field "assured precision" to time protocols. But, the reset of the work is not so complex, I think. Ntp time, for example, will be precise upto accumulated turn around time to the stratum 1 server plus small drift of each local clocks. > propagated is probably the best you can do. However, many people will > still be unhappy that a wrong record can sit around for a long time if > some server holds on to it and keeps using it and ignores these > revokations/changes. A misbehaving server can certainly ignore TTL > expirations if it wants to. But, unless a recipient want to do so (say, by specifying a forwarder), unauthorized secondaries won't be accessed. Perhaps, TTL should also be signed by secondaries so that the recipient can say that they accessed the data from authorized secondaries. > And it is not clear how the parent zone > will know that it needs to remove the NS records. When a secondary is supposed to be misbehaving, its NS record should be removed. > It might take a > long time to notice that the secondary is misbehaving. Doesn't it take a long time either to notice that a primary is misbehaving? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa01226; 3 Feb 94 14:08 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04709; Thu, 3 Feb 94 14:08:42 EST Received: by relay.tis.com; id AA15896; Thu, 3 Feb 94 14:09:17 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma015881; Thu Feb 3 14:08:29 1994 Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA27487; Thu, 3 Feb 94 10:21:51 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA21020 for dns-security@tis.com; Thu, 3 Feb 94 13:22:55 -0500 Message-Id: <9402031822.AA21020@skidrow.lkg.dec.com> To: Stephen D Crocker Cc: Paul Lambert , Ran Atkinson , ip security mailing list , dns-security@tis.com Subject: Re: Emphasizing Key Mgmt In-Reply-To: Your message of "Thu, 03 Feb 94 11:27:20 GMT." <9402031627.AA26016@tis.com> Date: Thu, 03 Feb 94 13:22:55 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, I'm not sure what the right thing to do is but I expect to be posting a draft in connection with DNS security within a week which is quite relevant to some forms of key management. From: Stephen D Crocker To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net (ip security mailing list) In-Reply-To: Your message of "Thu, 03 Feb 94 08:07:27 MST." <00112.2843107862.63903@poncho.phx.sectel.mot.com> >Should we keep key management as a work item and goal within IPSEC or >consider some other arrangement? > >I'm open to starting a separate group to work on this. However, it >would obviously be a bit more complicated to have a distinct group >working on key management. I don't really see a need to multiply working groups yet. >A third alternative (after leaving this as is or starting a fresh >group) is to set up some sort of subgroup that's tied into IPSEC but >organized to make progress in the near future. > >Comments? > >Steve Donald   Received: from sol.tis.com by magellan.TIS.COM id aa01930; 3 Feb 94 15:10 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10158; Thu, 3 Feb 94 15:10:15 EST Received: by relay.tis.com; id AA17071; Thu, 3 Feb 94 15:10:50 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma017045; Thu Feb 3 15:09:55 1994 Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA06679; Thu, 3 Feb 94 11:09:48 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA21589 for dns-security@tis.com; Thu, 3 Feb 94 14:10:50 -0500 Message-Id: <9402031910.AA21589@skidrow.lkg.dec.com> To: kasten@ftp.com Cc: crocker@tis.com, Paul_Lambert@poncho.phx.sectel.mot.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net, dns-security@tis.com Subject: Re: Emphasizing Key Mgmt In-Reply-To: Your message of "Thu, 03 Feb 94 12:21:09 EST." <9402031721.AA12153@tri-flow.ftp.com.ftp.com> Date: Thu, 03 Feb 94 14:10:49 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Frank, From: kasten@tri-flow.ftp.com (Frank Kastenholz) To: crocker@tis.com Reply-To: kasten@ftp.com Cc: Paul_Lambert@poncho.phx.sectel.mot.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net >Steve, > >I'd suggest that you open a separate working group for key >management. Experience has tended to show that as the number of >items on a single working group's agenda increases, the probability >of the group coming to closure on things decreases. If you have one >group with two goals, the chair of the single group has to multiplex >his time over both goals. With two groups, each with its own goal, >each chair is free to concentrate on a single goal. An alternative >would be to serialize the effort, finish the first task before >addressing the second. If there are three groups going at once in ipsec, dns-security, and key management, I believe that many mail messages will be relevant to more than one group. I don't suppose they could have a common mailing list? >Yes, there is the inter-group coordination problem but that is what >the Area Director and the Area Directorates are for :-) >-- >Frank Kastenholz >FTP Software >2 High Street >North Andover, Mass. USA 01845 >(508)685-4000 Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05341; 4 Feb 94 11:08 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22253; Fri, 4 Feb 94 11:08:39 EST Received: by relay.tis.com; id AA27891; Fri, 4 Feb 94 11:09:15 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.0mjr) id sma027884; Fri Feb 4 11:08:54 1994 Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA26943; Fri, 4 Feb 94 07:56:40 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA27928 for dns-security@tis.com; Fri, 4 Feb 94 10:57:45 -0500 Message-Id: <9402041557.AA27928@skidrow.lkg.dec.com> To: Stephen D Crocker Cc: pem-dev@tis.com, dns-security@tis.com Subject: Re: Are X.500 names feasible? In-Reply-To: Your message of "Thu, 03 Feb 94 20:45:33 EST." <9402040145.AA00163@tis.com> Date: Fri, 04 Feb 94 10:57:44 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, From: Stephen D Crocker To: pem-dev@tis.com >-----BEGIN PRIVACY-ENHANCED MESSAGE----- >Proc-Type: 4,MIC-CLEAR >Content-Domain: RFC822 >Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE > kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh > HbGVud29vZA==,03 >MIC-Info: RSA-MD5,RSA,J6tn1R723rn6oOukG0uvbhCnavKAr27USL/sfQzOOzP > Usx6vDEqKSUVcvfOkC+FQ7rjpn072zusH73gwWAqNnAI2AxOn8IO6ow7ADYwq7d0 > rxQh6bQ68cg8C1wGnz2Jt > >The attached exchange between anish@ctt.bellcore.com and >Jueneman@gte.com is focused on the handling of nicknames. However, >the underlying assumption is that email addresses are the basic form >of identity used in the Internet. RFC-822 email address are the basic form of identification for network entities. If anything they are becoming more and more dominant. X.400 addresses has proven so impractical that there are proposals to just adopt RFC-822 names as valid X.400 names. >In my view, the introduction of X.500 distinguished names has been a >very troublesome venture, and I see no evidence that things will get >better. Quite a lot has to happen before X.500 names are genuinely >useful as the basis for identity on the net. DNs are hopeless. Anyone reading the tens of thousands of lines of pedantic disputation re DN diddle-shit that have gone by on this mailing list would be forced to that conclusion but it is also derivable from principles. Yes, you can construct an unambiguous name from naturally occuring names such as country, organization, person name, street address, etc., etc., etc. but to guarantee uniqueness you end up with something so long and complex it is useless for human beings and has to include so much junk that part of the DN will change so often that, for many applications, it just does not have the stability required for a useful "name". The way to go is a "resigtration" system with first come first serve allocation of hierarchial names. The DNS plus "user names" does this and always has. Although I don't want to go into too much detail here I have never seen any validity in the claims that we are "running out" of DNS names or that there will be serious problems due to name "conflicts". No problem I can forsee with email addresses could compare with the nightmare of puzzling your way through the morasses of ployglot X.500 stuff. Like most OSI "protocols" X.500 is so complex and allows so many options that its really just a way to claim there is a world wide directory standard but still give each directory authority so much freedom to go its own way that actually dealing with the resulting "world wide directory" will be an enormously difficuly artificial intelligence problem at best. The existence of local alias systems has no relavence at all to this. They are fine for personal abbrevations for freqeuntly used names but are no excuse for having impractial names to start with. Directories are relevant. A good directory scheme would be great. It could map from lots of attributes to the true name for an entity. You could use it to map to someting gross and useless like DNs. Or you could use it to map to something useful and reasonably susinct like an email address. Or both. Maybe whois++, which I have not looked at, or its successor can fill the need for a good directory. >Given the very serious difficulties of deploying PEM using X.500 >distinguished names, perhaps it's time to ask the question directly. >Do we want to shift over toward using email addresses in place of the >current regime of distinguished names? > >If we want to shift over toward using email names, then certificates >would bind email addresses to keys. There might exist directories >that map email addresses to more detailed information, but the email >address would be the principal handle by which keys would be >associated with people. email addresses are currently encodable in the DNS. You just replace the "@" with a "." and put a "\" before any "."s in the user name. certificates, keys, DNs, and other attributes can be added to the DNS under the email address as a name. See the DNS security draft I will be posting shortly. >Steve Donald >> > You seem to want to tie a certificate to an e-mail address, whereas >> > I would prefer to tie BOTH to a locally-known name or nickname, >> > regardless of how it gets delivered (i.e., to which one of several >> > possible mail boxes.) >> >> I agree totally with this point. However, I believe it would be the >> responsibility of the user agent to handle nickname-to-emailname aliasing. >> The responder should only have to know email addresses, since that's the >> generally accepted name scheme used in the mail world. Nicknames should be >> defined locally - can you imagine how large an alias file would get if a >> repository had to keep local aliases for all potential users? >> >> You'd still be able to use your nicknames, but they would have to be >> resolved into email names at the UA, the same way that email-to-DN mapping >> would have to be resolved prior to accessing the certificate. >-----END PRIVACY-ENHANCED MESSAGE-----   Received: from sol.tis.com by magellan.TIS.COM id aa10603; 23 Feb 94 13:59 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11986; Wed, 23 Feb 94 13:59:22 EST Received: by relay.tis.com; id AA27819; Wed, 23 Feb 94 14:00:16 EST Received: from inet-gw-3.pa.dec.com(16.1.0.33) by relay via smap (V1.3mjr) id sma027794; Wed Feb 23 13:59:59 1994 Received: from skidrow.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA24625; Wed, 23 Feb 94 10:51:58 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA01576 for dns-security@tis.com; Wed, 23 Feb 94 13:54:00 -0500 Message-Id: <9402231854.AA01576@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: dee@lkg.dec.com Subject: dns security drafts Date: Wed, 23 Feb 94 13:54:00 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Well, it took longer to get out than I thought and it could use work but here it is. I'm also submitting it to internet-drafts. Donald --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) INTERNET-DRAFT DNS Protocol Security Extensions 23 February 1994 Expires 22 August 1994 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Donald E. Eastlake 3rd & Charles W. Kaufman Status of This Document This draft, file name draft-ietf-dnssec-ek-00.txt, is intended to be become a standards track RFC. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the authors. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, its Working Groupsd and other organizations or individuals. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The Domain Name System has become a critical operational part of the Internet infrastructure yet it has no security mechanisms to assure data integrity or authentication. Extensions to the DNS protocol are proposed to provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are added to secured zones as resource records. They can be most efficiently handled by security aware servers but security can still be provided to security aware resolvers or applications even by non-security aware primary, secondary, and caching servers. In addition, the extensions provide for the storage of authenticated keys in the DNS, so that a security aware resolver can learn the authenticating key of zones in addition to those for which it is initially configured, and for other purposes. Finally, the extensions optionally provide for authentication of DNS protocol messages for additional security. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................1 Acknowledgements...........................................2 Table of Contents..........................................2 1. Introduction............................................4 2. Overview of the Protocol...............................4 2.1 Data Origin Authentication.............................4 2.1.1 Security Provided...................................4 2.1.2 The SIG Resource Record..............................5 2.1.3 The RSA Resource Record..............................6 2.1.4 Signers Other Than The Zone..........................6 2.1.5 Special Problems With Time-to-Live...................6 2.1.6 Improved Performance At The Expense Of Compatibility.7 2.2 DNS Message Authentication.............................8 3. Services, Requirement, and Non-Requirements.............9 3.1 Requirements...........................................9 3.2 Non-Requirements......................................11 4. The Security Desired & Security Available Bits.........12 5. The SIG Resource Record................................13 5.1 SIG RDATA Format......................................13 5.1.1 Signature Format....................................14 5.1.2 Signet Format.......................................15 5.1.2.1 Direct Resource Record Signets....................16 5.1.2.2 Direct Glue Record Signet.........................17 5.1.2.3 Hashed Resource Record(s) Signet..................17 5.1.2.4 Partial RR Set Flag Signet........................18 5.1.2.5 Partial SIG Set Flag Signet.......................19 5.1.2.6 AXFR Signets......................................19 5.1.2.7 Reserved Signet Prefixes..........................20 5.2 SIG RRs in the Construction of Responses..............20 5.3 Processing Responses with SIG RRs.....................21 5.4 File Representation of SIG RRs........................22 5.4.1 Size of Data........................................22 5.4.2 RR Numbering........................................22 5.4.3 SIG RR Scope........................................23 5.4.4 RRs Surpressed by a SIG RR..........................23 6. The RSA Resource Record................................25 6.1 RSA RDATA format......................................25 6.2 Types of DNS Names and Keys...........................26 6.3 RSA RR Flag Bits......................................26 6.4 RSA RRs in the Construction of Responses..............27 6.5 File Representation of RSA RRs........................28 7. How to Resolve Securely................................29 7.1 Boot File Format......................................29 7.2 Chaining Through Zones................................29 7.3 Secure Time...........................................30 8. Operational Considerations.............................32 8.1 Modulus Size Considerations...........................32 8.2 Key Storage...........................................32 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions 8.3 Key Generation........................................33 8.4 Key Lifetimes.........................................33 8.5 Key Revocation........................................33 8.6 Root..................................................34 9. Conformance............................................35 10. Security Considerations...............................36 References................................................36 Authors Addresses.........................................37 Expiration and File Name..................................37 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 1. Introduction [To be written] 2. Overview of the Protocol These DNS protocol extensions provide two distinct services: data origin authentication, described in section 2.1 below, and message authentication, described in section 2.2 below. In addition, the resource records added to support these authentication services permit the association of keys with DNS names. These keys could be used in support of other security services such as IP level security. 2.1 Data Origin Authentication There are two distinct aspects to the data origin authentication service. The purpose of the first is to add security; the purpose of the second is to improve performance when the first is used. Adding security requires no changes to the "on-the-wire" DNS protocol beyond the addition of two new resource types: signatures and keys. This service could be supported by existing resolver and server implementations so long as they could support the additional resource types. If signatures are always retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. The revisions to the DNS wire protocol for security aware servers are an attempt to mitigate that degradation by automatically sending exactly the signatures needed and by skipping the sending of the data if it can be derived from the signature. 2.1.1 Security Provided Security is provided by associating with each item of information in DNS a cryptographically generated digital signature. Commonly, there will be a single RSA key that signs for an entire zone. If the resolver reliably learns the public RSA key of the zone, it can verify that all the data read was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions The data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a secondary or caching server will not affect the degree of assurance that a resolver has that the data is genuine. However, such a server can (except in the case of a zone transfer) claim that a name does not exist and a resolver may not be able to determine otherwise. A resolver can learn the public key of a zone either by having it manually configured or by reading it from DNS. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus to provide any reasonable degree of security, the resolver must be configured with at least the public key of one zone. From that, it can securely read the public keys of other zones. It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change. 2.1.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 5. It includes the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time to live (which may be longer than its current time to live but cannot be shorter), and an RSA signature. There are a number of unusual aspects to the construction of the RSA signature that are intended to maximize performance in this application. Unlike some other digital signature schemes like El Gamal or DSS, RSA signatures have the property that when a signature is verified, it produces a message that is almost the size of the signature itself. In most uses, for example Privacy Enhanced Mail, the message to be signed is much larger than the signature (which is generally 64-256 bytes long), so a message digest of the message is computed (a 16-20 byte "fingerprint") and that quantity is signed. For DNS, however, it will be common that the messages being signed, will be very short - sometimes shorter than 16-20 bytes - particularly with the abbreviation techniques used herein. Further, there are commonly multiple resource records associated with a DNS name, and it should be efficient to verify a signature on a single one of those records or any subset of them. If a 64-256 byte signature record were created for every resource record, there would be an unacceptable explosion of data. The SIG Resource record syntax proposed therefore has two unusual properties: (1) when it signs a resource record, it may contain Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions either the resource record itself or a message digest of the resource record; and (2) a single signature may sign multiple multiple resource records associated with a single name. Every name in a zone supporting signed data will have associated with it one or more SIG resource records - as many as required to sign all of the non-SIG resource records. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will return with all records retrieved the corresponding SIG records. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name, verify them all, and find the one or ones that sign the resource records that resolver is interested in. As a further optimization, a server supporting the performance enhanced version of the protocol will return only the signature - and skip the requested data - in the case where the signature contains enough information to reconstruct the data in full. Because of this, in some cases the authenticated data being sent via SIG records can be shorter than the plain data would have been. 2.1.3 The RSA Resource Record The syntax of an RSA resource record (key) is described in Section 6. It is present for two reasons: to support the DNS infrastructure itself so that a resolver that is manually configured with the public keys of one or more zones can securely learn the public keys of other zone; and to allow the storing of RSA public keys of DNS-named entities other than zones for applications like IP-Security. 2.1.4 Signers Other Than The Zone There are two cases where a signature is generated by other than the zone private key. One is for future support of dynamic update where an entity is permitted authenticate/update its own record. The public key of the entity must be present in the DNS and signed with the zone key, but the other RRs may be signed with the entity's key. The other is for support of message authentication as described in 2.2 below. 2.1.5 Special Problems With Time-to-Live A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions time-to-live field tick down when resource records are cached. This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous secondaries to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can fail to decrement time to live like they are supposed to, but they cannot increase it beyond its original value. Separately, signatures include a time signed and an expiration time. A resolver that knows an absolute time can determine securely whether a signature has expired. In order to keep the data as compressed as possible, we don't want to have to include the original TTL for every resource record included in a SIG when usually they are all the same. We therefore assume that the original TTL is equal to the original TTL of the SIG resource record (which is sent for every SIG resource record), and in the rare case where the TTL on the other resource record differs we permit it to be explicitly included. 2.1.6 Improved Performance At The Expense Of Compatibility To run the high performance version of the protocol, the server should remember for each resource record: (1) which SIG record includes the signature for that record and (2) whether the SIG record contains the resource record in full or in digested form. When the server is responding to a request, it should for each record requested return the corresponding SIG (removing duplicates) and also it should suppress the sending of the record itself if it is present in the signature in undigested form. Since a resolver running the secure protocol will not believe any record that is not signed, there would be no point in returning the record without the SIG. And if the resolver is going to see the RR in full in the course of verifying the signature there is no point in wasting bandwidth by sending the RR being authenticated. The high performance version of the protocol can only be used if both resolver and server understand it. Negotiation is done via some DNS message header bits we believe that existing servers will ignore and existing resolvers will not set. If signature verification is not done by the DNS resolver code but rather by some application that is retrieving resource records through that resolver, the standard protocol must be used. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions 2.2 DNS Message Authentication The data origin authentication service described above protects resource records but provides no protection for message headers and limited protection against resource record addition to or deletion from a message. If header bits or, in some cases, the resource record set in a response, are falsely set by a server, there is little that can be done. However, it is at least possible to add message authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it is, a server can be sure it is getting requests from the resolver it thinks it is, and that in both cases these messages have not been diddled in transit. This is accomplished by adding a SIG resource record to end of the message which digitally signs the message by the server or resolver. The private key used belongs to the host composing the message, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because messages are highly variable, message authentication SIGs can not be precalculated. Thus it will be necessary to keep the key on-line, for example in software or in a directly connected piece of hardware. The best way to get the security provided by the message authentication service would be to use a good IP level security protocol. The authors of this draft decry the every growing number of IP application level security protocols such as Telnet, NTP, FTP, etc., etc. when a single IP-security protocol could secure most of these applications. Unfortunately, an IP-security standard has not yet been adopted. And even if it had, there will be many systems for many years where it will be hard to add IP security but relatively easy to replace the DNS components. Furthermore, the data original authentication service requires the implementation of essentially all the mechanisms needed for a rudamentary message authentication service. Thus a simple message authentication service using mechanisms already required by DNS security is included as a strictly optional part of these extensions. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions 3. Services, Requirement, and Non-Requirements This section is based on the 19 November 1993 email message from James M. Galvin summarizing the Houston IETF meeting of the DNS Security Working Group. At this meeting a list of requirements, shown in 3.1 below, and non-requirement shown in 3.2 below, were arrived at. The security services desired were set at the following: data integrity, and data origin authentication. It was noted at that meeting that these services can be provided by digital signatures. 3.1 Requirements The numbered items below were determined to be "requirements", not in the sense of being mandatory but in the sense of all being highly desirable. A comment appears after each requirement as to if/how it is met by this proposal. <1> Sites must be able to support at least their internal users in the presence of external network failures. Security aware resolvers can be configured with the public key of their local apex zone. The needed SIG RRs can be added to that zone and any desired lower level zones either off-line or on-line. Thus this requirement is met. <2> it should be possible for a site to pre-configure other authoritative servers without having to query the "system" to find the server. Security aware resolvers can be configured with the public key of any other zones and the IP address of their servers. <3> It should be possible to request services only from security enhanced servers, only from non-security enhanced servers, or a indicate that either is acceptable. These proposed protocol extensions do not provide any enhancement to the NS RR or otherwise to indicate whether or not a server is security aware without actually querying it. It is believed that this additional complexity is not warranted. Non-security aware servers can still support security aware resolvers, although less efficiently. It is possible to tell if a server is security aware by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions the SA (Security Available) bit in the header of its responses. <4> It should be possible to recognize security enhanced responses. Security enhanced responses can be recognized by the presence of SIG RRs. <5> It should be possible to assign cryptographic keys (make use of the security services) to leaf nodes in the DNS tree, i.e., fully qualified domain names. The proposed extensions allow RSA key RRs to be associated with any node in the DNS tree. Indeed, more than one key can be associated with a node which serves multiple functions. <6> It should be possible to not trust secondary servers. The proposed extensions can be implemented so that the zone private key is never on line on the network. Thus, ignoring denial of service threats, it is possible to have untrusted secondaries and even untrusted primaries. <7> A mechanism must exist for revoking cryptographic keys that works within the DNS time-to-live framework. A bit is defined in the RSA RR to indicate if it is a key assertion or key revocation and key revocations are opportunisticly flooded as additional information on every query to their zone if the resolver and server are security aware. However, an additional mechanism may be necessary to notify secondaries, caching servers, etc. to assure that a revocation is noticed within the TTL. This is really just a special case of a change in zone information and a general mechanism such as the NOTIFY operation described in draft-ietf-dns-ixfr-01.txt could be used. However, guaranteed revocation is not possible (for example in a partitioned network) without introducing unacceptable denial of service risks (such as having to wait "forever" to get a current "key revocation list" for a zone if the network is partitioned). <8> Security services should be supported with no additional DNS queries beyond what would be required if security was not supported. No additional queries are required, barring possible UDP truncation problems, to obtain authentication from or to securely learn the public key for a zone when its names servers are being obtain if a security enhanced server is being used by a security aware resolver. <9> It must be possible to ensure that cached data expires according to its TTL. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions A security aware resolver has both the TTL for an RR and the expiration time of the SIG covering the RR. Cached data is always invalid after the SIG expiration time plus the original TTL. 3.2 Non-Requirements It was explicitly decided by the DNS Security Working Group at the Houston IETF meeting that the following were not requirements: <1> Confidentiality: DNS data is "public" and no effort need be made to provide encryption of queries/responses. (This service may be available via an IP level security protocol which is currently being worked on by the IP Security Working Group of the IETF .) <2> Access control: DNS data is "public" and no effort need be made to provide access control lists, or similar mechanisms, as part of this DNS security effort. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions 4. The Security Desired & Security Available Bits The header section of DNS messages is modified to define bits 9 and 10 in the second word (fourth octet). These were formerly the top two bits of the Z field defined as "Reserved for future use." [RFC1035] These bits are defined as security desired, labeled SD, and security available, labeled SA. With the definition of these bits, the header looks like the following: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QR| Opcode | AA| TC| RD| RA| SD| SA| Z | RCODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QDCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ANCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | NSCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ARCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ All fields are as before except that the Z field is reduced to one bit and SD and SA are defined as follows: SD Security Desired - this bit may be set in a query. If the server to which the query is sent does not support the DNS security protocol, the bit should be ignored except that it may be copied into the response. If the server does support this protocol, the bit MUST copied into the response and, if the bit is set, the server MUST provide any SIG and KEY RRs as described in the sections below concerning these RRs. SA Security Available - this is to be set or cleared in a response. If set, it indicates that the server supports this security protocol. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions 5. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that resource records (and optionally message) are authenticated. The SIG RR unforgably binds one or more other RRs (or a DNS message) to a time and the signer's fully qualified domain name using cryptographic techniques and the signer's private key. The signer is the owner of the zone the RR originated from (or the composer of the authenticated DNS message). 5.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information and that of the SIG RRs owner, type, and class are protected by the signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signer's name | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sig length | / +-+-+-+-+-+-+-+-+ signature -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is xxx. The "signer's name" field is the fully qualified domain name of the signer of node generating the SIG RR. This is the zone which contained the RR(s) being authenticated (or the host which is the source of a DNS message that is being authenticated). The "original TTL" field is included in the RDATA portion to avoid authentication problems that caching servers would otherwise cause by decrementing the real TTL field and security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the real TTL field is not. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The SIG is valid until the signature expiration time which is a field of the same format as the time signed. The "sig length" field is an unsigned 8 bit count of the number of octets in the signature field. The structured of the "signature" field is described below. [It would be possible to allow additional optional fields after the above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 5.1.1 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, and expiration time of the RR to one or more RRs being authenticated (or to the entire DNS message in which it occurs). To accomplish this, it contains at least one "signet", as defined in the following section, and a "self-hash" field covering the above items. The structure of signets is described in section 5.1.2 below. The signature is then calculated using the RSA public key system as follows s = ( 01 | FF* | 00 | signets | self-hash ) ** e (mod n) where "|" is concatenation. "signets" is the concatenation of the signets included in this signature. "self-hash" is the 20 octet hash using the Secure Hash Standard [SHS] of the SIG RR name, class, signer name, original TTL, time signed, and expiration time. "e" is the secret key exponent of the signer, and "n" is the public modulus that is the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is less than the value of n. No FF octets need occur if "signets" is long enough. The order of the signets is not significant. The size of n, including most and least significant bits (which will be 1) SHALL be at least 641 and not more than 2040. n and e MUST be chosen such that the public exponent is less than 2**24 - 1 and SHOULD be chosen such that the public exponent is small. The above specifications are a profiling of PKCS #1 [PKCS1] except that, under most circumstances, one additional byte of data is Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions allowed. (A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem [ref], the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality.) 5.1.2 Signet Format Each signet consists of a prefix octet, with which the length of the signet can be unambiguously determined, followed by the signet data. Signet's are of three basic types: hashed, direct, and flag. A hashed signet consists of the prefix octet, some additional data, and a 20 bit hash of the data covered using the Secure Hash Standard [SHS]. Since this hash algorithm is not invertible, the data, such as RRs, covered by a hashed signet must also be included in the reply to a query if it was requested. A direct signet includes all of the data it covers. Some of the data may be implicit or compressed but it is all unambiguously recoverable. If a direct signet is present covering an RR, then that RR SHOULD be surpressed from the reply message if the SD bit is on in the query and the server is security aware. Flag signets occur with direct signets and multiple SIG RRs. They are used to determine if a complete set of RRs of a particular variety are present. Signet prefix octets are as follows: 0000000* Illegal 0LLLLLLL Direct Resource Record - type & rdata 10LLLLLL Direct Glue Record - name, type, & rdata 110***** (reserved) 1110**** (reserved) 11110NHT Hashed RR(s) - N, type, T, & hash 111110** (reserved 11111100 Partial SIG Set Flag 11111101 Partial RR Set Flag 1111111* Illegal In the above table, "*" represents 0 or 1 and L, N, H, and T are bits whose meaning is defined in the signet descriptions below. The Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.2.1 Direct Resource Record Signets This signet is an actual RR but with some fields surpressed. In order to avoid inconsistencies, all RRs of the same type and class have to have the same TTL, at least for currently defined RRs. SIG RRs need not survive beyond the RRs they authenticate but must live as long as the covered RRs do. Thus SIG RRs may be constrained to having the same TTL as the RRs they cover in most cases. The SIG RR will always have the same class and name as the RRs it covers(except for glue RRs as described in 5.1.2.2 and 5.1.2.3 below). Finally, the signet data length in the prefix octet can be used to calculate the RDSIZE. Thus RRs directly represented by this variety of signet are compressed by omitting their name, class, TTL, and RDLENGTH fields. Only the type, and RDATA are present. For example, the direct signet for a type A record in the IN (Internet) class would be seven octets as follows: 06 00 01 xx yy zz ww where 06 is the prefix indicating a direct RR signet with six data octets, 00 01 is hex for the type code for type A, and xx yy zz ww is the 32 bit IP address from the RR. These 7 octets in a SIG RR completely represent the 15+ (1+ name, 2 type, 2 class, 4 TTL, 2 rdlength, 4 ip address) octets of the original type A RR. The class, name, and TTL are all recoverable from the same fields of the SIG RR whose signature field includes this signet. Thus the original type A RR can be surpressed from the answer if given to a security aware resolver. Note that any names in the RDATA area of this type of signet can not be abbreviated by pointers outside of the reconstructed RR. That is because the SIG RR and its signets are frozen at the time the signature is encrypted under the signer's private key and this frozen SIG may then be used in a variety of DNS messages. The RDATA area may, however, if it has multiple names, abbreviate them by references to earlier names in the reconstructed RR. The direct representation of RRs makes maximum use of the relatively large size of RSA digital signatures for common cases. The direct representation also avoids the computational effort of calculating a hash code. Because the original RRs type field must always be present, the minimum length of the data after this type of signet prefix is 2, thus prefixes of 00 and 01 hex are illegal. The maximum size direct RR signet is 128 octets. All RRs need not be included within a signature using this direct Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions signet. If the data portion of a direct RR signet exceeds 22 octets (i.e., a total signet size of 23 octets including the prefix count octet), space inside the signature can be saved by going to the hashed RR signet described below. If an RR compressed for a direct signet exceeds 127 bytes or the amount of space available for signets in the signature part of a SIG RR, then it must appear separately and be authenticated by a hashed RR signet. 5.1.2.2 Direct Glue Record Signet Glue records must be handled a little differently. These are currently always A records with a name which usually isn't even in the zone being handled but are associated with an RR in the zone. This type of signet allows such glue RRs to be included within a SIG. The direct glue record signet is just like the direct resource record signet described above except that the name is included right after the prefix and before the type and RDATA. If the Glue Record signet won't fit, a hashed RR signet, described below, must be used. Note that names in the DNS can be up to 256 bytes long which would not fit inside a SIG RR signature field. 5.1.2.3 Hashed Resource Record(s) Signet RRs can also be protected by a signet with a hash code. If a hashed signet is used, all RRs of the same name, type, class, and TTL MUST be hashed into a single signet. To avoid inconsistencies, RRs of the same name, type, class, and TTL must either all be present or all be absent. Thus a single hash code covering such multiple RRs is all that is required. The signet is then formed by a single octet 11110NHT (binary) prefix followed by a possible name field depending on "N" and "H" as described below, the two octet type for the RRs covered, a possible TTL field depending on the values of "T" described below, and then the 20 octet hash code. The hash is calculated by concatenating the full RRs, with all names fully expanded and any required RDLENGTH adjustments made, in a canonical order, and applying the Secure Hash Standard [SHS]. The canonical order for RRs is to sort them in ascending order as left justified unsigned octet sequences where a missing octet sorts before a zero octet. Thus the hex sequences FE 01 02, 07, FF 03, FE FD, FF, and 01 01 01 01 would sort and be concatenated into the sequence 01 01 01 01 07 FE 01 02 FE FD FF FF 03. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions The "N" bit in the prefix stands for Name. It is normally zero because almost all RRs associated with a name in a zone have that name. The exception is glue records. These are currently A records with owner names outside the zone. To be able to cover these in a SIG for a different name where they cannot be included as a direct glue record signet as discussed in the section above, the N bit makes it possible to include the different name in the signet immediately after the prefix. If the N bit is a one but the H bit is zero, the name is included in full. Because names in DNS can be up to 256 bytes long, the 20 byte hash of the full name, using the Secure Hash Standard, can be used instead of the actual name and is indicated by turning on the H (or "hash") bit. To match this against RRs in the reply, their names must be hashed and compared. The "T" bit in the prefix stands for TTL. It is normally zero. For the presently defined RRs, all RRs of the same type, class, and name should have the same TTL. Future RRs may be defined for which it is useful for such RRs to have different TTL's. In that case the T bit must be one in the signet prefix octet, and the TTL of the hashed RR(s) included after the two octet type and before the hash code. If both the N and T bits are on, the name appears immediately after the prefix byte followed by the type, then the TTL, then the 20 byte hash code. This is the standard order for these fields in an RR. 5.1.2.4 Partial RR Set Flag Signet Verification of a hashed RR signet against the RR(s) included in the hash provides a guarantee that none have been omitted. The same assurance is not provided by the direct RR signet unless all of the direct RR signets of the same type and class are included in one SIG RR. If direct RR signets are split over more than one RR, they MUST be covered by a partial RR set flag signet in each RR. The partial RR set flag signet is indicated by a hex FC prefix followed a two octet type and then by a count octet. The most significant 4 bits (nibble) of this count octet indicates one less than the total number of SIG RRs that include all of the direct signets for the variety of RRs in question. The least significant nibble is used to distinguish the different SIG RRs required and varies from zero through the value of the first nibble. It is permissible, but unnecessary, to include a partial RR set flag signet prefix followed by the type and a zero byte (i.e., 1 of 1) in the SIG RR containing direct signets for all RRs of a particular varient. For example, an signet of FC000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions Should there be a case where more than 16 SIG RRs could be required to hold the direct signets for a particular variety of RR, direct signets may not be used. The RRs must appear directly in the DNS answer and a hashed signet must be used for authentication. 5.1.2.5 Partial SIG Set Flag Signet Since the SIG RRs for an owner name are not in themselves covered by yet another SIG (except for the case of zone transfers), a malicious server might choose to provide only some of them in response to a query for SIG RRs. The partial RR set flag signet defined above is not guaranteed to help here. The signet prefix of hex FD is followed by an unsigned byte which is one less than the total number of SIG RRs associated with the name and a second unsigned byte which varies from zero through the value of the first byte. It is permissible, but unnecessary, to include a partial SIG set flag signet prefix followed by two zero bytes (i.e, 1 of 1) if only one SIG RR is associated with a name. More than 256 SIGs many not be associated with the same name and class. 5.1.2.6 AXFR Signets To secure zone transfers, a SIG under the zone name will have a hashed RR signet with the AXFR type. It will be calculated by hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 5.1.2.3. This SIG, other than having to be calculated last of all zone key signed SIGs in the zone, is the same as any other SIG. It can contain non-AXFR signets, be numbered with the partial SIG set flag signet along with other zone level SIGs, if any, etc. Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity key rather than a zone key (see Section 6.2) are not included. They originate in the network and will not, in general, be migrated to the recommended off line zone signing procedure (see Section 8.2). Thus such dynamic RRs are not directly signed by the zone and are not generally protected against omission during zone transfers. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions 5.1.2.7 Reserved Signet Prefixes A number of signet prefixes are reserved for future allocation by the Internet Assigned Numbers Authority (IANA). All such signets will have an unsigned length octet immediately following their prefix code. This will be the length of the signet data not including the prefix or length octets. Thus their length can be unambiguously determined. Such signets are not to be generated by any implementation except for a use for which they have been allocated by IANA. Such signets are to be ignored on receipt by any implementation which does not understand them. 5.2 SIG RRs in the Construction of Responses SIG RRs MUST NOT be sent in response to a query where the SD header bit is clear unless the query specifically requests the SIG type. When the SD header bit is set, the DNS server MUST, for every RR the query will return, attempt to send the available SIG RRs which authenticates the requested RR. If multiple such SIGs are available, there may be insufficient space in the response to include them all. In this case, SIGs whose signer is the zone containing the RR MUST be given highest priority and retained even if SIGs with other signers must be dropped. Furthermore, this automatic inclusion of SIGs in a response is NOT additional information RR processing. To minimize possible truncation problems, if a SIG covers any RR that would be in the answer section of the response, it MUST appear in the answer section. If it covers an RR that would appear in the authority section and does not cover any answer section RR, it MUST appear in the authority section. If it covers an RR that would appear in the additional information section and does not cover any answer or authority section RR, it MUST appear in the additional information section. In many cases, as described below, the full authenticated RR will be included inside the SIG RR. In such cases, the DNS server SHOULD send only the SIG and surpress the directly requested RR. The server should assume that the inquirer has the necessary public key to authenticate RRs with the SIG and that, in general, an RR not covered by a SIG may be considered worthless by the inquirer. However, if a SIG including a full RR or an RR and its authenticating SIG will not fit in a response, but the RR alone will, a server MAY send the unauthenticated RR notwithstanding the set SD bit in the query header. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions Optionally, DNS messages may be authenticated by a SIG RR at the end of the message in the additional information section. Such SIG RRs are signed by the DNS server originating the message. 5.3 Processing Responses with SIG RRs If SIG RRs are received in response to a query specifying the SIG type, no special processing is required but a security aware client may wish to authenticate them by decoding the signature and applying consistency checks. If SIG RRs are received in any other response, a security aware client should decoded them using the public key of the signer and the data coded into the signature should be carefully examined. It should start with a 01 FF* 00 octet sequence (a 01 octet, zero or more FF octets, and a 00 octet) followed immediately by one or more concatenated signets and ending with the 20 byte self hash field matching the hash of the relevant SIG RR fields outside of the signature. If the decoded signature can not be parsed or the self hash check fails, the SIG RR is invalid and should be ignored. The time of receipt of the SIG RR must be in the inclusive range of the time signed and the signature expiration but the SIG can be retained and remains locally valid until the expiration time plus the range authenticated TTL. Next, the contents of the one or more direct RR, hashed RR, or flag signets present should be examined. For all direct RR signets, the original RR should be reconstructed if they are of a type that should have been retrieved by the query. If they are of another type, they can be optionally reconstructed or ignored. For all reconstructed RRs, there must be a complete set of partial set flag signets or all must be included in one SIG. For hashed RR signets, the hash should be computed from RRs present in the response and compared for authentication. Hashed RR signets for a type not requested in the query must be ignored. If the SIG RR is the last RR in a response in the additional information section, it may contain a hashed message signet covering the preceding data in the response. This should be checked and the message rejected if the check fails but it does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the originating zone can authenticate RRs. The hashed message signet merely protects from tampering between the DNS server and the resolver making the query. If all reasonable checks indicate that the SIG RR is valid then RRs reconstructed or verified by hash should be considered authenticated and all other RRs in the response should be considered with Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions suspicion. The probability that a SIG RR that has been tampered with (without knowledge of the secret key) will pass reasonable checks is vanishingly small (less than 1 in 2**150). If a SIG RR is received in the additional information section of a query, rather than a response, it can be optionally used to authenticate the query. Warning: many current implementations of the DNS ignore queries with a non-zero additional information count. A message authenticating SIG RR should NOT be included in a query unless you have outside knowledge that the queried system will permit it or have received a DNS message from the system with the SA bit on in the header. 5.4 File Representation of SIG RRs A SIG RR covering RRs can be represented as a single logical line in a zone data file [RFC1033] but there are some special problems as described below. (It does not make sense to include a message authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the message composing DNS host.) 5.4.1 Size of Data There is no particular problem with the signer and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL appears as an unsigned integer. However, the signature itself can be up to 255 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can be split between lines using the standard parenthesis. 5.4.2 RR Numbering A SIG RR stored in a zone file covers and in some cases surpresses a number of resource records via one or more direct or hashed signets. In order to represent this, RRs can be numbered by an integer field Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions enclosed in curly braces "{}". For compatibility with earlier DNS zone file implementations, this field can occur after all data fields but before any comments, and can be optionally preceded by a single pound sign ("#") immediately before the open curly brace ("{"). This "#" will cause the RR number to be treated as a comment by non- security aware servers but the "#{ number }" will be recognized by security aware servers. [give example] Actually, the RR number is the first subfield of three within the curly braces. As described below additional fields can occur separated by semi-colons (";"). 5.4.3 SIG RR Scope The RRs that are covered by a SIG RR are represented by a second sub-field inside the curly brace field which must be present for SIG RRs. This subfield consists of a comma and/or white space separated list of RR numbers, or ranges of the form n-m to indicates all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such covered RRs are numbered. The SIG RR should also be considered to cover any RRs that it surpresses as explained in the section below. The SIG RR itself need not be numbered unless it needs to be referred to. For example [give examples here] 5.4.4 RRs Surpressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should normally be surpressed when the SIG RR appears in a response. This is indicated in the zone data file by a third sub-field inside the curly brace field that may be present with SIG RRs and must be present if they have direct RR signets. As with the scope subfield, this subfield consists of a comma and/or white space separated list of RR numbers or ranges of the form n-m to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions indicate all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such surpressed RRs are numbered. An RR that is surpressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.2. [give example] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 6. The RSA Resource Record The RSA RR is used to document a public key that is associated with a DNS name. This can be a zone owner, the name of a DNS host for message authentication, or any DNS name. An RSA RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations should be designed to handle at least two simultaneously valid keys associated with a name and try both for decoding relevant SIG RRs to handle key roll over. The type number for the RSA RR is xxx. 6.1 RSA RDATA format The RDATA for a RSA RR consists of a start and end time, an octet of flags, the public exponent, and the public modulus. The format is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The time fields are unsigned in seconds since the start of 1 January 1970. The public key exponent is an unsigned 24 bit integer. The modulus length is an unsigned octet. This limits keys to a maximum of 255 bytes. A zero modulus length is special and indicates the specific assertion that there is no key associated with the owner. The public key modulus field is a multiprecision unsigned integer. The bits in the flag octet are described in Section 6.3 belows. [It would be possible to allow additional optional fields after the above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions 6.2 Types of DNS Names and Keys The same DNS name may refer to up to three things at present. For example, dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the mapping into a DNS name of the user dee@lkg.dec.com (although at present it is only the last of these three). Thus, the flag byte in the RSA RR has bits to indicate with which of these roles a public key is associated as described below. It is possible to use the same key for these different things with the same DNS name but this is discouraged. The case of the host or other end entity is further subdivided. One bit indicates that a key is generally associated with that entity. A second indicates that the key belongs to the end entity and is authorized to authenticate RRs for the end entity. In this case, the thing represented by the key is the same and it would be reasonable to use the same key for both the general and DNS updating / authenticating roles but the freedom is provided to use different keys. It would be desirable for the growth of DNS to be managed so that additional possible simultaneous uses for names are NOT added. New uses should be distinguished by exclusive domains. For example, all telephone numbers in the world have been mapped into the tpc.int domain of the operational DNS system. This is preferable to having the same name possibly be a telephone number and a host as well as a zone and a user, depending on the RRs present. 6.3 RSA RR Flag Bits Bit 0 (the most significant bit) a zero means the RSA RR asserts the validity of the public key from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the key as above. The strength of these assertions depends on the SIG RR(s), if any, authenticating the RSA RR. Bits 1 is the "mandatory" bit. Keys may be associated with zone or entities for experimental, trial, or optional use, in which case this bit will be zero. If this bit is a one, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is on for a zone, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. Similarly, if this bit were on for a host key and attempts to negotiate IP-security with the host produced indications that IP-security was not supported, it should be assumed that the host has been compromised or communications with it are being spoofed. On the other hand, if this bit were a zero, the host might very well sometimes operate in a secure mode and at other times Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions operate without the availability of IP-security. (This bit is meaningless in a revocation RSA RR.) Bits 2-3 are reserved and must be zero. If they are found non- zero, they should be ignored and the RSA RR used as indicated by the other flags. Bit 4 on indicates that this is a zone key for the zone whose name is the RSA RR owner name. This is the fundamental type of data origin authentication public key. Bit 5 on indicates that this is a key associated with the end entity whose name is the RR owner name by which that entity is authorized to authenticate DNS entries for itself. This assertion is, of course, only valid if the asserting RSA RR is signed by a valid zone key. This is intended to support certain types of dynamic update. Bit 6 on indicates that this is a key associated with the end entity whose name is the RR owner name. This will commonly be a host but could, in some part of the DNS tree, be some other type of entity. This is the public key used in connection with the optional message authentication service defined in this draft. It could also be used in an IP-security protocol where authentication of a host was desired. This would be useful in IP or other security for host level services such as DNS, NTP, routing, etc. Bit 7 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual in the SOA record: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated then through an RSA RR with name j\.random_user.host.subdomain.domain. It could be used in an IP-security protocol where authentication of a user was desired. This key would be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. 6.4 RSA RRs in the Construction of Responses A request for RSA RRs does not cause any additional information process because of these RSA RRs except, of course, for SIG RRs if security is requested and available. Security aware DNS servers will include RSA RRs as additional information in responses where security is requested under appropriate conditions as follows: Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions On the retrieval of NS RRs, the zone key RSA RR for the zone served by these name servers will be included. If not all additional info will fit, the RSA RR has higher priority than type A RRs. On retrieval of type A RRs, the end entity RSA RR for the host named will be included. On inclusion of A RRs as additional information, they will also be included but with lower priority than the relevant A RRs. On any retrieval with security requested and available from a zone, any revocation RSAs that fit will be included as additional information with low priority and the relevant SIGs for such revocation RSAs will also be included with lower priority than the RSA RRs they sign. 6.5 File Representation of RSA RRs RSA RRs may appear as lines in a zone data file. The time fields appear in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The flags field is represented as an unsigned integer. The public key exponent appears as an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 255 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can span lines using the standard parenthesis. The special case of a null key is indicated by a single zero digit. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions 7. How to Resolve Securely Retrieving or resolving secure data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS structure to the zone of interest. Such trusted public keys would normally be configured in a manner similar to that described in section 7.1. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point. 7.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: zonekey f.q.d.n exponent modulus for a zone public key or hostkey f.q.d.n exponent modulus for a host public key. f.q.d.n is the domain name of the zone or host, exponent is the public key exponent between 3 and 16777215, and modulus is the public key modulus in hex. Appropriate "start" and "end" times should be synthesized when the boot file is read. While it might seem logical for everyone to start with the key for the root zone, this has problems. The logistics of updating every DNS resolver in the world when the root key changes would be excessive. It may be some time before there even is a root key. And furthermore, some organizations may explicitly wish their "interior" DNS implementations to trust only their own zone. These interior resolvers can then go through the organization's zone server to access data outsize the organization's domain. If desired, the IP address for the f.q.d.n's with configured keys can generally also be configured via an /etc/hosts or similar local file. 7.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have them. Every secure zone (except root) should also include the RSA record for its super-zone signed by the secure zone. This makes it possible to climb the tree of zones if Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions one starts below root. A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data and data configured via a boot file should be given a distance number of zero. Should a query encounter different data with different distance values, that with a larger value should be ignored. A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure or only optionally secure by the present of an authenticated RSA RR for the non-secure zone with a zero length modulus or the presence of a non-zero length modulus RSA RR without the mandatory bit set. Otherwise the resolver could be getting completely bogus or spoofed replies. If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Never the less, continuing to apply secure checks withing "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. 7.3 Secure Time Coordinated interpretation of the time fields in SIG and RSA RRs requires that secure consistent time be available to the hosts implementing the DNS security extensions. The Network Time Protocol (NTP) [ref] provides an excellent means for coordinating consistent time. It also includes strong security but has no key management provisions. It just assumes that symmetric keying material will be on each pair of communicating nodes. In the absence of security, NTP or other time synchronization protocols could be spoofed. A solution to this would be to do NTP over IP-security. This may seem circular, where the security system is used to protect the synchronization of time needed for the security system. In practice, manual set up of approximate time would be adequate to bootstrap the system which could then securely synchronize itself more accurately. To accommodate the secure time requirement, all DNS servers should Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions also be NTP servers. NTP assumes that time servers are organized into numbered strata where the servers at each strata are clients to a lower numbered strata and servers to higher numbered strata. This can be accomplished in the DNS context by have each primary or secondary DNS server be an NTP client to the servers up the DNS tree from those zones they provide (ignoring zones that are subzones of other zones the server carries). Stub resolvers or the like could look to their default server for NTP service. Special arrangements would have to been made for the root primary and its secondaries to either have reliable hardware time sources or be secure clients to machines with such sources. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations 8.1 Modulus Size Considerations There are a number of factors that effect modulus size choice for use in the DNS security extension. Unfortunately, these factors do not all point in the same direction. Choice of a modulus size should be made by the zone administrator depending on their local conditions. Larger moduluses are more secure but slower. The recommended minimum modulus size, 641 bit, is believed by the authors to be secure at this time and for some years but high level nodes in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.) Because this protocol packs information inside an RSA signature, larger moduluses also increase the efficiency of use of space with SIG RRs. There is a 22 byte overhead (prefix and self hash) within the signature plus all the SIG RR fields outside of the signature. However, larger moduluses also lead to larger SIG RRs which may lead to lower packing density of SIG RRs in a maximum length DNS UDP packet. With the minimum modulus size required by this protocol, the signature before RSA encoding is 80 octets (usually resulting in 81 octets after encoding). After deducting 2 octets for the minimum 01 00 signature prefix and 20 octets for a hashed self signet, 56 octets would be available for other signets. With the maximum modulus size permitted by this protocol, the signature is usually 255 octets which leaves 233 bytes for other signets. Zones may wish to adopt policies on the size of host, user, or even subzone keys within them such that the RSA RRs for these keys will fit within a zone signed SIG for efficiency. 8.2 Key Storage It is strongly recommended that zone private keys and the zone file master copy be kept and used in off-line non-network connected machines. Periodically an application can be run to re-sign the RRs in a zone by adding SIG RRs and then the signed file transferred, perhaps by sneaker-net, to the networked server machine. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. The master copy of the zone file should also be off net and should not be updated based on a solely network mediated communication. 8.3 Key Generation Careful key generation is a sometimes over looked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Suggestions will be found in draft-ietf-security-randomness-01.txt. 8.4 Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. No DNS security extensions key should have a lifetime significantly over five years. The recommended lifetime for zone keys that are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended lifetime for host keys that are used for IP-security or the like and are kept on line is 35 days with the intent that they be replaced monthly. 8.5 Key Revocation In cases where an erroneous signed key exists in the DNS system, it is useful to be able to propagate a revocation. In most cases, the natural refresh processes of DNS will eventually obtain valid up to date key information for secondaries. However, there could be stale information out in caching servers or the like for a long time, particularly since accident or malicious action could have cause RRs, including SIGs, RSAs, etc., with very long TTLs and/or distant end- times to be distributed. There are limits to how much can be done about this problem. The DNS security extensions provide for revocation of keys. The revocation information is provided when current key information is retrieved. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions In addition, security aware servers opportunisticly flood revocation information by including it with low priority in the additional information section of any retrieval from the zone containing the revoked key. It is a matter of server policy how to choose which extra revocations to include as additional information. Some revocations may be "more important" than others or it may be best to simply pick as much as will fit at random. On receipt of an authenticated revocation, a resolver should expunge all RRs authenticated by the revoked key. It is a matter of resolver policy what revocations, if any, to cache and for how long. If a relavent revocation is received by a resolver but is not accompanied by an authenticating SIG, the resolver should normally attempt to retrieve such a SIG. Resolvers can not keep an indefinite number of revocations for an indefinite time. The possibility of denial of service attacks based on fabricating many revocations must be considered. It should be noted that like assertions, revocations have start and end times. Thus, for example, a valid key validly generated but accidentally given an excessive lifetime can be revoked for just the later part of that lifetime by setting appropriate times in the revocation RSA RR. 8.6 Root The root zone RSA key is self-signed. It should also be noted that in DNS the root is a zone unto itself. Thus the root key should only be see signing itself or signing RRs with names one level below root, such as .aq, edu, or .arpa. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance [this section needs work ...] - Security aware server needs to respond normally to requests that do not have the Security Desired bit set. [should response still have the Security Available bit set if SD wasn't?] - Minimal server compliance is ability to handle SIG and RSA RRs in zone files, etc. - Full server compliance is ability to handle SD and SA bits, automatically include SIG and RSA RRs in responses as appropriate, etc. - Resolver compliance... Donald E. Eastlake 3rd & Charles W. Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions 10. Security Considerations The entirety of this document concerns extensions to the Domain Name System (DNS) protocol to provide data origin authentication, DNS message authentication, and key storage. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, November 1987 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications [SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute of Science and Technology, U.S. Department of Commerce, April 1993. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions Authors Addresses Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Charles W. Kaufman Digital Equipment Corporation 110 Spit Brook Road, ZKO3-3/U14 Nashua, NH 03062 Telephone: +1 603-881-1495 EMail: kaufman@zk3.dec.com Expiration and File Name This draft expires 22 August 1994 Its file name is draft-ietf-dnssec-ek-00.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37]   Received: from sol.tis.com by magellan.TIS.COM id aa18294; 25 Feb 94 11:49 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06795; Fri, 25 Feb 94 11:48:34 EST Received: by relay.tis.com; id AA23406; Fri, 25 Feb 94 11:49:28 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3mjr) id sma023398; Fri Feb 25 11:49:14 1994 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06799; 25 Feb 94 11:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@magellan.TIS.COM MMDF-Warning: Parse error in original version of preceding line at magellan.TIS.COM Cc: dns-security@tis.com From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-00.txt Date: Fri, 25 Feb 94 11:43:25 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9402251143.aa06799@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Security Working Group of the IETF. Title : Domain Name System Protocol Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-00.txt Pages : 37 Date : 02/24/1994 The Domain Name System has become a critical operational part of the Internet infrastructure yet it has no security mechanisms to assure data integrity or authentication. Extensions to the DNS protocol are proposed to provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are added to secured zones as resource records. They can be most efficiently handled by security aware servers but security can still be provided to security aware resolvers or applications even by non-security aware primary, secondary, and caching servers. In addition, the extensions provide for the storage of authenticated keys in the DNS, so that a security aware resolver can learn the authenticating key of zones in addition to those for which it is initially configured, and for other purposes. Finally, the extensions optionally provide for authentication of DNS protocol messages for additional security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-dnssec-secext-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: venera.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19940224115054.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-dnssec-secext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940224115054.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--