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--   Received: from sol.tis.com by magellan.TIS.COM id aa07227; 16 Mar 94 10:03 EST Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA23057; Wed, 16 Mar 94 10:03:37 EST Received: from localhost.tis.com by magellan.TIS.COM id aa07220; 16 Mar 94 10:03 EST Reply-To: James M Galvin To: dns-security@tis.com Subject: [IESG Secretary: WG Action: DNS Security (dnssec)] Date: Wed, 16 Mar 1994 10:03:36 -0500 From: James M Galvin Message-Id: <9403161003.aa07220@magellan.TIS.COM> I just realized this message did not make it to this mailing list. So, just in case you're not on the IETF Announce mailing list, here you go. Jim ------- Forwarded Message Message-ID: <9403041541.aa10990@IETF.CNRI.Reston.VA.US> Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: IESG Secretary To: IETF-Announce:;@tis.com Date: Fri, 04 Mar 94 15:40:56 -0500 Subject: WG Action: DNS Security (dnssec) A new working group has been formed in the Service Application Area of the IETF. For more information, please contact the working group's chair(s) or the Area Director. IESG Secretary DNS Security (dnssec) - --------------------- Chair(s): James Galvin Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:dns-security@tis.com To Subscribe: dns-security-request@tis.com Archive: ftp.tis.com:/pub/dns-security Description of Working Group: The Domain Name System (DNS) Security Working Group (dnssec) will specify enhancements to the DNS protocol to protect the DNS against unauthorized modification of data and against masquerading of DNS data origin. That is, it will add data integrity and authentication capabilities to the DNS. The specific mechanism to be added to the DNS protocol will be a digital signature. The digital signature service will be added such that the DNS resource records will be signed and, by distributing the signatures with the records, remote sites can verify the signatures and thus have confidence in the accuracy of the records received. There are at least two issues to be explored and resolved. First, should the records be signed by the primary or secondary (or both) servers distributing the resource records, or should they be signed by the start of authority for the zone of the records. This issue is relevant since there are servers for sites that are not IP connected. Second, the mechanism with which to distribute the public keys necessary to verify the digital signatures must be identified. Two essential assumptions have been identified. First, backward compatibility and co-existence with DNS servers and clients that do not support the proposed security services is required. Second, data in the DNS is considered public information. This latter assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group. Goals and Milestones: Mar 94 Submit proposal for adding Security enhancements to DNS as an Internet-Draft Jul 94 Update Internet-Draft on adding security enhancements to DNS Nov 94 Submit proposal for adding security enhancements to the DNS to the IESG for consideration as a Proposed Standard ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa12831; 23 Mar 94 13:05 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02665; Wed, 23 Mar 94 13:05:22 EST Received: by relay.tis.com; id AA19897; Wed, 23 Mar 94 13:04:54 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3mjr) id sma019883; Wed Mar 23 13:04:01 1994 Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA20595; Wed, 23 Mar 94 09:49:06 -0800 Received: by skidrow.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA02754; Wed, 23 Mar 1994 03:43:38 -0500 Message-Id: <9403230843.AA02754@skidrow.lkg.dec.com> To: Internet Drafts Cc: dee@skidrow.lkg.dec.com, Charlie Kaufman , dns-security@tis.com Subject: Revised dns-secext draft Date: Wed, 23 Mar 94 03:43:38 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Hi, Here is an improved of our DNS Security Extensions drafts. Sorry to get this in so close to IETF... 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 March 1994 Expires 22 September 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-secext-01.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, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions 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 secondary or 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 transactions for additional security. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Overview of the Protocol...............................5 2.1 Data Origin Authentication.............................5 2.1.1 Security Provided...................................5 2.1.2 The SIG Resource Record..............................6 2.1.3 The RSA Resource Record..............................7 2.1.4 Signers Other Than The Zone..........................7 2.1.5 Special Problems With Time-to-Live...................7 2.1.6 Improved Performance At The Expense Of Compatibility.8 2.2 DNS Transaction Authentication.........................9 3. Services, Requirement, and Non-Requirements............10 3.1 Requirements..........................................10 3.2 Non-Requirements......................................12 4. The Security Desired & Security Available Bits.........13 5. The SIG Resource Record................................14 5.1 SIG RDATA Format......................................14 5.1.1 SIG Flag Bits.......................................15 5.1.2 Signature Format....................................15 5.1.3 Signet Format.......................................16 5.1.3.1 Direct Resource Record Signets....................17 5.1.3.2 Direct Glue Record Signet.........................18 5.1.3.3 Hashed Resource Record(s) Signet..................18 5.1.3.4 Partial RR Set Flag Signet........................19 5.1.3.5 Partial SIG Set Flag Signet.......................20 5.1.3.6 AXFR Signets......................................20 5.1.3.7 Message Hashed Signets............................21 5.1.3.8 Reserved Signet Prefixes..........................21 5.2 SIG RRs in the Construction of Responses..............22 5.3 Processing Responses with SIG RRs.....................23 5.4 File Representation of SIG RRs........................24 5.4.1 Size of Data........................................24 5.4.2 RR Numbering........................................24 5.4.3 SIG RR Scope........................................25 5.4.4 RRs Supressed by a SIG RR...........................25 5.4.5 Indicating Revocation...............................25 6. The RSA Resource Record................................27 6.1 RSA RDATA format......................................27 6.2 Types of DNS Names and Keys...........................27 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 6.3 RSA RR Flag Bits......................................28 6.4 RSA RRs in the Construction of Responses..............29 6.5 File Representation of RSA RRs........................29 7. How to Resolve Securely................................31 7.1 Boot File Format......................................31 7.2 Chaining Through Zones................................31 7.3 Secure Time...........................................32 8. Operational Considerations.............................34 8.1 Modulus Size Considerations...........................34 8.2 Key Storage...........................................34 8.3 Key Generation........................................35 8.4 Key Lifetimes.........................................35 8.5 Key Revocation........................................35 8.6 Root..................................................36 9. Conformance............................................37 9.1 Server Conformance....................................37 9.2 Resolver Conformance..................................37 10. Security Considerations...............................38 References................................................38 Authors Addresses.........................................39 Expiration and File Name..................................39 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] 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 in addition to supporting DNS zone 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 5] 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 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 a 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), some flags, and an RSA (Rivest, Shamir, and Adelman [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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions properties: (1) when it signs a resource record, it may contain 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions signature is verified. This conflicts with our desire to have the 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, 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 8] INTERNET-DRAFT DNS Protocol Security Extensions 2.2 DNS Transaction 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 transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response if from the query it sent and that these messages have not been diddled in transit. This is accomplished by adding a SIG resource record to end of the reply which digitally signs the message by the server and includes a hash code of the query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies 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 transaction 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 transaction 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 9] 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 BoF. 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 the SA (Security Available) bit in the header of its responses. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions <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 whose name 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 SIG RR to indicate if it is an assertion or revocation. This applies to keys (RSA RRs) and such 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. A security aware resolver has both the TTL for an RR and the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions 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 BoF 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 12] 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 RSA 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 fully supports this security protocol. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | flags | 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 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 reply 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 14] 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 "key footprint" is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. In cases where multiple keys may be applicable, it can be used to efficiently pick the right one in most cases. The "flags" octet is described below. 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 SIG Flag Bits Bits 0 to 6 are reserved and must be zero. Bit 7 (the least significant bit) a zero means the SIG RR asserts the validity of the RR it signs from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the RR as above. 5.1.2 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 (or DNS messages) being authenticated. 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions 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, expiration time, key footprint, and flags. "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 similar to PKCS #1 [PKCS1] except that, under most circumstances, one additional byte of data is 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.3 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 supressed 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions 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 11111000 Partial SIG Set Flag 11111001 Partial RR Set Flag 11111010 Hashed query message 11111011 Hashed response message 1111110* (reserved) 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 illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.3.1 Direct Resource Record Signets This signet is an actual RR but with some fields supressed. 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.3.2 and 5.1.3.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 supressed from the answer if given to a security aware Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions 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 within 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 RR's 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 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.3.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.3.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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions 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. 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.3.4 Partial RR Set Flag Signet Verification of a hashed RR signet against the RRs included in the hash provides a guarantee that none have been omitted. The same Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions 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 F8 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 F8000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. 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.3.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 F9 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.3.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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 5.1.3.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. 5.1.3.7 Message Hashed Signets The response message signet consists of the FA (hex) prefix followed by the 20 byte SHS hash of the entire response message before the SIG, including the header. The query signet consists of the FB (hex) prefix followed by the 20 byte SHS has of the entire query that produced this response, including the query's header. Verification of the transaction authentication SIG, which is signed by the server host key, not the zone key, and the message signets within it by the requesting resolver show that the query and response were not tampered with in transit, that the response corresponds to the intended query. 5.1.3.8 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions 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 authenticate 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 supress 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. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section. Such SIG RRs are signed by the DNS server originating the response. The transaction authentication SIG contains a response message hashed signet and a query message hashed signet. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. To save space, the name should be root (a single zero byte) and the class and TTL fields can be zero. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions 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, hashed, 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 hashed response and query message signets covering the preceding data in the response and the query that produced the response. These should be checked and the message rejected if the checks fails. But even it the check succeeds, such a transaction authentication SIG it does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. 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 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). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions 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 transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) 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 and flags fields appears as unsigned integers. The key footprint appears as an eight digit unsigned hexadecimal number. 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 supresses 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 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 (";"). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 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 supresses 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 Supressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should normally be supressed 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 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 supressed RRs are numbered. An RR that is supressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.2. [give example] 5.4.5 Indicating Revocation In many cases, a zone file will be maintained and SIG RRs will be added to the zone file by a separate operation. To indicate that Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions such a generated SIG should be a revocation, include the word "revoke", or any word (contiguous string of letters) beginning with a lower or upper case R within the "{}" field for the RR as described above. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] 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 transaction authentication, etc., 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. The type number for the RSA RR is xxx. 6.1 RSA RDATA format The RDATA for a RSA RR consists of 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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] 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 . Thus, the flag byte in the RSA RR has bits to indicate with which of these roles a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions 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. In addition, there are two control bits, the "mandatory" bit and the "authority" bit, as described in 6.3 below. 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 Bits 0 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 operate without the availability of IP-security. The mandatory bit is only effective if the key is appropriately signed. Bit 1 is the "authority" bit. It indicates that the key can validly sign RRs of the same name. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The bit is only effective if the key is signed by a valid zone key. Bits 2-4 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 5 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 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions entity. This is the public key used in connection with the optional transaction 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: On the retrieval of NS RRs, the zone key RSA RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the RSA RR(s) have higher priority than type A RRs. On retrieval of type A RRs, the end entity RSA RR(s) 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 revoked RSAs that fit with their revoking SIG will be included as additional information with low priority. 6.5 File Representation of RSA RRs RSA RRs may appear as lines in a zone data file. The flags field is represented as an unsigned integer. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions 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 30] INTERNET-DRAFT DNS Protocol Security Extensions 7. How to Resolve Securely Retrieving or resolving authentic 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. 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 one starts below root. A secure sub-zone is generally indicated by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions an RSA RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. 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. 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 is probably getting completely bogus or spoofed data. 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 within "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 RRs requires that secure consistent time be available to the hosts implementing the DNS security extensions. The Network Time Protocol (NTP) [RFC1305] 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions To accommodate the secure time requirement, all DNS servers should 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 33] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations This section discusses a variety of operational considerations in secure operation of DNS using these proposed protocol extensions. 8.1 Modulus Size Considerations There are a number of factors that effect modulus (key) 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding SIG RRs and then the SIG augmented file transferred, perhaps by sneaker-net, to the networked server machine. 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 maximum 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 or more often. 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, Donald E. Eastlake 3rd & Charles W. Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions 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. 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. 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 in a SIG can be revoked for just the later part of that lifetime by setting appropriate times in the revocation SIG 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 36] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance [this section needs work ...] 9.1 Server Conformance Security aware servers MUST respond normally to requests that do not have the Security Desired bit set. Three levels of server conformance are defined as follows: Zilch server compliance is (1) the ability to ignore the Security Requested bit in queries, (2) ability to store and retrieve (incluidng zone transfer) SIG and RSA RRs, and (3) always clearing the Security Available bit in responses. It is believed that almost all current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG and RSA RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to handle the Security Desired bit in inquiries, automatically including SIG and RSA RRs in responses as appropriate, as well as meeting the minimal compliance except that only item 2 of zilch criteria should be met. In addition, fully compliant servers MUST turn on the Security Available bit in responses. 9.2 Resolver Conformance - Resolver compliance... Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37] 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 transaction 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 [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992 [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 38] 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 September 1994 Its file name is draft-ietf-dnssec-secext-01.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 39]   Received: from sol.tis.com by magellan.TIS.COM id aa12569; 23 Mar 94 11:54 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25829; Wed, 23 Mar 94 11:53:45 EST Received: by relay.tis.com; id AA19132; Wed, 23 Mar 94 11:53:17 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma019126; Wed Mar 23 11:52:19 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05235; Wed, 23 Mar 94 08:49:55 -0800 Received: by skidrow.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA07406; Wed, 23 Mar 1994 11:51:04 -0500 Message-Id: <9403231651.AA07406@skidrow.lkg.dec.com> To: internet-drafts%cnri.reston.va.us@inet-gw-1.pa.dec.com Cc: dns-security%tis.com@inet-gw-1.pa.dec.com Subject: Revised dns-secext draft Date: Wed, 23 Mar 94 11:51:04 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp The following mail is stuck on the mail queue at skidrow.lkg.dec.com due to a configuration error. You will also get another copy if/when that problem is fixed. Hopefully I've addressed this copy to get around the problem. Donald ------- Forwarded Message Forwarded: Wed, 23 Mar 94 11:37:00 -0500 Forwarded: internet-drafts%cnri.reston.va.us@relay.dec.com Forwarded: dns-security%tis.com@relay.dec.com Return-Path: dee To: Internet Drafts Cc: dee, Charlie Kaufman , dns-security@tis.com Subject: Revised dns-secext draft Date: Wed, 23 Mar 94 03:43:38 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Hi, Here is an improved of our DNS Security Extensions drafts. Sorry to get this in so close to IETF... 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 March 1994 Expires 22 September 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-secext-01.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, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions 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 secondary or 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 transactions for additional security. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Overview of the Protocol...............................5 2.1 Data Origin Authentication.............................5 2.1.1 Security Provided...................................5 2.1.2 The SIG Resource Record..............................6 2.1.3 The RSA Resource Record..............................7 2.1.4 Signers Other Than The Zone..........................7 2.1.5 Special Problems With Time-to-Live...................7 2.1.6 Improved Performance At The Expense Of Compatibility.8 2.2 DNS Transaction Authentication.........................9 3. Services, Requirement, and Non-Requirements............10 3.1 Requirements..........................................10 3.2 Non-Requirements......................................12 4. The Security Desired & Security Available Bits.........13 5. The SIG Resource Record................................14 5.1 SIG RDATA Format......................................14 5.1.1 SIG Flag Bits.......................................15 5.1.2 Signature Format....................................15 5.1.3 Signet Format.......................................16 5.1.3.1 Direct Resource Record Signets....................17 5.1.3.2 Direct Glue Record Signet.........................18 5.1.3.3 Hashed Resource Record(s) Signet..................18 5.1.3.4 Partial RR Set Flag Signet........................19 5.1.3.5 Partial SIG Set Flag Signet.......................20 5.1.3.6 AXFR Signets......................................20 5.1.3.7 Message Hashed Signets............................21 5.1.3.8 Reserved Signet Prefixes..........................21 5.2 SIG RRs in the Construction of Responses..............22 5.3 Processing Responses with SIG RRs.....................23 5.4 File Representation of SIG RRs........................24 5.4.1 Size of Data........................................24 5.4.2 RR Numbering........................................24 5.4.3 SIG RR Scope........................................25 5.4.4 RRs Supressed by a SIG RR...........................25 5.4.5 Indicating Revocation...............................25 6. The RSA Resource Record................................27 6.1 RSA RDATA format......................................27 6.2 Types of DNS Names and Keys...........................27 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 6.3 RSA RR Flag Bits......................................28 6.4 RSA RRs in the Construction of Responses..............29 6.5 File Representation of RSA RRs........................29 7. How to Resolve Securely................................31 7.1 Boot File Format......................................31 7.2 Chaining Through Zones................................31 7.3 Secure Time...........................................32 8. Operational Considerations.............................34 8.1 Modulus Size Considerations...........................34 8.2 Key Storage...........................................34 8.3 Key Generation........................................35 8.4 Key Lifetimes.........................................35 8.5 Key Revocation........................................35 8.6 Root..................................................36 9. Conformance............................................37 9.1 Server Conformance....................................37 9.2 Resolver Conformance..................................37 10. Security Considerations...............................38 References................................................38 Authors Addresses.........................................39 Expiration and File Name..................................39 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] 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 in addition to supporting DNS zone 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 5] 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 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 a 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), some flags, and an RSA (Rivest, Shamir, and Adelman [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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions properties: (1) when it signs a resource record, it may contain 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions signature is verified. This conflicts with our desire to have the 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, 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 8] INTERNET-DRAFT DNS Protocol Security Extensions 2.2 DNS Transaction 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 transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response if from the query it sent and that these messages have not been diddled in transit. This is accomplished by adding a SIG resource record to end of the reply which digitally signs the message by the server and includes a hash code of the query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies 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 transaction 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 transaction 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 9] 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 BoF. 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 the SA (Security Available) bit in the header of its responses. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions <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 whose name 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 SIG RR to indicate if it is an assertion or revocation. This applies to keys (RSA RRs) and such 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. A security aware resolver has both the TTL for an RR and the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions 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 BoF 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 12] 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 RSA 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 fully supports this security protocol. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | flags | 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 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 reply 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 14] 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 "key footprint" is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. In cases where multiple keys may be applicable, it can be used to efficiently pick the right one in most cases. The "flags" octet is described below. 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 SIG Flag Bits Bits 0 to 6 are reserved and must be zero. Bit 7 (the least significant bit) a zero means the SIG RR asserts the validity of the RR it signs from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the RR as above. 5.1.2 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 (or DNS messages) being authenticated. 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions 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, expiration time, key footprint, and flags. "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 similar to PKCS #1 [PKCS1] except that, under most circumstances, one additional byte of data is 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.3 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 supressed 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions 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 11111000 Partial SIG Set Flag 11111001 Partial RR Set Flag 11111010 Hashed query message 11111011 Hashed response message 1111110* (reserved) 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 illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.3.1 Direct Resource Record Signets This signet is an actual RR but with some fields supressed. 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.3.2 and 5.1.3.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 supressed from the answer if given to a security aware Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions 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 within 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 RR's 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 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.3.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.3.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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions 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. 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.3.4 Partial RR Set Flag Signet Verification of a hashed RR signet against the RRs included in the hash provides a guarantee that none have been omitted. The same Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions 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 F8 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 F8000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. 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.3.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 F9 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.3.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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 5.1.3.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. 5.1.3.7 Message Hashed Signets The response message signet consists of the FA (hex) prefix followed by the 20 byte SHS hash of the entire response message before the SIG, including the header. The query signet consists of the FB (hex) prefix followed by the 20 byte SHS has of the entire query that produced this response, including the query's header. Verification of the transaction authentication SIG, which is signed by the server host key, not the zone key, and the message signets within it by the requesting resolver show that the query and response were not tampered with in transit, that the response corresponds to the intended query. 5.1.3.8 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions 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 authenticate 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 supress 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. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section. Such SIG RRs are signed by the DNS server originating the response. The transaction authentication SIG contains a response message hashed signet and a query message hashed signet. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. To save space, the name should be root (a single zero byte) and the class and TTL fields can be zero. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions 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, hashed, 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 hashed response and query message signets covering the preceding data in the response and the query that produced the response. These should be checked and the message rejected if the checks fails. But even it the check succeeds, such a transaction authentication SIG it does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. 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 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). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions 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 transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) 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 and flags fields appears as unsigned integers. The key footprint appears as an eight digit unsigned hexadecimal number. 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 supresses 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 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 (";"). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 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 supresses 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 Supressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should normally be supressed 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 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 supressed RRs are numbered. An RR that is supressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.2. [give example] 5.4.5 Indicating Revocation In many cases, a zone file will be maintained and SIG RRs will be added to the zone file by a separate operation. To indicate that Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions such a generated SIG should be a revocation, include the word "revoke", or any word (contiguous string of letters) beginning with a lower or upper case R within the "{}" field for the RR as described above. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] 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 transaction authentication, etc., 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. The type number for the RSA RR is xxx. 6.1 RSA RDATA format The RDATA for a RSA RR consists of 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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] 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 . Thus, the flag byte in the RSA RR has bits to indicate with which of these roles a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions 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. In addition, there are two control bits, the "mandatory" bit and the "authority" bit, as described in 6.3 below. 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 Bits 0 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 operate without the availability of IP-security. The mandatory bit is only effective if the key is appropriately signed. Bit 1 is the "authority" bit. It indicates that the key can validly sign RRs of the same name. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The bit is only effective if the key is signed by a valid zone key. Bits 2-4 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 5 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 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions entity. This is the public key used in connection with the optional transaction 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: On the retrieval of NS RRs, the zone key RSA RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the RSA RR(s) have higher priority than type A RRs. On retrieval of type A RRs, the end entity RSA RR(s) 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 revoked RSAs that fit with their revoking SIG will be included as additional information with low priority. 6.5 File Representation of RSA RRs RSA RRs may appear as lines in a zone data file. The flags field is represented as an unsigned integer. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions 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 30] INTERNET-DRAFT DNS Protocol Security Extensions 7. How to Resolve Securely Retrieving or resolving authentic 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. 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 one starts below root. A secure sub-zone is generally indicated by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions an RSA RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. 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. 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 is probably getting completely bogus or spoofed data. 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 within "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 RRs requires that secure consistent time be available to the hosts implementing the DNS security extensions. The Network Time Protocol (NTP) [RFC1305] 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions To accommodate the secure time requirement, all DNS servers should 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 33] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations This section discusses a variety of operational considerations in secure operation of DNS using these proposed protocol extensions. 8.1 Modulus Size Considerations There are a number of factors that effect modulus (key) 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding SIG RRs and then the SIG augmented file transferred, perhaps by sneaker-net, to the networked server machine. 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 maximum 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 or more often. 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, Donald E. Eastlake 3rd & Charles W. Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions 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. 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. 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 in a SIG can be revoked for just the later part of that lifetime by setting appropriate times in the revocation SIG 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 36] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance [this section needs work ...] 9.1 Server Conformance Security aware servers MUST respond normally to requests that do not have the Security Desired bit set. Three levels of server conformance are defined as follows: Zilch server compliance is (1) the ability to ignore the Security Requested bit in queries, (2) ability to store and retrieve (incluidng zone transfer) SIG and RSA RRs, and (3) always clearing the Security Available bit in responses. It is believed that almost all current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG and RSA RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to handle the Security Desired bit in inquiries, automatically including SIG and RSA RRs in responses as appropriate, as well as meeting the minimal compliance except that only item 2 of zilch criteria should be met. In addition, fully compliant servers MUST turn on the Security Available bit in responses. 9.2 Resolver Conformance - Resolver compliance... Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37] 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 transaction 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 [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992 [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 38] 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 September 1994 Its file name is draft-ietf-dnssec-secext-01.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 39] ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa23493; 24 Mar 94 19:15 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23033; Thu, 24 Mar 94 19:15:27 EST Received: by relay.tis.com; id AA11048; Thu, 24 Mar 94 19:14:58 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3mjr) id sma011034; Thu Mar 24 19:14:34 1994 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07825; 24 Mar 94 11:19 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-01.txt Date: Thu, 24 Mar 94 11:19:37 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9403241119.aa07825@IETF.CNRI.Reston.VA.US> --NextPart A Revised 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-01.txt Pages : 39 Date : 03/23/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 secondary or 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 transactions 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-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.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-01.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: <19940323172226.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-dnssec-secext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940323172226.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from sol.tis.com by magellan.TIS.COM id aa07334; 30 Mar 94 20:02 EST Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA06909; Wed, 30 Mar 94 20:02:43 EST Received: from localhost.tis.com by magellan.TIS.COM id aa07327; 30 Mar 94 20:02 EST Reply-To: James M Galvin To: Dave Crocker Cc: dns-security@tis.com Subject: DNS Security Area Report Summary (March 94 Seattle) Mime-Version: 1.0 Content-Type: multipart/security; boundary="----- =_aaaaaaaaaa0" Date: Wed, 30 Mar 1994 20:02:47 -0500 From: James M Galvin Message-Id: <9403302002.aa07327@magellan.TIS.COM> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7309.765075761.2@tis.com> The DNS Security WG met to review the proposed security enhancements drafted by Charile Kaufman and Don Eastlake. The desired requirements specifed at the Houston meeting were reviewed, followed by a presentation and discussion of the proposal. A number of issues were identified, with a disposition proposed for each. In particular, resolution on a few was deferred until after implementation experience was available. Jim Galvin indicated that TIS would be implementing the proposal. This group expects to meet in Toronto. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature; protocol="pem" Content-ID: <7309.765075761.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE= ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0= 2 MIC-Info: RSA-MD5,RSA,hYipsflYdAmIuTebemHiLMtxqwl92qd3XEFqVBq0+D+7NgX7SuKJ= KWFfF1YqCLBzwsMR3OQWdZY2ruNYy8pqhg6Gb2uekCW7twhiDtHui1x9MoGg401JNFa6TK1brq= r1 ------- =_aaaaaaaaaa0--   Received: from sol.tis.com by magellan.TIS.COM id aa11921; 1 Apr 94 2:21 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04193; Fri, 1 Apr 94 02:21:15 EST Received: by relay.tis.com; id AA09657; Fri, 1 Apr 94 02:21:51 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma009654; Fri Apr 1 02:21:48 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25032; Thu, 31 Mar 94 23:18:02 -0800 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21005; Fri, 1 Apr 1994 02:19:18 -0500 Message-Id: <9404010719.AA21005@skidrow.lkg.dec.com> To: Internet Assigned Number Authority Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com Subject: SIG & RSA RRs Date: Fri, 01 Apr 94 02:19:17 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Jon, As we discussed, implementations of draft-ietf-dnssec-secext-01.txt will be starting shortly. Thus two DNS RR type numbers need to be assigned, one for the SIG (signture) RR type and one for the RSA (key) RR type. Thanks, 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)   Received: from sol.tis.com by magellan.TIS.COM id aa11929; 1 Apr 94 2:22 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04211; Fri, 1 Apr 94 02:22:14 EST Received: by relay.tis.com; id AA09663; Fri, 1 Apr 94 02:22:51 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma009660; Fri Apr 1 02:22:24 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25066; Thu, 31 Mar 94 23:19:01 -0800 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21032; Fri, 1 Apr 1994 02:20:27 -0500 Message-Id: <9404010720.AA21032@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: Paul Mockapetris , dee@skidrow.lkg.dec.com Subject: SIG RR location in responses Date: Fri, 01 Apr 94 02:20:27 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I talked to Paul Mockapetris and he has no objection to the scheme proposed in the current dnssec draft on the placing of SIG in a response when the query did not specify SIGs. (It calls for putting the SIG in the answer section if it signs anything in the answer section, putting it in the authority section if it signs something in the authority section and nothing in the answer section, and putting it in the additional information section if it signs nothing in either the answer or authority sections.) 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)   Received: from sol.tis.com by magellan.TIS.COM id aa15537; 2 Apr 94 13:40 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25005; Sat, 2 Apr 94 13:40:41 EST Received: by relay.tis.com; id AA17938; Sat, 2 Apr 94 13:41:20 EST Received: from quark.isi.edu(128.9.208.208) by relay via smap (V1.3mjr) id sma017935; Sat Apr 2 13:40:43 1994 Received: from [128.9.32.193] (ppp3.isi.edu) by quark.isi.edu (5.65c/5.61+local-16) id ; Sat, 2 Apr 1994 10:37:44 -0800 Date: Sat, 2 Apr 1994 10:37:44 -0800 Message-Id: <199404021837.AA06041@quark.isi.edu> X-Sender: pvm@quark.isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Donald E. Eastlake 3rd (Beast)" , dns-security@tis.com From: pvm@isi.edu Subject: Re: SIG RR location in responses Cc: Paul Mockapetris , dee@skidrow.lkg.dec.com At 2:20 AM 4/1/94 -0500, Donald E. Eastlake 3rd (Beast) wrote: >I talked to Paul Mockapetris and he has no objection to the scheme >proposed in the current dnssec draft on the placing of SIG in a >response when the query did not specify SIGs. (It calls for putting >the SIG in the answer section if it signs anything in the answer >section, putting it in the authority section if it signs something in >the authority section and nothing in the answer section, and putting >it in the additional information section if it signs nothing in either >the answer or authority sections.) > >Donald > Don, I belive I said I had no objection to adding things to the additional section, in general, and other sections as appropriate. This isn't a blanket good idea; the effects of truncation and backward compatibility must be considered. paul paul USC/Information Sciences Institute 4676 Admiralty Way, Marina del Rey, CA 90292 310-822-1511 x285   Received: from sol.tis.com by magellan.TIS.COM id aa15805; 2 Apr 94 16:56 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27553; Sat, 2 Apr 94 16:55:57 EST Received: by relay.tis.com; id AA18478; Sat, 2 Apr 94 16:56:36 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma018475; Sat Apr 2 16:55:54 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA08502; Sat, 2 Apr 94 13:52:18 -0800 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23373; Sat, 2 Apr 1994 16:53:45 -0500 Message-Id: <9404022153.AA23373@skidrow.lkg.dec.com> To: pvm@isi.edu Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Your message of "Sat, 02 Apr 94 10:37:44 PST." <199404021837.AA06041@quark.isi.edu> Date: Sat, 02 Apr 94 16:53:45 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul, From: pvm@isi.edu To: "Donald E. Eastlake 3rd (Beast)" , dns-security@tis.com >At 2:20 AM 4/1/94 -0500, Donald E. Eastlake 3rd (Beast) wrote: >>I talked to Paul Mockapetris and he has no objection to the scheme >>proposed in the current dnssec draft on the placing of SIG in a >>response when the query did not specify SIGs. (It calls for putting >>the SIG in the answer section if it signs anything in the answer >>section, putting it in the authority section if it signs something in >>the authority section and nothing in the answer section, and putting >>it in the additional information section if it signs nothing in either >>the answer or authority sections.) >>Donald >Don, I belive I said I had no objection to adding things to the additional >section, in general, and other sections as appropriate. This isn't a >blanket good idea; the effects of truncation and backward compatibility >must be considered. Sorry if I misrepresented you at all. I designed the current proposal as described above for a couple of reasons listed below. I don't see backward compatibility as an issues as a resolver will never see SIG RRs unless it explicitly asks for them or it is a security aware resolver talking to a security aware server and turns on the security desired bit in its query. The reasons for the current design were (1) I believe that in most cases all the RRs being exlicitly retrieved will fix inside the SIG. So when a security aware resolver and server are talking, the normal case will be that all of the explicity requested RRs will be surpressed and the "answer" will just consist of a SIG (or, in some cases, an RSA and a SIG). This being the case, it seems reasonable to put this SIG RR in the answer section. (2) Regardless of point 1, when operating in a secured mode, RRs are essentially useless unless they are signed. Thus the SIG that goes with any RRs in the answer setion is just as valuable as they are and intrisicly more valuable than anthing in the additional information section. Thus it should appear in the answer section to minimize any chance it would be truncated. >paul > >USC/Information Sciences Institute >4676 Admiralty Way, Marina del Rey, CA >90292 310-822-1511 x285 Donald   Received: from sol.tis.com by magellan.TIS.COM id aa17521; 3 Apr 94 14:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07856; Sun, 3 Apr 94 14:15:28 EDT Received: by relay.tis.com; id AA21270; Sun, 3 Apr 94 14:16:08 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma021267; Sun Apr 3 14:15:29 1994 Received: by gw.home.vix.com id AA19257; Sun, 3 Apr 94 11:15:23 -0700 Date: Sun, 3 Apr 94 11:15:23 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: SIG RR location in responses Organization: Vixie Enterprises Message-Id: References: <9404031202.AA09476@necom830.cc.titech.ac.jp> Nntp-Posting-Host: office.home.vix.com In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 3 Apr 1994 06:02:06 -0700 >Moreover, aren't the current name servers copying the unused bits >of query packets? yes. >SIGs are less valuable than glue As because they can be asked with a separate >query. agreed. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa17002; 3 Apr 94 8:17 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07053; Sun, 3 Apr 94 08:17:02 EDT Received: by relay.tis.com; id AA20332; Sun, 3 Apr 94 08:17:42 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma020326; Sun Apr 3 08:16:42 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 3 Apr 94 21:02:35 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404031202.AA09476@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses To: "Donald E. Eastlake 3rd" Date: Sun, 3 Apr 94 21:02:33 JST Cc: pvm@isi.edu, dns-security@tis.com In-Reply-To: <9404022153.AA23373@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 2, 94 4:53 pm X-Mailer: ELM [version 2.3 PL11] > I don't see > backward compatibility as an issues as a resolver will never see SIG > RRs unless it explicitly asks for them or it is a security aware > resolver talking to a security aware server and turns on the security > desired bit in its query. The older resolver will see (partial) SIG RRs with query type of ANY. Moreover, aren't the current name servers copying the unused bits of query packets? > The reasons for the current design were > (1) I believe that in most cases all the RRs being exlicitly retrieved > will fix inside the SIG. If you are assuming that the total size of RRs is small, you don't have to eliminate that RRs. For example, RRs for A records are only 14 byte long (excluding NAME). Is it really meaningfull to remove one or two 14 byte record when you are using 128 byte (1024) SIG RR(s)? It should be noted that as no compression mechanism is assumed in the draft, raw data in signets could be quite lengthy. Note, for example, that my host name , "necom830.cc.titech.ac.jp.", already exceeds 20 characters and much longer than MD5 signature. BTW, considering that 128 byte SIG can contain 8 MD5 signatures, isn't it reasonable to forget about partial SIG RRs and allow only one SIG RR for a given domain. It is rare that a domain have data for more than 8 RR types. > (2) Regardless of point 1, when operating in a secured mode, RRs are > essentially useless unless they are signed. Regardless of point 2, when DNS operates, NS RRs of authority section for names within the domain are essentially useless unless they are accompanied by glue A records. > Thus the SIG that goes > with any RRs in the answer setion is just as valuable as they are and > intrisicly more valuable than anthing in the additional information > section. Thus it should appear in the answer section to minimize any > chance it would be truncated. SIGs are less valuable than glue As because they can be asked with a separate query. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa01006; 4 Apr 94 17:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21150; Mon, 4 Apr 94 16:53:11 EDT Received: by relay.tis.com; id AA27572; Mon, 4 Apr 94 16:53:53 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027569; Mon Apr 4 16:53:09 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA10112; Mon, 4 Apr 94 13:45:37 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA28553; Mon, 4 Apr 1994 16:47:04 -0400 Message-Id: <9404042047.AA28553@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Your message of "Sun, 03 Apr 94 21:02:33 +0200." <9404031202.AA09476@necom830.cc.titech.ac.jp> Date: Mon, 04 Apr 94 16:47:04 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Ohta-san, From: Masataka Ohta In-Reply-To: <9404022153.AA23373@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 2, 94 4:53 pm >> I don't see >> backward compatibility as an issues as a resolver will never see SIG >> RRs unless it explicitly asks for them or it is a security aware >> resolver talking to a security aware server and turns on the security >> desired bit in its query. > >The older resolver will see (partial) SIG RRs with query type of ANY. Yes, you are correct that older resolvers (in fact, resolvers of any age) doing a query of type ANY will see SIG RRs. (I'm not sure why you said "(partial)"...) But anyone doing an ANY type request should expect to see strange RRs come back that it does not know about. New RRs get defined periodically. This is not anything new with just the SIG RR. In any case, I thought were talking about the location in a response of SIGs that were automatically added by security aware servers when they recieve queries with the Security Desired (SD) bit set. This sort of automatically included RR is exactly the sort of thing that has in the past been included in the "additional information section". I gave the reasons why I thought SIGs were different in this regard and should frequently be in the answer or authority section. >Moreover, aren't the current name servers copying the unused bits >of query packets? I don't see what that has to do with the location of spontaneously included SIG RRs on queries from security aware resolvers to security aware servers, which is what I was discussing. If a security aware resolver makes a query with the (SD) bit on in the header to a non-security aware server, it will probably be copied into the response, but so what? A non-security aware server will not set the Security Available (SA) bit in the response and will not spontaneously add SIG RRs to the response. >> The reasons for the current design were >> (1) I believe that in most cases all the RRs being exlicitly retrieved >> will fix inside the SIG. >If you are assuming that the total size of RRs is small, you don't >have to eliminate that RRs. >For example, RRs for A records are only 14 byte long (excluding NAME). >Is it really meaningfull to remove one or two 14 byte record when you >are using 128 byte (1024) SIG RR(s)? I make no assumptions about the total size of RRs and only broad bounds on the size of the zone key modulus. The draft is designed to work as well as it can with all sizes of individual and total RRs. While I think the retrieved and additional RRs will commonly fit into one SIG at this time, this will, for example, not be true if it becomes common to have a host key (RSA) RR present unless the modulus is constrained to be significantly smaller than the zone key modulus. (The proposal calls for the inclusion of the host RSA RR, if any, as additional info on a type A retrieval on the assumption that with widespread IPsec, you would want to know the host key.) Eliminating an RR when it is incorporated inside the SIG is optional under the current draft. But there are clearly cases when not eliminating a plain text RR that did fit into the SIG will cause truncation. It might, for example, force the RSA RR additional information mentioned above to not fit and cause truncation. As tentatively decided at the DNSSEC WG meeting in Seattle, I would wait for implementation experience to indicate the need before changing this aspect of the draft. >It should be noted that as no compression mechanism is assumed in >the draft, raw data in signets could be quite lengthy. Note, for example, >that my host name , "necom830.cc.titech.ac.jp.", already exceeds 20 >characters and much longer than MD5 signature. I'm not sure of your point. Long RR's can be represented as hashes inside the SIG. All RR's in excess of 127 bytes (or the SIG modulus size less overhead if that is smaller) after abbreviating out the owner name, class, and TTL, must be included as hashes. For medium length RRs, the implenetor is premitted to go either way. For short RRs, you can represent them as a hash if you want, even if that is longer. I thought people considered the draft complicated enough as it is. I suppose some compression scheme could be added but I would not want to do that unless implementation experience indicated it was necessary. If I did want to add compression, the first thing I would do would be to allow name compression inside the signets as if they were immediately preceeded by the SIG RR owner name followed by the SIG RR signer name... This may not be such a bad idea although it would not help in cases like a PTR RR with a completely unrelated name... >BTW, considering that 128 byte SIG can contain 8 MD5 signatures, isn't >it reasonable to forget about partial SIG RRs and allow only one SIG RR >for a given domain. It is rare that a domain have data for more than >8 RR types. I think you are talking about two things: elimination of multiple SIG RRs so that only one was allowed for a particular name and class; and elimination of the "direct" signets so that only hashed signets would be allowed in a SIG. I still think you would need prefix octets to distinguish types (hashed, hashed glue, hashed message, ...) so your signets would all be 19 bytes (prefix + type + 16 byte MD5), or longer for glue RRs, so its more like 6 signets fitting and then only if people use a key as big as your are assuming which is well above the minimum allowed in the current draft. Even assuming you can get things to fit in 512 byte UDP datagrams with your simplifications, which is not clear to me, and even if it is "rare" for for there to be more than 6 RR types for a given owner name and class, I find it totally unacceptable to only secure common cases in the DNS. I believe that a DNS security proposal must cover all but the most preverse cases. >> (2) Regardless of point 1, when operating in a secured mode, RRs are >> essentially useless unless they are signed. > >Regardless of point 2, when DNS operates, NS RRs of authority section >for names within the domain are essentially useless unless they are >accompanied by glue A records. I don't see why that is true. You can always get the A record by resolving the name from root if need be. With a security ignorant server, you can always do what you want with additional retrievals. When you are trying to use one or more NS RRs for a zone you need the RSA record for the zone pointed to so you know its key and if security is mandatory for that zone and you need one or more A records for one or more of the servers for that zone and you want all of this stuff signed (although I guess it makes less difference if the A record is signed as with dnssec you can't get spoofed talking to the wrong server if the zone is secured and you can securely resolve the server name(s) separatly if you want). >> Thus the SIG that goes >> with any RRs in the answer setion is just as valuable as they are and >> intrisicly more valuable than anthing in the additional information >> section. Thus it should appear in the answer section to minimize any >> chance it would be truncated. > >SIGs are less valuable than glue As because they can be asked with a separate >query. Why can't you ask for the glue A's in a separate query? > Masataka Ohta I suggest that the best way to resolve this is that you should write the off line application that signs a zone using your suggestions and run it on variousl real zones (including RSA RRs) with various sizes of key and post the results. These can then be compared with the results using a policy closer to that recommended in the draft. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa01043; 4 Apr 94 17:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23040; Mon, 4 Apr 94 17:27:17 EDT Received: by relay.tis.com; id AA27871; Mon, 4 Apr 94 17:27:58 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027864; Mon Apr 4 17:27:24 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11876; Mon, 4 Apr 94 14:20:28 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA29270; Mon, 4 Apr 1994 17:21:57 -0400 Message-Id: <9404042121.AA29270@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: dnssec draft Date: Mon, 04 Apr 94 17:21:57 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I'd be the first to admit that the current draft is not particularly well written. However, I think that even more than improvement and some reorganization of the technical documentation, there is a drastic need for an "overview". This would have no bit fields or binary/hex numbers in it but would try to give a thorough overview of the proposal. It might incorporate some of the introductory and overview material in the current draft but substantially augmented and rewritten. What do other people think? Donald PS: I have gone through and replaced the secure hash standard with MD5 everywhere in the draft as well as fixing many of the typos and am in the process of de-emphasizing NTP, all as discussed in Seattle. I plan to post this revised draft in a few days so people with complaints about typos might want to wait to see if I've caught them... --------------------------------------------------------------------------- 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)   Received: from sol.tis.com by magellan.TIS.COM id aa02088; 5 Apr 94 4:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01778; Tue, 5 Apr 94 04:54:36 EDT Received: by relay.tis.com; id AA00820; Tue, 5 Apr 94 04:55:18 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma000817; Tue Apr 5 04:55:08 1994 Received: by gw.home.vix.com id AA05484; Tue, 5 Apr 94 01:54:51 -0700 Date: Tue, 5 Apr 94 01:54:51 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: SIG RR location in responses Organization: Vixie Enterprises Message-Id: References: <9404042047.AA28553@skidrow.lkg.dec.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: dee@skidrow.lkg.dec.com's message of 4 Apr 1994 15:02:02 -0700 Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? If RSA has put their algorythm into the public domain recently, I'll withdraw my objection. But I don't think they've done that, and I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. (I'm not saying I won't do it, but I'm definitely reluctant.) -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa02349; 5 Apr 94 6:14 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02181; Tue, 5 Apr 94 06:14:43 EDT Received: by relay.tis.com; id AA01134; Tue, 5 Apr 94 06:15:26 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma001127; Tue Apr 5 06:14:43 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA22518; Tue, 5 Apr 1994 12:18:21 +0200 Message-Id: <199404051018.AA22518@mitsou.inria.fr> To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Your message of "Tue, 05 Apr 1994 01:54:51 PDT." Date: Tue, 05 Apr 1994 12:18:20 +0200 From: Christian Huitema Paul, Do you seriously believe there is any alternative to RSA? The only one I could think of would be using another non patented PK technology, or using a symmetric key system. While symmetric systems could be used for an Internet wide key distribution mechanism, I don't really see how you would secure the DNS records with them (i.e. if you really belive that, show us how). The PK alternative would be ElGamal - which is still covered by the Diffie-Helmann patent until 1997, and also mandates some very large signatures and certificates (at least twice larger than RSA) + computer intensive checks. The general catch phrase is "fair patenting". In my mind, this should imply free usage in public domain implementations + easy procedures for commercial software. If you do not believe that RSA meets these conditions, please explain us why, and what should be changed. Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa04264; 5 Apr 94 11:31 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22014; Tue, 5 Apr 94 11:31:22 EDT Received: by relay.tis.com; id AA02816; Tue, 5 Apr 94 11:32:04 EDT Received: from uucp6.netcom.com(163.179.3.6) by relay via smap (V1.3mjr) id sma002811; Tue Apr 5 11:31:34 1994 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id IAA10328; Tue, 5 Apr 1994 08:26:49 -0700 Received: from cc:Mail UUCPLINK 2.0 by metrico.metricom.com id 9403057655.AA765554826 Tue, 05 Apr 94 07:07:06 Date: Tue, 05 Apr 94 07:07:06 From: Greg_Campbell@metrico.metricom.com Message-Id: <9403057655.AA765554826@metrico.metricom.com> To: James M Galvin To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses Subject: cc:Mail UUCPLINK 2.0 Undeliverable Message User metrico!rfox@metricom.com is not defined Original text follows ----------------------------------------- Received: by ccmail Received: from netcomsv by metricom.com (UUPC/extended 1.11) with UUCP; Tue, 05 Apr 1994 07:05:40 PDT Received: from relay.tis.com by netcomsv.netcom.com with SMTP (8.6.4/SMI-4.1) id IAA07540; Tue, 5 Apr 1994 08:08:55 -0700 Received: by relay.tis.com; id AA02469; Tue, 5 Apr 94 10:46:58 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa02455; Tue Apr 5 10:45:59 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03805; 5 Apr 94 10:39 EDT Received: from sol.tis.com by magellan.TIS.COM id aa03801; 5 Apr 94 10:38 EDT Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA16375; Tue, 5 Apr 94 10:38:04 EDT Received: from localhost.tis.com by magellan.TIS.COM id aa03631; 5 Apr 94 10:30 EDT Reply-To: James M Galvin To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Paul A Vixie's message of Tue, 05 Apr 1994 01:54:51 PDT. Date: Tue, 05 Apr 1994 10:29:53 -0400 From: James M Galvin X-ccAdmin: metricom@netcomsv Message-Id: <9404051030.aa03631@magellan.TIS.COM> Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. Two bits of information to keep in mind. First, RSADSI has made RSAREF available for non-commercial use. However, I realize this does not solve the "vendors packaging a product." For that, may I direct your attention to the latest issue of Connexions, March 1984, in which commandment number 1 of "The Ten Commandments of Domain Name Service" is, "Thou shalt not run thy vendor's DNS software." During the IETF last week, in a private conversation, it was suggested that the DNS may be one of those applications (e-mail is another) for which the vendor release cycle is just slow enough to make waiting for updated versions from vendors at least irresponsible. I, too, believe this to be true. Christian already commented on the business side of things so I won't say any more about that. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa03801; 5 Apr 94 10:38 EDT Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA16375; Tue, 5 Apr 94 10:38:04 EDT Received: from localhost.tis.com by magellan.TIS.COM id aa03631; 5 Apr 94 10:30 EDT Reply-To: James M Galvin To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Paul A Vixie's message of Tue, 05 Apr 1994 01:54:51 PDT. Date: Tue, 05 Apr 1994 10:29:53 -0400 From: James M Galvin Message-Id: <9404051030.aa03631@magellan.TIS.COM> Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. Two bits of information to keep in mind. First, RSADSI has made RSAREF available for non-commercial use. However, I realize this does not solve the "vendors packaging a product." For that, may I direct your attention to the latest issue of Connexions, March 1984, in which commandment number 1 of "The Ten Commandments of Domain Name Service" is, "Thou shalt not run thy vendor's DNS software." During the IETF last week, in a private conversation, it was suggested that the DNS may be one of those applications (e-mail is another) for which the vendor release cycle is just slow enough to make waiting for updated versions from vendors at least irresponsible. I, too, believe this to be true. Christian already commented on the business side of things so I won't say any more about that. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa04770; 5 Apr 94 12:39 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25071; Tue, 5 Apr 94 12:39:33 EDT Received: by relay.tis.com; id AA03282; Tue, 5 Apr 94 12:40:16 EDT Received: from gw1.att.com(192.20.239.133) by relay via smap (V1.3mjr) id sma003270; Tue Apr 5 12:40:02 1994 Date: Tue, 5 Apr 94 12:30 EDT Content-Length: 1991 Content-Type: text Message-Id: From: WJCarpenter To: galvin@tis.com Cc: dns-security@tis.com In-Reply-To: James M Galvin's note of 10:29:53, 5 Apr 1994 Reference: <9404051030.aa03631@magellan.TIS.COM> Subject: RE: SIG RR location in responses vixie> Am I the only person reading all this who is concerned about vixie> using RSA, a patented and licensed technology, for DNS vixie> security? I am very reluctant to put into BIND any technology vixie> which would require vendors to pay a royalty to RSA before they vixie> could ship it with their systems. galvin> Two bits of information to keep in mind. First, RSADSI has galvin> made RSAREF available for non-commercial use. However, I galvin> realize this does not solve the "vendors packaging a product." galvin> For that, may I direct your attention to the latest issue of galvin> Connexions, March 1984, in which commandment number 1 of "The galvin> Ten Commandments of Domain Name Service" is, "Thou shalt not galvin> run thy vendor's DNS software." That's fine for commercial products (ie, selling software) since it is unlikely that there would be much of a market for commercial replacements of BIND anyhow (hard to beat the price :-). I think the issue is not just having RSAREF in the software, it's having it in the protocol that's the sticky point. What about a commercial service? It's not clear to me that if I ran a for-profit service bureau that ran DNS servers for folks whether that would be commercial use w/r/t RSAREF or not. Probably yes, even if I were using non-commercial BIND software. Don't like that because you think that's a marginal case? What if I run an Internet-based business where claiming to use the reliability of the signed DNS records is part of the reassurance that I give to my customers. Whether it is just hype or actual value, it would conceivably be part of value perceived by the customer. Hence, it is contributing to my getting more business. Is that commercial use, even if I'm just using non-commercial BIND software? -- Bill@attmail.com billc@pegasus.ATT.COM or +1 908 576 2932, Fax x6406 William_J_Carpenter@ATT.COM AT&T Bell Labs / AT&T EasyLink Services LZ 3C-207   Received: from sol.tis.com by magellan.TIS.COM id aa05108; 5 Apr 94 13:40 EDT Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA29889; Tue, 5 Apr 94 13:40:02 EDT Message-Id: <9404051740.AA29889@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <5096.765567591.0@tis.com> Date: Tue, 05 Apr 1994 13:40:10 -0400 From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5096.765567591.1@tis.com> Enclosed below is my record of the meeting held during the last IETF meeting. Corrections from those who attended the meeting are hereby solicited. In particular, there is one issue that I had regarded on the slides for which I can not remember either the context or the resolution. I'd appreciate if someone could remind me. I will submit the revised minutes for the record on Monday, April 11 (or these if I get no comments). Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5096.765567591.2@tis.com> Content-Description: Meeting Minutes DNS Security WG Meeting Minutes March 1994 Seattle Recorded by Jim Galvin, Chair The DNS Security Working Group met on Tuesday morning for a 2.5 hour meeting. Charlie Kaufman and Donald Eastlake had previously submitted a proposal (as an internet draft) for enhancing the DNS to support a digital signature security service. This meeting was dedicated to a review of that proposal. The meeting began with a review of the desired requirements identified at the BOF meeting held at the November 1993 Houston meeting. Charlie and Donald then led a presentation and discussion of their proposal. The following issues were discussed and resolved as indicated. o choice of algorithm The proposal currently specifies the SHA and RSA algorithms. It was agreed to replace SHA with MD5, the current Internet preference. o revisit DNS architecture The addition of SIG RRs increases the probability that the maximum UDP payload per packet may be exceeded. The requirement that we remain backward compatible with the existing installed base and the lack of empirical data to support the premise caused us to agree to leave the DNS architecture alone. o where do SIG RRs go in the reply A question was raised as to whether which section of the reply the SIG RRs should be placed. This is an issue because it was noted that, if necessary, implementations may ignore (and truncate) the additional records portion of a reply. It was agreed to query Paul Mockapetris in particular and to followup on the mailing list. o key per zone or key per server The proposal currently specifies that a public/private key pair is assigned to a zone, which is responsible for signing its data. In this way the data may be distributed by any server and, in fact, the actual signing of the data may (and should) occur as an off-line function. In addition, a specification is included for servers to optionally sign responses to queries. At this time it was agreed to leave the optional alternative in the document. We will revisit this issue after we have some implementation experience. o split the document It was suggested that the document may be better organized as several related documents. It was agreed Donald and/or Charlie would initiate a discussion of this issue on the mailing list. o use of the NTP time service The proposal currently emphasizes (if not requires) the use of a reliable time service, in particular NTP. It was agreed that DNS should not depend on synchronized clocks. The authors agreed to rework this aspect of the proposal to not depend on synchronized clocks. o partial and/or hash records (** HELP HERE **) I have this item recorded on the slides but I don't recall the issue or the resolution. Can someone provide some context, please? o key management It was observed that an integral part of the proposal is the specification of a key management protocol. As the new security area director was present at the meeting he was asked if the security area believed it was appropriate to specify another key management protocol, observing that both PEM and SNMP Security have also specified key management protocols. The response was that this key management protocol was sufficiently different from the other two that it was valuable in its own right and should remain part of the proposal. The meeting concluded with Jim Galvin noting that TIS would be implementing the proposal using the bind implementation of the DNS as a baseline. This software would be openly available to the Internet community. This group expects to meet in Toronto. ------- =_aaaaaaaaaa0--   Received: from sol.tis.com by magellan.TIS.COM id aa05649; 5 Apr 94 15:35 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10666; Tue, 5 Apr 94 15:34:57 EDT Received: by relay.tis.com; id AA04579; Tue, 5 Apr 94 15:35:39 EDT Received: from relay.hp.com(15.255.152.2) by relay via smap (V1.3mjr) id sma004568; Tue Apr 5 15:35:05 1994 Received: from hpindbg.cup.hp.com by relay.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA24360; Tue, 5 Apr 1994 12:34:31 -0700 Received: by hpindsh.cup.hp.com (1.37.109.9Q/15.5+IOS 3.20+cup+OMrelay) id AA1865448453; Tue, 5 Apr 1994 12:34:29 -0700 From: Art Harkin Message-Id: <9404051234.ZM18652@hpindbg.cup.hp.com> Date: Tue, 5 Apr 1994 12:34:28 -0700 In-Reply-To: Greg_Campbell@metrico.metricom.com "Re: SIG RR location in responses, cc:Mail UUCPLINK 2.0 Undeliverable Message" (Apr 5, 7:07am) References: <9403057655.AA765554826@metrico.metricom.com> X-Mailer: Z-Mail (2.1.5 20sep93) To: Greg_Campbell@metrico.metricom.com, James M Galvin , Paul A Vixie Subject: Re: SIG RR location in responses, cc:Mail UUCPLINK 2.0 Undeliverable Message Cc: dns-security@tis.com On Apr 5, 7:07am, Greg_Campbell@metrico.metricom.com wrote: > Am I the only person reading all this who is concerned about > using RSA, a patented and licensed technology, for DNS security? > I am very reluctant to put into BIND any technology which would > require vendors to pay a royalty to RSA before they could ship > it with their systems. > > Two bits of information to keep in mind. First, RSADSI has made RSAREF > available for non-commercial use. However, I realize this does not > solve the "vendors packaging a product." For that, may I direct your > attention to the latest issue of Connexions, March 1984, in which > commandment number 1 of "The Ten Commandments of Domain Name Service" > is, "Thou shalt not run thy vendor's DNS software." > > During the IETF last week, in a private conversation, it was suggested > that the DNS may be one of those applications (e-mail is another) for > which the vendor release cycle is just slow enough to make waiting for > updated versions from vendors at least irresponsible. I, too, believe > this to be true. > I plead some ignorance on RSA royalty issues, in the past, I have not discovered such limitations with MD5's use within xntp. If someone is able to enlighten me via e-mail on what is actually subject to royalties, and what usage of public domain software will require such a license, I would appreciate it. Making a possibly ignorant stab at what I see to be a potentially dangerous viewpoint with DNS, even though it was one of Bryan Beecher's 10 DNS commandments. I think Bryan's point is well taken, vendors generally have lag times and there is a delay getting out new functionality (however, this part isn't set in stone tablets, there are ways of getting software out prior to the scheduled releases, if the changes merit it). Where I feel the danger lies is how this 'problem' has been intepreted into a rule that vendor software is to be discarded. This might be a simplistic view, there are many network admins unwilling to delve into the issues of running unsupported software. Not recognizing this can cause problems later. I feel a better approach is to encourage rapid deployment of new features in both commercial and non-commercial arenas. If the vendors can't be convinced, then the customers/users/admins should be convinced and they can apply pressure, if they can't be convinced, then maybe the technology is not addressing a generally needed concern on the Internet. The requirements, needs and timetables of vendors shouldn't delay an IETF technology's release on to the Internet, however the technology shouldn't at the same time cripple future vendor integration. Hopefully the IETF rough consensus is not building to a point where it is agreeable to ignore issues that may stall commercial use of technology. In particular for the dnssec WG, the glossing over the issues of RSA royalties with out determining the impact can be as bad a judgment as a poorly considered protocol change. If RSA royalties interfered with commercial use of BIND, than what would happen if vendors did not implement BIND past 4.9.2, because of a significant royalty cost? If something like this was to occur, I suspect we will be revisiting these issues again at a later date. -art -- ------------------------------------------------------------------------------ A r t H a r k i n Hewlett-Packard Company E-mail: ash@cup.hp.com Information Networks Division 19420 Homestead Road MS 43LN, Cupertino, CA 95014 Education should be as gradual as the moonrise, perceptible not in progress, but in result. ------------------------------------------------------------------------------   Received: from sol.tis.com by magellan.TIS.COM id aa06112; 5 Apr 94 16:44 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16238; Tue, 5 Apr 94 16:44:12 EDT Received: by relay.tis.com; id AA05274; Tue, 5 Apr 94 16:44:54 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma005262; Tue Apr 5 16:44:12 1994 Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22668; Tue, 5 Apr 1994 16:43:40 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA25266; Tue, 5 Apr 1994 16:43:38 -0400 Message-Id: <9404052043.AA25266@abyss.zk3.dec.com> To: galvin@tis.com Cc: dns-security@tis.com Subject: Re: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting Date: Tue, 05 Apr 94 16:43:38 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >o partial and/or hash records > > (** HELP HERE **) > > I have this item recorded on the slides but I don't recall the issue > or the resolution. Can someone provide some context, please? The issue was around the Partial RR Set Flag Signet - in particular whether this functionality is needed. If there are a large number of small resource records all of the same type, the current specification allows two different ways of signing them. They can all be concatenated and a single hash included in a Hashed Resource Record(s) Signet *or* they can be encoded in a series of Direct Resource Record Signets. If the second encoding is chosen and there are too many RRs to fit inside a single signature, the Partial RR Set Flag Signet is needed to assure the reader that it has seen all of them. The proposal from the floor was that the second encoding be disallowed in the case where the RRs didn't fit in a single signature, thus eliminating the need for the complexity of allowing the additional signet type. Don and I agreed that this was plausible thought that there might be cases where the second encoding would permit substantial efficiencies. I'm not sure what the resolution was (if any). I suspect we agreed to think about it. --Charlie   Received: from sol.tis.com by magellan.TIS.COM id aa06147; 5 Apr 94 16:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17267; Tue, 5 Apr 94 16:54:14 EDT Received: by relay.tis.com; id AA05429; Tue, 5 Apr 94 16:54:55 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma005422; Tue Apr 5 16:54:02 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA07101; Tue, 5 Apr 94 13:48:06 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21749; Tue, 5 Apr 1994 16:49:36 -0400 Message-Id: <9404052049.AA21749@skidrow.lkg.dec.com> To: James M Galvin Cc: dns-security@tis.com Subject: Re: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting In-Reply-To: Your message of "Tue, 05 Apr 94 13:40:10 EDT." <9404051740.AA29889@tis.com> Date: Tue, 05 Apr 94 16:49:35 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Jim, From: James M Galvin To: dns-security@tis.com > > DNS Security WG Meeting Minutes > March 1994 Seattle > > >Recorded by Jim Galvin, Chair > >... > >o use of the NTP time service > > The proposal currently emphasizes (if not requires) the use of a > reliable time service, in particular NTP. It was agreed that DNS > should not depend on synchronized clocks. The authors agreed to > rework this aspect of the proposal to not depend on synchronized > clocks. My understand was that the desire was to have to draft say that the resolver and server need only have approximately synchronized clocks (typically on the order of synchronized within a few hours) but to not mention NTP or any other particular way of achieving sychronization. >o partial and/or hash records > > (** HELP HERE **) > > I have this item recorded on the slides but I don't recall the issue > or the resolution. Can someone provide some context, please? I believe the point was raised that the ability to directly include RRs of a particular type in more than one SIG record was overly complicated in that it caused the need for the "partial RR" signet to be sure you had all the relevant SIGs. The suggestion was that if all the RRs of a particular type did not fit directly into one SIG, the use of a hashed signet be required which would in turn require the RRs to be present in plain text outside the SIG. The resolution at the meeting was to wait for implementation experience to see if this simplification to the proposal made sense. > >... > Donald   Received: from sol.tis.com by magellan.TIS.COM id aa06624; 5 Apr 94 19:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24522; Tue, 5 Apr 94 19:50:33 EDT Received: by relay.tis.com; id AA06444; Tue, 5 Apr 94 19:51:16 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma006440; Tue Apr 5 19:50:28 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 5 Apr 1994 16:49:00 -0700 Message-Id: <199404052349.AA06461@zephyr.isi.edu> To: Paul A Vixie Cc: dns-security@tis.com, namedroppers@nic.ddn.mil Reply-To: pvm@isi.edu Subject: Re: SIG RR location in responses In-Reply-To: Your message of Tue, 05 Apr 1994 01:54:51 -0700. Date: Tue, 05 Apr 94 16:47:20 PDT From: Paul Mockapetris > Am I the only person reading all this who is concerned about using RSA, > a patented and licensed technology, for DNS security? If RSA has put > their algorythm into the public domain recently, I'll withdraw my > objection. But I don't think they've done that, and I am very reluctant > to put into BIND any technology which would require vendors to pay a > royalty to RSA before they could ship it with their systems. (I'm not > saying I won't do it, but I'm definitely reluctant.) > -- > Paul Vixie > Redwood City, CA > decwrl!vixie!paul > No. I objected to starting down this track without a reasonable agreement in hand at the Houston IETF. (Other opinions differed) I said the same thing in Seattle. Steve Crocker told me he was going to work with PKP/RSA to create an agreement. With a reasonable aagreement, I see no reason to object, but until then... I also think namedroppers and bind mailing lists should be kept informed of architectural implications of the proposed changes. Suggest you keep the heat up on IETF leadership on this one, say the security area directorate. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa06868; 5 Apr 94 22:10 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA25974; Tue, 5 Apr 94 22:10:37 EDT Message-Id: <9404060210.AA25974@tis.com> To: dns-security@tis.com, namedroppers@nic.ddn.mil, crocker@tis.com Subject: Possible use of public key technology in DNS authentication Date: Tue, 05 Apr 94 22:10:33 -0400 From: Stephen D Crocker In a message attached in whole below, Paul Mockapetris wrote: > Steve Crocker told me he was going to work with PKP/RSA to create an > agreement. With a reasonable agreement, I see no reason to object, > but until then... Paul describes a brief hallway conversation, and some amplification and clarification is in order. Concern is expressed about the availability of public key technology for use in the DNS environment. I expressed -- ar at least intended to express -- confidence that the technology would be available. Let me make it clear that I do not speak for either Public Key Partners ("PKP") nor RSA Data Security Inc ("RSA"), so the opinions I expressed are my own. During the conversation, I expressed the opinion that it should be possible to work out something reasonable with RSA, and that I would undertake some discussions. I have not done so yet, and nothing I said then or in this note should be construed as reflecting the position of either RSA or PKP. Similarly, I cannot -- and did not intend to -- speak authoritatively for the ISOC, IETF, IESG or IAB. I can, however, attempt to discuss these matters in good faith and bring proposals to the table for review by all parties. With those caveats established, it's useful to note some of the indicators that suggest the technology is likely to be accessible for our purposes. Two packages are available from RSA free of charge for non-commercial use. ("Non-commercial" means somewhat different things in different contexts, so it's important to read the specific definition in any particular situation. However, the details are not important for this note.) One package is RSAREF, a source code collection of the various cryptographic routines. The other, just recently released, is RIPEM/SIG, an object-code, signature-only version of RIPEM. RIPEM is approximately "PEM-lite". RSA encourages the use of these packages for the development of new applications. Without having worked out the specific details, it seems probable that the capabilities needed for DNS authentication are within the capabilities included in RSAREF. Further, since only authentication is needed, it is likely that object code versions of the code can be granted mass market export licenses, as has been done for RIPEM/SIG. (Licensing from RSA and/or PKP is only one of two traditional bogeymen haunting public key technology; the other is export control. Both have to be addressed when planning wide spread deployment of this technology.) RSA also sells its software, and it has a number of license agreements in place with companies large and small. To the best of my knowledge, including the direct negotiations I have had with RSA for our own licenses, licensing terms should not stand in the way of whatever approach we will find useful for securing DNS. We now come to a chicken and egg problem. RSA and PKP usually license their software or technology to companies, not standards bodies. Similarly, the IETF has not heretofore contracted with patent holders for specific terms. Yet the tone of the notes from Paul Mockapetris and Paul Vixie suggest we should not design a public-key based solution to DNS authentication without a specific license arrangement in place. While it may be possible to clear away much of the uncertainty ahead of time, the only acid test will come after the design is complete and individual implementors conduct specific discussions with RSA and/or PKP. I agree that all other things being equal, royalty-free technology is preferable to royalty-bearing technology, but I also believe that it's poor practice to avoid the best technology just because it's patented. The Ethernet was patented, and the Internet probably wouldn't exist without it. This is not the first time we've dealt with this issue. The use of patented technology in Internet standards has been addressed by the IAB and IESG in both RFC 1310 and RFC 1602. The latter was issued in March 1994 and applies to specifications adopted on or after April 1, 1994 (no fooling). The relevant section is: 5.4.2. Standards Track Documents (A) ISOC will not propose, adopt, or continue to maintain any standards, including but not limited to standards labelled Proposed, Draft or Internet Standards, which can only be practiced using technology or works that are subject to known copyrights, patents or patent applications, or other rights, except with the prior written assurance of the owner of rights that: l. ISOC may, without cost, freely implement and use the technology or works in its standards work; 2. upon adoption and during maintenance of an Internet Standard, any party will be able to obtain the right to implement and use the technology or works under specified, reasonable, non-discriminatory terms; and 3. the party giving the assurance has the right and power to grant the licenses and knows of no other copyrights, patents, patent applications, or other rights that may prevent ISOC and members of the Internet community from implementing and operating under the standard. With respect to the use of public key technology, the assurances required under 5.4.2(A)2 have already been provided and are documented in RFC 1170. This documentation was required prior to the advancement of the PEM specifications to Proposed Standard status, and the official IESG notice requesting advancement of those specifications to Proposed Standard status cited RFC 1170 and discussed the issues. It is useful to note that RFC 1170 is not specific to PEM and applies to all use of public key technology. In the event that public key technology is used in the design of DNS authentication or any other Internet specification that is put on the standards track, it is perfectly appropriate to revisit the agreements and assurances. With RFC 1170 already in hand, the results should be similar. My belief is we should design the best authentication scheme we can for DNS. If this means using public key technology -- and I believe it does -- then so be it. Steve +-------------------------------------+-------------------------------+ | Steve Crocker | Voice: 301-854-6889 | | Trusted Information Systems | FAX: 301-854-5363 | | 3060 Washington Road (Route 97) |-------------------------------| | Glenwood, MD 21738 | Internet: crocker@tis.com | +-------------------------------------+-------------------------------+ > Reply-To: pvm@isi.edu > Sender: majordomo@internic.net > From: Paul Mockapetris > To: Paul A Vixie > cc: dns-security@tis.com, namedroppers@nic.ddn.mil > Date: Tue, 05 Apr 94 16:47:20 PDT > Subject: Re: SIG RR location in responses > > > Am I the only person reading all this who is concerned about using RSA, > > a patented and licensed technology, for DNS security? If RSA has put > > their algorithm into the public domain recently, I'll withdraw my > > objection. But I don't think they've done that, and I am very reluctant > > to put into BIND any technology which would require vendors to pay a > > royalty to RSA before they could ship it with their systems. (I'm not > > saying I won't do it, but I'm definitely reluctant.) > > -- > > Paul Vixie > > Redwood City, CA > > decwrl!vixie!paul > > > > No. > > I objected to starting down this track without a reasonable agreement > in hand at the Houston IETF. (Other opinions differed) I said the > same thing in Seattle. Steve Crocker told me he was going to work > with PKP/RSA to create an agreement. With a reasonable agreement, I > see no reason to object, but until then... > > I also think namedroppers and bind mailing lists should be > kept informed of architectural implications of the proposed changes. > > Suggest you keep the heat up on IETF leadership on this one, say the > security area directorate. > > paul > > USC/Information Sciences Institute phone: 310-822-1511 x285 > 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 > 90292   Received: from sol.tis.com by magellan.TIS.COM id aa07120; 6 Apr 94 1:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27375; Wed, 6 Apr 94 01:01:02 EDT Received: by relay.tis.com; id AA07655; Wed, 6 Apr 94 01:01:46 EDT Received: from optima.cs.arizona.edu(192.12.69.5) by relay via smap (V1.3mjr) id sma007652; Wed Apr 6 01:01:14 1994 Received: from baskerville.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA03312; Tue, 5 Apr 1994 22:01:00 MST Received: (from ho@localhost) by baskerville.cs.arizona.edu (8.6.7/8.6.6) id WAA04399; Tue, 5 Apr 1994 22:00:58 -0700 Date: Tue, 5 Apr 1994 22:00:58 -0700 From: Hilarie Orman Message-Id: <199404060500.WAA04399@baskerville.cs.arizona.edu> To: crocker@tis.com Cc: namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: Your message <9404060210.AA25974@tis.com> Subject: Re: Possible use of public key technology in DNS authentication Is this to say that the assurances required under 5.4.2(A)1 and 3 have not been provided? If this is correct, will someone be talking to RSA about getting the assurances? Another question: are implementors free to implement RSA patented algorithms for non-commercial use? Or are they only free to use RSAREF?   Received: from sol.tis.com by magellan.TIS.COM id aa10990; 6 Apr 94 8:45 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA12855; Wed, 6 Apr 94 08:45:12 EDT Message-Id: <9404061245.AA12855@tis.com> To: Hilarie Orman Cc: crocker@tis.com Cc: namedroppers@nic.ddn.mil, dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication In-Reply-To: Your message of "Tue, 05 Apr 94 22:00:58 PDT." <199404060500.WAA04399@baskerville.cs.arizona.edu> Date: Wed, 06 Apr 94 08:45:09 -0400 From: Stephen D Crocker Hilarie, I focused on 5.4.2(a)2 because it pertained to implementation. So far as I can tell, the full assurances required under 5.4.2(A)1, 5.4.2(A)2 and 5.4.2(A)3 were obtained previously, as documented in RFC 1170. As I said before, it's entirely reasonable to revisit and redocument the details, but my strong belief is that this is not a showstopper and should not affect our design choices. With respect to your second question, are you asking the generic question about patent law, i.e. (a) "are implementors free to implement for non-commercial use?", or are you asking (b) whether RSA has provided general permission for free implementation of their technology for non-commercial use? As neither a lawyer nor an RSA representative, I can give only my general understanding, which is (a) I believe patents cover all use, commercial or not, and (b) I don't think RSA has given blanket permission for non-commercial implementations other than through RSAREF, but I strongly recommend you take this up with them. Steve > From: Hilarie Orman > To: crocker@tis.com > cc: namedroppers@nic.ddn.mil, dns-security@tis.com > Date: Tue, 5 Apr 1994 22:00:58 -0700 > Subject: Re: Possible use of public key technology in DNS authentication > > Is this to say that the assurances required under 5.4.2(A)1 and 3 have > not been provided? If this is correct, will someone be talking to RSA > about getting the assurances? > > Another question: are implementors free to implement RSA patented > algorithms for non-commercial use? Or are they only free to use > RSAREF?   Received: from sol.tis.com by magellan.TIS.COM id aa07383; 6 Apr 94 3:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28828; Wed, 6 Apr 94 03:45:15 EDT Received: by relay.tis.com; id AA08113; Wed, 6 Apr 94 03:45:58 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008109; Wed Apr 6 03:45:12 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Apr 94 16:37:18 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404060737.AA26241@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses To: "Donald E. Eastlake 3rd" Date: Wed, 6 Apr 94 16:37:16 JST Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm X-Mailer: ELM [version 2.3 PL11] > >SIGs are less valuable than glue As because they can be asked with a separate > >query. > > Why can't you ask for the glue A's in a separate query? Sigh... To make the query, you must know A's. Read the section 4.2.1 of RFC1034, if you can't understand it. The point here is that truncation is a real issue only for glue records. So, you don't have to think truncation of SIG or RSA records in additional section so seriously. In general, you are trying to do: 1) Make DNS secure 2) Make DNS reply short In doing 2), your proposal includes several modificatiton to the architecture of DNS. But as the truncation is not a so severe issue, I don't think its worthwhile to do so. So, I suggest not to pursue 2) so much and simplify the proposal. That is: 1) Don't introduce new abbreviaiton and use the RR format currently used in the DNS packets. 2) Always use MD5 3) Use a single record for authenticaiton, not multiple SIGs > >Moreover, aren't the current name servers copying the unused bits > >of query packets? > > I don't see what that has to do with the location of spontaneously > included SIG RRs on queries from security aware resolvers to security > aware servers, which is what I was discussing. If a security aware > resolver makes a query with the (SD) bit on in the header to a > non-security aware server, it will probably be copied into the > response, but so what? SD copied by security unaware forwarders will cause a lot of problems. > >Is it really meaningfull to remove one or two 14 byte record when you > >are using 128 byte (1024) SIG RR(s)? > > I make no assumptions about the total size of RRs Then, you can't evaluate the effect of your optimizaiton. > Eliminating an RR when it is incorporated inside the SIG is optional > under the current draft. Name servers with different OPTIONS can't communicate each other. So, it can't be optional. > But there are clearly cases when not > eliminating a plain text RR that did fit into the SIG will cause > truncation. It might, for example, force the RSA RR additional > information mentioned above to not fit and cause truncation. Unlike glue As, you can remove large RRs from the additional section without causing any problem. OK? > As > tentatively decided at the DNSSEC WG meeting in Seattle, I would wait > for implementation experience to indicate the need before changing > this aspect of the draft. If it is option, what will be implemented? > I thought people considered the draft complicated enough as it is. That's why I suggest simplification. Why don't we use MD5 all the time? > suppose some compression scheme could be added but I would not want to > do that unless implementation experience indicated it was necessary. > > If I did want to add compression, No, please. > Even assuming you can get things to fit in 512 byte UDP datagrams with > your simplifications, which is not clear to me, and even if it is > "rare" for for there to be more than 6 RR types for a given owner name > and class, I find it totally unacceptable to only secure common cases > in the DNS. I believe that a DNS security proposal must cover all but > the most preverse cases. What I suggested was to use block authentication to cover larger number of signets. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa07523; 6 Apr 94 4:09 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28964; Wed, 6 Apr 94 04:09:17 EDT Received: by relay.tis.com; id AA08339; Wed, 6 Apr 94 04:10:01 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008328; Wed Apr 6 04:09:13 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Apr 94 16:58:51 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404060759.AA26399@necom830.cc.titech.ac.jp> Subject: Real truncation problem To: "Donald E. Eastlake 3rd" Date: Wed, 6 Apr 94 16:58:48 JST Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm X-Mailer: ELM [version 2.3 PL11] I found the current proposal unnecessarily contains real truncation problem. As the largest modulus is 2048 bits, usual key size will be about 1000 bits or 130 bytes. If such a large key is chosen by administrators (as the cost to choose the longer key is not so large, most of the security conscious administrators (that is, all those who use secure DNS) will use the largest possible, I think), a DNS packet containing 4 keys will be truncated. As having 2 keys for a single purpose is usually enough, it should not be an issue. But the current proposal assign only a single RSA RR name to 3 different purposes: authentication of a zone, a host and a user. So, real truncation may occur. Moreover, it will make additional section processing difficult causing a lot of truncations. So, we should have 3 different RR names for 3 different purposes: ZRSA for zones, HRSA for hosts, and MRSA for mails. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa16312; 6 Apr 94 16:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13594; Wed, 6 Apr 94 16:27:11 EDT Received: by relay.tis.com; id AA13264; Wed, 6 Apr 94 16:27:56 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma013255; Wed Apr 6 16:27:08 1994 Received: by gw.home.vix.com id AA15278; Wed, 6 Apr 94 13:26:57 -0700 Date: Wed, 6 Apr 94 13:26:57 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: Possible use of public key technology in DNS authentication Organization: Vixie Enterprises Message-Id: References: <9404061245.AA12855@tis.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: crocker@tis.com's message of 6 Apr 1994 06:29:08 -0700 The question I'd like to see someone take up with RSA (and I suppose that someone could be me if there's no designated RSA delegate from the WG) is: IF a DNS Security protocol is approved by the IAB, AND that protocol specifies the use of a PK system AND the PK system specified is one patented by RSA THEN (1) will i be in trouble if i publish a version of BIND that includes full source code to the implementation of the above (2) will i have to alter my existing BSD-derived copyright in any way (it currently specifies unlimited use and unlimited redistribution) (3) will vendors who include such a BIND in their operating systems be at risk from lawsuits from RSA if they don't pay license fees to RSA? Steve Crocker mentioned Ethernet as an example of a previous patented technology whose licensing restrictions didn't seem to impede Ethernet's tremendous usefulness or the Internet's growth. I almost bought it. But then I realized that any *particular* user of the Internet could avoid paying, either directly or indirectly, any licenses fees or royalties to the Digital/Intel/Xerox Ethernet consortium, through the simple expedient of not buying any Ethernet hardware. RSA in DNS would have much a broader effect: within a few years after Secure DNS is implemented, *noone* will be able to use the Internet without using the RSA technology. If the only people who are allowed to *use* the RSA technology are those who are either not doing commerce on the Internet or who pick up BIND on their own because their vendor doesn't want to pay RSA's license fees or doesn't include BIND at all, then I believe we'll have done a very bad thing. The overwhelming majority of new Internet hosts use system software straight from their vendors. What this looks like from here is a coup attempt by RSA. I'm still not ready to say that BIND won't ever include licensed technology that vendors won't be able to incorporate into their products without paying patent royalties. We're a ways off from having to make that decision, anyway. But I think it behooves the IETF, as supposedly representing the interests of the Internet community, to think VERY CAREFULLY about the implications of giving a company like RSA this kind of monopolistic cash cow. Now, who can answer my Big Question (see above)? If noone here is willing to contact RSA to ask it, then who at RSA should I talk to? I don't think this ought to be my job, since I'm more concerned as an implementor and as an citizen Internet than as a pseudo-member of the WG. This issue falls, in my opinion, squarely in the province of the area directorate or perhaps the IAB's industry liason (if there even is such a thing). But since I generally loathe people who say ``that's not my job,'' I **will** make the calls and get an official answer out of RSA if noone else thinks that it's *their* job to do that. Steve, I don't want you to take this personally. But as a bear of very little brain, I can't follow the mumbo jumbo in 5.4.2(A)1 et al. I need a simple answer to what I hope is a very simple question. I happen to think that the rest of the WG ought to want to hear the answer just as badly as I do, but that's something I'll address at a later date. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa16618; 6 Apr 94 18:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19189; Wed, 6 Apr 94 17:44:24 EDT Received: by relay.tis.com; id AA13955; Wed, 6 Apr 94 17:45:08 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma013950; Wed Apr 6 17:44:18 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA04842; Wed, 6 Apr 94 14:33:41 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA10640; Wed, 6 Apr 1994 17:35:09 -0400 Message-Id: <9404062135.AA10640@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-Reply-To: Your message of "Wed, 06 Apr 94 16:37:16 +0200." <9404060737.AA26241@necom830.cc.titech.ac.jp> Date: Wed, 06 Apr 94 17:35:09 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm >> >SIGs are less valuable than glue As because they can be asked with a separate >> >query. >> >> Why can't you ask for the glue A's in a separate query? > >Sigh... To make the query, you must know A's. Read the section 4.2.1 >of RFC1034, if you can't understand it. Well, I went and read Section 4.2.1 of RFC 1034 very carefully and it didn't change my opinion that you could retrieve the type A glue record with a separate query, just like you can retrieve the RSA and/or SIG RR's with a separate query. You seem to be assuming that I meant an A RR query to the server pointed to by the NS RR and, as you say, you can't query that unless you have its IP address. What I meant was an A RR query to the same server where you initially found the NS for this lower level zone, i.e., the server where the A record is present as glue. Would this actually not work in current implementations? >The point here is that truncation is a real issue only for >glue records. So, you don't have to think truncation of >SIG or RSA records in additional section so seriously. As long as you need the A glue RR and the RSA RR and the SIG RR signing them to securely look into a zone, I just don't see that much difference between truncation losing different ones of them. So I guess if you want it changed to give A records higher priority, I don't see that it hurts any. >In general, you are trying to do: > 1) Make DNS secure > 2) Make DNS reply short > >In doing 2), your proposal includes several modificatiton to the >architecture of DNS. But as the truncation is not a so severe >issue, I don't think its worthwhile to do so. > >So, I suggest not to pursue 2) so much and simplify the proposal. > >That is: > 1) Don't introduce new abbreviaiton and use the RR format > currently used in the DNS packets. > 2) Always use MD5 > 3) Use a single record for authenticaiton, not multiple SIGs Re your points 1 & 2: A specific requirement decided at the Houston IETF was not to take significantly more queries. If you start getting lots of truncation, you will start having to make twice as many queries. Many people think this would be a problem. Re your point 3: I am not willing to accept the limits a single SIG RR with only hash signets places on the number of types of RR you can have under a name. Even completely ignoring glue and message signets, you need 18 bytes. With the minimum allowed key size, then only 3 types of RRs you would be allowed to have securely under a name. >> >Moreover, aren't the current name servers copying the unused bits >> >of query packets? >> >> I don't see what that has to do with the location of spontaneously >> included SIG RRs on queries from security aware resolvers to security >> aware servers, which is what I was discussing. If a security aware >> resolver makes a query with the (SD) bit on in the header to a >> non-security aware server, it will probably be copied into the >> response, but so what? > >SD copied by security unaware forwarders will cause a lot of problems. Ahh... It was not clear to me that you were talking about copying into forwarded requests rather than responses. If they are being copied forward like that, then it clearly is a problem. The next thing I would suggest is not to set the SD bit until you actually get a reply with the SA (security available bit). This means your first query would be less efficient but you would cache this flag and later queries could be more efficient. If unused bits are also being copied back into replies sent by servers in response to recursive queries from the bit set on replies they receive, then using header bits to indicate security awareness is pretty hopeless and security awareness will probably have to wait for "DNS-II" or whatever based on a different op code or something else that does not have these unused header bit problems. >> >Is it really meaningfull to remove one or two 14 byte record when you >> >are using 128 byte (1024) SIG RR(s)? >> >> I make no assumptions about the total size of RRs > >Then, you can't evaluate the effect of your optimizaiton. What I meant was that I tried to make the minimum of limiting assumptions on the total size of RRs. By not assuming such limits, I came up with a scheme which works when the optimizations it proposes are required and when a scheme without such optimizations will not work. Thus, under my broad assumptions, I can evaluate my optimizations as being required to meet the dns security design goals. >> Eliminating an RR when it is incorporated inside the SIG is optional >> under the current draft. > >Name servers with different OPTIONS can't communicate each other. >So, it can't be optional. Why can't they communicate with each other? Under the proposal, a security aware server composing a reply to a security aware resolver can surpress RR's included in a SIG or not. A security aware resolver has to be able to handle it either way. Under the general Internet principle of being conservative in what you send and liberal in what you accept, security aware servers should always surpress the RR in replies they send but security aware resolvers should accept replies where they are not surpressed. >> But there are clearly cases when not >> eliminating a plain text RR that did fit into the SIG will cause >> truncation. It might, for example, force the RSA RR additional >> information mentioned above to not fit and cause truncation. > >Unlike glue As, you can remove large RRs from the additional >section without causing any problem. OK? It causes the problem of twice as many queries. >> As >> tentatively decided at the DNSSEC WG meeting in Seattle, I would wait >> for implementation experience to indicate the need before changing >> this aspect of the draft. > >If it is option, what will be implemented? One would guess that if something is an implementation option and there are enough different implemenations, it would be implemented both ways, although the draft clearly recommends surpressing RRs incorprated in a SIG (but only when a security aware server is composing a reply to a security aware resolver) so maybe everyone would implement it that way. Maybe the draft should be changed to say the supression is mandatory... >> I thought people considered the draft complicated enough as it is. > >That's why I suggest simplification. Why don't we use MD5 all the time? Because it leads to bigger replies, more truncation, and more queries. >> suppose some compression scheme could be added but I would not want to >> do that unless implementation experience indicated it was necessary. >> >> If I did want to add compression, > >No, please. Sorry, I thought you were complaining about the lack of compression of RRs when they were incorporated in SIGs. Certainly more compression could be done. >> Even assuming you can get things to fit in 512 byte UDP datagrams with >> your simplifications, which is not clear to me, and even if it is >> "rare" for for there to be more than 6 RR types for a given owner name >> and class, I find it totally unacceptable to only secure common cases >> in the DNS. I believe that a DNS security proposal must cover all but >> the most preverse cases. > >What I suggested was to use block authentication to cover larger >number of signets. ? Block authentication? Do you mean transaction/message authentication? If you suggested something like this in an earlier message, either I didn't understand it or I don't remember it. > Masataka Ohta To: Masataka Ohta cc: "Donald E. Eastlake 3rd" , dns-security@tis.com In-reply-to: Your message of "Wed, 06 Apr 94 16:58:48 +0200." <9404060759.AA26399@necom830.cc.titech.ac.jp> -------- From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm >I found the current proposal unnecessarily contains real truncation >problem. > >As the largest modulus is 2048 bits, usual key size will be about 1000 >bits or 130 bytes. The largest modulus allowed in the present proposal is 2040 bits and it claims to impose a floor of 641 bits but there is no enforecment mechanism proposed for this minimum. (At one point I was considering enforcing this by having the modulus length of the key be the modulus length byte as an unsigned integer plus 64. This would really impose a 512 bit floor and allow moduluses up to 2552 bits.) >If such a large key is chosen by administrators (as the cost to choose >the longer key is not so large, most of the security conscious >administrators (that is, all those who use secure DNS) will use the >largest possible, I think), a DNS packet containing 4 keys will be >truncated. ? The largest key modulus is 2040 bits so I don't understand why you say administrators who will use the largest possible will use 1000 bits. I should think DNS administrators will try to pick what works best. We can recommend things in the standard. I think a lot of people will use keys around 800 or 900 bits which is quite safe for now. The draft allows up to over 2000 bits for possible use later when computers and factoring algorithms have gotten better. Probably by then some way to great around the 512 byte DNS UDP limit will be in effect also. >As having 2 keys for a single purpose is usually enough, it should not >be an issue. > >But the current proposal assign only a single RSA RR name to 3 >different purposes: authentication of a zone, a host and a user. >So, real truncation may occur. > >Moreover, it will make additional section processing difficult causing >a lot of truncations. > >So, we should have 3 different RR names for 3 different purposes: >ZRSA for zones, HRSA for hosts, and MRSA for mails. Although I think it will be extremely rare for the same name to be a zone, a host, and a user, this is an interesting proposal. It is the case that the different types of RSA RR were going to have to be additional info for different types of queries. For exmple, the Zone RSA if you get NS, the Host RSA if you get A, and the User RSA if you get some of the more obsure M* RRs (but not MX which is a host). I would assume that all the additional section processing in current implementations uses type and would prefer not to delve into the RDATA area as would be required in the current proposal. You would still need the flags byte for the mandatory and authority bits. It does use up more RR type numbers but overall I think it is a good idea. What do other people think about it? > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa17030; 6 Apr 94 23:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28908; Wed, 6 Apr 94 23:15:09 EDT Received: by relay.tis.com; id AA15740; Wed, 6 Apr 94 23:15:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma015712; Wed Apr 6 23:14:57 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 7 Apr 94 12:04:19 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404070304.AA00261@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses & Re: Real truncation problem To: "Donald E. Eastlake 3rd" Date: Thu, 7 Apr 94 12:04:18 JST Cc: dns-security@tis.com In-Reply-To: <9404062135.AA10640@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 6, 94 5:35 pm X-Mailer: ELM [version 2.3 PL11] > Well, I went and read Section 4.2.1 of RFC 1034 very carefully and it > didn't change my opinion that you could retrieve the type A glue > record with a separate query, just like you can retrieve the RSA > and/or SIG RR's with a separate query. You seem to be assuming that I > meant an A RR query to the server pointed to by the NS RR and, as you > say, you can't query that unless you have its IP address. What I > meant was an A RR query to the same server where you initially found > the NS for this lower level zone, i.e., the server where the A record > is present as glue. Would this actually not work in current > implementations? It does not work. What do you think "truncation problem" means, at all? > As long as you need the A glue RR and the RSA RR and the SIG RR > signing them to securely look into a zone, I just don't see that much > difference between truncation losing different ones of them. Anyway, if you think the problem does not exist, it's OK. If you have any further concern on the real truncation prolem related to glue records, ask it in "namedroppers". The conclusion here is not to make secure DNS complex only trying to solve non-existent problem. That's because you don't udnerstand > >That is: > > 1) Don't introduce new abbreviaiton and use the RR format > > currently used in the DNS packets. > > 2) Always use MD5 > > 3) Use a single record for authenticaiton, not multiple SIGs > > Re your points 1 & 2: > A specific requirement decided at the Houston IETF was not to > take significantly more queries. If you start getting lots of > truncation, you will start having to make twice as many queries. Many > people think this would be a problem. With 1 and 2, there will be no extra queries, because there won't be much truncations occure. > Re your point 3: > I am not willing to accept the limits a single SIG RR with > only hash signets places on the number of types of RR you can have > under a name. Even completely ignoring glue and message signets, you > need 18 bytes. With the minimum allowed key size, then only 3 types > of RRs you would be allowed to have securely under a name. I'm assuming to use something like RSA-CBC here. > >SD copied by security unaware forwarders will cause a lot of problems. > > Ahh... It was not clear to me that you were talking about copying > into forwarded requests rather than responses. If they are being > copied forward like that, then it clearly is a problem. The next > thing I would suggest is not to set the SD bit until you actually get > a reply with the SA (security available bit). This means your first > query would be less efficient but you would cache this flag and later > queries could be more efficient. It might be an acceptable hack if your scheme were already widely deplyed. Otherwise, IMHO, it is too complex to be acceptable. > If unused bits are also being copied > back into replies sent by servers in response to recursive queries > from the bit set on replies they receive, then using header bits to > indicate security awareness is pretty hopeless and security awareness > will probably have to wait for "DNS-II" or whatever based on a > different op code or something else that does not have these unused > header bit problems. I'm afraid your proposal, using new representation of RR records and breaks several DNS architechture, is pretty much close to DNS-II. SD bit on means too much. > >> >Is it really meaningfull to remove one or two 14 byte record when you > >> >are using 128 byte (1024) SIG RR(s)? > >> > >> I make no assumptions about the total size of RRs > > > >Then, you can't evaluate the effect of your optimizaiton. > > What I meant was that I tried to make the minimum of limiting > assumptions on the total size of RRs. Neither do I. > By not assuming such limits, I > came up with a scheme which works when the optimizations it proposes > are required and when a scheme without such optimizations will not > work. Thus, under my broad assumptions, I can evaluate my > optimizations as being required to meet the dns security design goals. My opinion is that with usual circumstance, your optimization is ineffective and, thus, should be removed. > >> Eliminating an RR when it is incorporated inside the SIG is optional > >> under the current draft. > > > >Name servers with different OPTIONS can't communicate each other. > >So, it can't be optional. > > Why can't they communicate with each other? > > Under the proposal, a security aware server composing a reply to a > security aware resolver can surpress RR's included in a SIG or not. A > security aware resolver has to be able to handle it either way. Then, it is mandatory for resolvers. > Under > the general Internet principle of being conservative in what you send > and liberal in what you accept, security aware servers should always > surpress the RR in replies they send but security aware resolvers > should accept replies where they are not surpressed. I'm afraid you completely misunderstand the Internet. Under the general Internet principle of being conservative in what you send, security aware servers should always ADD the RR in replies, which is what current DNS is doing. As such a behaviour is quite basic to the current DNS, even the most conservative secutiry aware resolvers don't have to accept completely broken replies. Your proposal to try to handle partial RRs makes many assumptions, such as caching behaviour, of the current implementaiton of DNS. > >> But there are clearly cases when not > >> eliminating a plain text RR that did fit into the SIG will cause > >> truncation. It might, for example, force the RSA RR additional > >> information mentioned above to not fit and cause truncation. > > > >Unlike glue As, you can remove large RRs from the additional > >section without causing any problem. OK? > > It causes the problem of twice as many queries. In rare case when SIG is large, yes, which affect the expected number of queries very little. > >> I thought people considered the draft complicated enough as it is. > > > >That's why I suggest simplification. Why don't we use MD5 all the time? > > Because it leads to bigger replies, more truncation, and more queries. No. If RRs of a type is large, truncation occurs anyway. If it is small truncation won't occure. The latter is almost always the case. > >> suppose some compression scheme could be added but I would not want to > >> do that unless implementation experience indicated it was necessary. > >> > >> If I did want to add compression, > > > >No, please. > > Sorry, I thought you were complaining about the lack of compression of > RRs when they were incorporated in SIGs. Certainly more compression > could be done. I'm complaining about the complexity of your scheme trying to reduce the packet size which will, most of the time, result in the increase of the size. > >What I suggested was to use block authentication to cover larger > >number of signets. > > ? Block authentication? Do you mean transaction/message > authentication? If you suggested something like this in an earlier > message, either I didn't understand it or I don't remember it. As I wrote, something like RSA-CBC. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa27610; 7 Apr 94 17:25 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02805; Thu, 7 Apr 94 17:25:20 EDT Received: by relay.tis.com; id AA20789; Thu, 7 Apr 94 17:26:05 EDT Received: from ns.novell.com(137.65.1.1) by relay via smap (V1.3mjr) id sma020781; Thu Apr 7 17:25:34 1994 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04899; Thu, 7 Apr 94 15:30:18 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA25281; Thu, 7 Apr 94 14:24:54 PDT Date: Thu, 7 Apr 94 14:24:53 PDT Message-Id: <9404072124.AA25281@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: dns-security@tis.com From: Greg Minshall Subject: DNS security draft Some thoughts on the DNS security draft: 4. Could at least the SA (security available) bit be carried in some other form rather than one of the reserved bits in the header? Inferred, say, from the presence of an unsolicited SIG? Or, some other unsolicited record in the reply? 5.1. Can a *request* be authenticated? 5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla encoding (with a hashed signet)? Greg Minshall   Received: from sol.tis.com by magellan.TIS.COM id aa28700; 7 Apr 94 23:23 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09852; Thu, 7 Apr 94 23:22:54 EDT Received: by relay.tis.com; id AA22174; Thu, 7 Apr 94 23:23:41 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma022171; Thu Apr 7 23:22:47 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA07286; Thu, 7 Apr 94 23:21:26 EDT Date: Thu, 7 Apr 94 23:21:26 EDT From: Theodore Ts'o Message-Id: <9404080321.AA07286@tsx-11.MIT.EDU> To: Paul A Vixie Cc: dns-security@tis.com In-Reply-To: Paul A Vixie's message of Wed, 6 Apr 94 13:26:57 -0700, Subject: Re: Possible use of public key technology in DNS authentication Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 6 Apr 94 13:26:57 -0700 From: Paul A Vixie IF a DNS Security protocol is approved by the IAB, AND that protocol specifies the use of a PK system AND the PK system specified is one patented by RSA THEN (1) will i be in trouble if i publish a version of BIND that includes full source code to the implementation of the above If you publish a version of BIND that references routines used in the RSAREF library, you're fine. The RSAREF library has been released by RSADSI, and includes a free, personal, non-commercial use license to use the routines in that library, which include RSA and a routine to do Diffie-Helman key exchange. Recently that license has been expanded to include use by commercial companies so long as the use of RSAREF does not directly contribute to their commercial dealings. Since DNS is basically a infrastructure service, this would mean that any company would be able to get and compile RSAREF and use it for their own internal use without any problems. (2) will i have to alter my existing BSD-derived copyright in any way (it currently specifies unlimited use and unlimited redistribution) The copyright on your code can remain the same; this doesn't affect the copyright on the RSAREF code, though. (3) will vendors who include such a BIND in their operating systems be at risk from lawsuits from RSA if they don't pay license fees to RSA? If vendors include such in the operating system, they will indeed need to get a license from RSA before they can distribute it. RSA in DNS would have much a broader effect: within a few years after Secure DNS is implemented, *noone* will be able to use the Internet without using the RSA technology. If the only people who are allowed to *use* the RSA technology are those who are either not doing commerce on the Internet or who pick up BIND on their own because their vendor doesn't want to pay RSA's license fees or doesn't include BIND at all, then I believe we'll have done a very bad thing. The overwhelming majority of new Internet hosts use system software straight from their vendors. I don't buy that. DNS resolvers will be able to use the internet without using RSA --- they just won't be able to verify the veracity of the nameserver records just like today. As for people who run name servers for their domains, they can either let their regional network run it, or they can grab your freely available source code and a copy of RSAREF, and compile their own. Actually, I expect that in a few years, hopefully the vendors will also be supplying a Secure DNS. Keep in mind that the IP Security working group is currently talking about using Diffie-Helman to secure IP connections --- and the patent for Diffie-Helman is also controlled by RSADSI. Like it or not, most of the good schemes for doing wide-area cryptography (RSA, Diffie-Helman, etc.) are controlled by RSADSI. At some level, though, while these issues are important, I don't think this is the best place to be addressing them, since they apply to more than one working group. Perhaps we should just concentrate on getting the technical issues right, and let the IESG debate the patent issues? I am quite certain that if we let ourselves get tied up in the patent nonsense, we won't make any progress. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa01796; 8 Apr 94 11:39 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29204; Fri, 8 Apr 94 11:39:02 EDT Received: by relay.tis.com; id AA25776; Fri, 8 Apr 94 11:39:42 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma025771; Fri Apr 8 11:38:47 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12607; Fri, 8 Apr 94 08:00:27 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA14418; Fri, 8 Apr 1994 11:01:59 -0400 Message-Id: <9404081501.AA14418@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: RR Type assignments Date: Fri, 08 Apr 94 11:01:58 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp IANA has assignged type number 24 for the proposed SIG (signature) RR and type number 25 for the proposed RSA (key) RR. I'm edited these into the draft. 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)   Received: from sol.tis.com by magellan.TIS.COM id aa02251; 8 Apr 94 13:02 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02538; Fri, 8 Apr 94 13:02:25 EDT Received: by relay.tis.com; id AA26488; Fri, 8 Apr 94 13:03:12 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma026484; Fri Apr 8 13:02:26 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20908; Fri, 8 Apr 94 09:58:27 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA16062; Fri, 8 Apr 1994 12:59:53 -0400 Message-Id: <9404081659.AA16062@skidrow.lkg.dec.com> To: Stephen D Crocker Cc: Hilarie Orman , namedroppers@nic.ddn.mil, dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication In-Reply-To: Your message of "Wed, 06 Apr 94 08:45:09 EDT." <9404061245.AA12855@tis.com> Date: Fri, 08 Apr 94 12:59:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp My interpretation of the current RSAREF license is that "non-commercial" use would include offering a service where RSA was needed for an essential part of the service. I don't think there would be any problem where RSA was part of something incidental such as normal DNS use. On the "free implementation" aspect, the general RSAREF license restricts you to using the defined interfaces although you can change the inards as much as you want, presumably even to completely replacing them. Also, as far as I am aware, no one who has ever asked to get a variance to use different interfaces for some stated purpose has ever been turned down. As a reality check, I think people should note that (1) RSA is still only patented in the United States of America and (2) most UNIX vendors have already licensed RSA. So if RSA is used in secure DNS, as far as I can till it will not affect people outside the US, people who want to use it non-commercially in the US will have no problem, and, at worst, people who want to use it commerically inside the US will simply have to buy their initial DNS software with an RSA sub-license from HP or SUN or DEC or any of the other zillions of companies that already have a general RSA license. It would be nice if once could wave a magic wand and avoid all the political/export/patent problems of cryptographic security but I don't see how to do that. Donald (not a lawyer) From: Stephen D Crocker To: Hilarie Orman Cc: crocker@tis.com Cc: namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: Your message of "Tue, 05 Apr 94 22:00:58 PDT." <199404060500.WAA04399@baskerville.cs.arizona.edu> >Hilarie, > >I focused on 5.4.2(a)2 because it pertained to implementation. So far >as I can tell, the full assurances required under 5.4.2(A)1, 5.4.2(A)2 >and 5.4.2(A)3 were obtained previously, as documented in RFC 1170. As >I said before, it's entirely reasonable to revisit and redocument the >details, but my strong belief is that this is not a showstopper and >should not affect our design choices. > >With respect to your second question, are you asking the generic >question about patent law, i.e. (a) "are implementors free to implement > for non-commercial use?", or are you asking (b) whether >RSA has provided general permission for free implementation of their >technology for non-commercial use? As neither a lawyer nor an RSA >representative, I can give only my general understanding, which is (a) >I believe patents cover all use, commercial or not, and (b) I don't >think RSA has given blanket permission for non-commercial >implementations other than through RSAREF, but I strongly recommend >you take this up with them. > >Steve > >> From: Hilarie Orman >> To: crocker@tis.com >> cc: namedroppers@nic.ddn.mil, dns-security@tis.com >> Date: Tue, 5 Apr 1994 22:00:58 -0700 >> Subject: Re: Possible use of public key technology in DNS authentication >> >> Is this to say that the assurances required under 5.4.2(A)1 and 3 have >> not been provided? If this is correct, will someone be talking to RSA >> about getting the assurances? >> >> Another question: are implementors free to implement RSA patented >> algorithms for non-commercial use? Or are they only free to use >> RSAREF?   Received: from sol.tis.com by magellan.TIS.COM id aa02375; 8 Apr 94 13:21 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03270; Fri, 8 Apr 94 13:21:32 EDT Received: by relay.tis.com; id AA26623; Fri, 8 Apr 94 13:22:19 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma026618; Fri Apr 8 13:21:48 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA22314; Fri, 8 Apr 94 10:18:36 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA16274; Fri, 8 Apr 1994 13:20:07 -0400 Message-Id: <9404081720.AA16274@skidrow.lkg.dec.com> To: Greg Minshall Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Thu, 07 Apr 94 14:24:53 PDT." <9404072124.AA25281@WC.Novell.COM> Date: Fri, 08 Apr 94 13:20:07 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Greg, From: Greg Minshall To: dns-security@tis.com >Some thoughts on the DNS security draft: >4. Could at least the SA (security available) bit be carried in some other >form rather than one of the reserved bits in the header? Inferred, say, >from the presence of an unsolicited SIG? Or, some other unsolicited record >in the reply? Yes, this could be carried in another way. A normal unsolicited SIG or RSA just added as additional information might not fit or might cause trunction. However, we could make up a very short (one byte of RDATA) RR (probably an RSA with a special bit set in its RDATA flag byte) that could be returned as additional information to substitute for the SA header bit and something similar that could be provided as additional data as part of the query to substitute for the SD header bit. Since current BIND tends to ignore queries with a non-zero additional information count, you would have to be careful not send this "SD" indication RR unless you have had gotten the "SA" indication. I think there are some loose ends here like not getting faked out if you see the "SA" flag just because you did an ANY retreival from some caching server, etc., but it could probably be made to work. >5.1. Can a *request* be authenticated? Well, one of the principles of DNS is supposed to be that it gives everyone the same answer. So we deliberately left out an explicit request authentication mechanism. However, you could certainly tack a SIG with just a hashed query message signet in the additional information section of a query. The server then could, if it wanted to, use this to authenticate the query. The proposal could be changed to require servers to at least ignore such a SIG. Currently it does not even mention their possibility. You have to be careful, however, as many current implementations will ignore queries where the additional info count is non-zero. So you could only do this when you know the server is security aware. Do people think request authentication should be required/optional? >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla >encoding (with a hashed signet)? Such a resolver would not be conformant to the current proposal. And, to be able to answer a query two ways, the server would probably have to pre-calculate two different sets of SIGs and be careful to only send the right one. (Note, although you don't mention the possibility, you could also provide the vanilla A RR and a direct signet inside the SIG.) Since there is concern over the complexity of the current proposal, adding yet more options to queries seems like a bad idea. Either only hashed signets should be used, as Masataka Ohta suggests and you are asking for as a query option, or the current proposal allowing both direct and hashed signets should be followed. Some statistical studies on real zones with reasonable projections of added RSA RRs, key modulus sizes, etc., seems to me like the only way to get data that can be used to answer this. >Greg Minshall Donald   Received: from sol.tis.com by magellan.TIS.COM id aa03421; 8 Apr 94 16:20 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12033; Fri, 8 Apr 94 16:20:30 EDT Received: by relay.tis.com; id AA28095; Fri, 8 Apr 94 16:21:18 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma028090; Fri Apr 8 16:20:38 1994 Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA05129; Fri, 8 Apr 1994 16:20:22 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA19120; Fri, 8 Apr 1994 16:20:21 -0400 Message-Id: <9404082020.AA19120@abyss.zk3.dec.com> To: Greg_Minshall@novell.com Cc: dns-security@tis.com Subject: Re: DNS security draft Date: Fri, 08 Apr 94 16:20:20 -0400 From: kaufman@zk3.dec.com X-Mts: smtp I agree with Don's responses, but would append a suspicious "why do you ask?". >4. Could at least the SA (security available) bit be carried in some other >form rather than one of the reserved bits in the header? Inferred, say, >from the presence of an unsolicited SIG? Or, some other unsolicited record >in the reply? Are you concerned about interoperability, trying to preserve a bit for some future use, or just trying to simplify the protocol? A resolver needs to know whether a server supports the protocol so that - if not - it can explicitly request SIG records. There are clever ways it could figure that out without a bit in the formats, but it wouldn't simplify the protocol in practice. >5.1. Can a *request* be authenticated? I suppose, but why would you want to? What would DNS do with this information? Did you have access control in mind? An earlier draft proposal included this functionality, but we took it out because it seemed what users really wanted was to know that a given response was the response to its actual query (and not some modified version). That protection is included. >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla >encoding (with a hashed signet)? When might this happen? Do you have in mind a partially implemented resolver that understands hashed signets but not direct encodings? I can't think of why anyone would implement such a thing. You certainly have to be able to request a vanilla encoding and no signature for backwards compatibility with non-security aware resolvers. I guess I can imagine a case where a security aware resolver lacks the particular public key needed to decrypt some SIG. Is this the case you're worried about? --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa05296; 9 Apr 94 14:46 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03611; Sat, 9 Apr 94 14:45:58 EDT Received: by relay.tis.com; id AA03823; Sat, 9 Apr 94 14:46:47 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma003819; Sat Apr 9 14:46:00 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25331; Sat, 9 Apr 94 11:43:36 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA28629; Sat, 9 Apr 1994 14:45:09 -0400 Message-Id: <9404091845.AA28629@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Security AD's assesment re RSAREF licensing Date: Sat, 09 Apr 94 14:45:09 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Forwarded with permission. ------- Forwarded Message Donald From: Jeffrey I. Schiller To: dee > My reading of the current RSAREF license, which I assume are their > general terms, is that you would have to pay if you had something > using RSA as an essential part of providing a service (ie, some secure > network service dependent on dns security even if you were using > freeware BIND) as well as if you incorporated RSA into a product you > sold (ie, a vendor version of BIND). Do you think RSA would be > willing to be more liberal than this? > >Obviously I cannot speak for RSADSI, but I can venture my vision of what >I believe they will and will not be willing to do (so to speak!). They >will certainly want any vendor selling a commercial version of BIND >(either stand alone or as part of an operating system product) to pay a >royalty. However many of the existing computer vendors (DEC, Sun, etc.) >are already licensees so this isn't a problem. Note: Customers of these >companies will probably be able to use the enhanced BIND that comes with >their operating system for any purpose that they want, commercial or >otherwise. In essence the vendor incorporates the license in the >version of bind shipped with the system. For example Lotus Notes uses >the RSA system internally (users in fact have a key pair) and commercial >organizations may purchase Notes and use it for whatever they want. The >fact that the RSA system is patented is already taken care of in the >license that Lotus has with RSADSI. > >A "freeware" version of bind may be developed and distributed on the >Internet via anonymous FTP according to the terms of the RSAREF >license. Anyone can copy and make use of such a freeware version, >including commercial entities as long as they do not directly use the >secure DNS as a fundamental portion of a service that they offer for >pay. > >Example: > >o If I am a commercial organization and I use secure DNS in order to > authenticate hosts on the network I am probably just fine. > >o On the otherhand if I am a commercial organization and I sell > information over the network, but only to hosts that I can authenticate > with the secure DNS, then I probably have to pay a royalty *to use the > freeware version*. If I base my system on a commercial product that is > "fully" licensed, I shouldn't need to worry. > >Jim Bidzos told me that he is actively working on figuring out how to >offer "hassle free" commercial licenses where people can make commercial >use of things like RSAREF and pay RSADSI a (small) royalty without >having to negotiate a complex license. Jim appears to have realized that >the network may present him with a customer base larger then his current >organization is capable of physically dealing with unless they come up >with some for of electronic "auto licensing" etc. > >Btw. It probably makes sense to implement secure DNS in such a fashion >that the RSA operations are abstracted into a separate module which >contains the appropriate #ifdef's to handle either RSAREF (for the >freeware version) or BSAFE (for the commercial companies that probably >already have a BSAFE license arrangement). > > -Jeff ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa09221; 11 Apr 94 10:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14823; Mon, 11 Apr 94 10:32:18 EDT Received: by relay.tis.com; id AA13515; Mon, 11 Apr 94 10:33:09 EDT Message-Id: <9404111433.AA13515@relay.tis.com> Received: from ninet.research.att.com(192.20.225.3) by relay via smap (V1.3mjr) id sma013507; Mon Apr 11 10:32:59 1994 From: smb@research.att.com Received: by gryphon; Mon Apr 11 10:27:43 EDT 1994 To: Masataka Ohta Cc: "Donald E. Eastlake 3rd" , crocker@tis.com, ho@cs.arizona.edu, namedroppers@nic.ddn.mil, dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication Date: Mon, 11 Apr 94 10:27:42 EDT > As a reality check, I think people should note that (1) RSA is still > only patented in the United States of America and I know patent system in US is broken. Anyway... Does someone know when the patent will expire? September 19, 2000. > My interpretation of the current RSAREF license As copyright lasts much longer than patent, it's better not to depend on licenced code. After the patent expires, we should be absolutely free. > On the "free implementation" aspect, the general RSAREF license > restricts you to using the defined interfaces although you can chang e > the inards as much as you want, presumably even to completely > replacing them. Is RSA Inc. trying to protect the interface specification with copyright? If so, I don't think it appropriate to use it as Internet Standard. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08649; 11 Apr 94 6:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04460; Mon, 11 Apr 94 04:56:18 EDT Received: by relay.tis.com; id AA11621; Mon, 11 Apr 94 04:57:09 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma011616; Mon Apr 11 04:56:44 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 17:48:08 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404110848.AA21154@necom830.cc.titech.ac.jp> Subject: Re: Possible use of public key technology in DNS authentication To: "Donald E. Eastlake 3rd" Date: Mon, 11 Apr 94 17:48:07 JST Cc: crocker@tis.com, ho@cs.arizona.edu, namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: <9404081659.AA16062@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 8, 94 12:59 pm X-Mailer: ELM [version 2.3 PL11] > As a reality check, I think people should note that (1) RSA is still > only patented in the United States of America and I know patent system in US is broken. Anyway... Does someone know when the patent will expire? > My interpretation of the current RSAREF license As copyright lasts much longer than patent, it's better not to depend on licenced code. After the patent expires, we should be absolutely free. > On the "free implementation" aspect, the general RSAREF license > restricts you to using the defined interfaces although you can change > the inards as much as you want, presumably even to completely > replacing them. Is RSA Inc. trying to protect the interface specification with copyright? If so, I don't think it appropriate to use it as Internet Standard. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa13091; 11 Apr 94 12:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21568; Mon, 11 Apr 94 12:54:05 EDT Received: by relay.tis.com; id AA15008; Mon, 11 Apr 94 12:54:55 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma015000; Mon Apr 11 12:54:40 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11574; Mon, 11 Apr 94 09:48:59 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA15440; Mon, 11 Apr 1994 12:50:27 -0400 Message-Id: <9404111650.AA15440@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Mon, 11 Apr 94 20:27:59 +0200." <9404111128.AA22598@necom830.cc.titech.ac.jp> Date: Mon, 11 Apr 94 12:50:27 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta In-Reply-To: <9404082020.AA19120@abyss.zk3.dec.com>; from "kaufman@zk3.dec.com" at Apr 8, 94 4:20 pm >> I agree with Don's responses, but would append a suspicious "why do you ask?". >> >> >4. Could at least the SA (security available) bit be carried in some other >> >form rather than one of the reserved bits in the header? Inferred, say, >> >from the presence of an unsolicited SIG? Or, some other unsolicited record >> >in the reply? >> >> Are you concerned about interoperability, trying to preserve a bit >> for some future use, or just trying to simplify the protocol? A resolver >> needs to know whether a server supports the protocol so that - if not - it >> can explicitly request SIG records. There are clever ways it could figure >> that out without a bit in the formats, but it wouldn't simplify the >> protocol in practice. > >While SD is useful to affect additional section processing, SA is >useless. If you believe that the SA (Security Available) bit is useless, do you also believe that the recursion available bit in the DNS message header is useless? >A resolver must be able to securely know whether SIG RRs are available >or not for which purpose SA is nothing. In a secure environment, your resolver will hopefully start from a known secure zone. The way it tells whether other zones are secure is by travering the DNS tree and looking at the RSA RRs. If they show a zone as having no key, then it would assume there are no SIGs. If they show a zone as having a key with the mandatory bit off, it might have SIGs or it might not. If they show a zone with a key with the mandatory bit on, then it has to have SIGs. The SA bit, which tells about the characteristics of a particular server, has nothing to do with this. Different servers for the same zone might some be security aware with the SA bit on in their responses and some be security non-aware with the SA bit off. >> >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES >> >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla >> >encoding (with a hashed signet)? >> >> When might this happen? > >It can't happen, which is why I think the current proposal is too much >complex. > > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa13140; 11 Apr 94 13:04 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21984; Mon, 11 Apr 94 13:04:07 EDT Received: by relay.tis.com; id AA15084; Mon, 11 Apr 94 13:04:58 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma015076; Mon Apr 11 13:04:51 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11981; Mon, 11 Apr 94 09:55:02 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA15535; Mon, 11 Apr 1994 12:56:34 -0400 Message-Id: <9404111656.AA15535@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication In-Reply-To: Your message of "Mon, 11 Apr 94 17:48:07 +0200." <9404110848.AA21154@necom830.cc.titech.ac.jp> Date: Mon, 11 Apr 94 12:56:34 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: dee (Donald E. Eastlake 3rd) Cc: crocker@tis.com, ho@cs.arizona.edu, namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: <9404081659.AA16062@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 8, 94 12:5 9 pm X-Mailer: ELM [version 2.3 PL11] >> My interpretation of the current RSAREF license > >As copyright lasts much longer than patent, it's better not to depend >on licenced code. Although there are some references to copyright, I believe the RSAREF license is primarily a patent right license. >After the patent expires, we should be absolutely free. > >> On the "free implementation" aspect, the general RSAREF license >> restricts you to using the defined interfaces although you can change >> the inards as much as you want, presumably even to completely >> replacing them. > >Is RSA Inc. trying to protect the interface specification with >copyright? If so, I don't think it appropriate to use it as >Internet Standard. No, I think they are just using granting permission under their patent(s) limited in this case by the RSAREF interface spec. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa09014; 11 Apr 94 9:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06574; Mon, 11 Apr 94 07:13:40 EDT Received: by relay.tis.com; id AA12289; Mon, 11 Apr 94 07:14:31 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma012285; Mon Apr 11 07:13:44 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 20:07:47 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404111108.AA22390@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: "Donald E. Eastlake 3rd" Date: Mon, 11 Apr 94 20:07:46 JST Cc: dns-security@tis.com In-Reply-To: <9404091845.AA28629@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 9, 94 2:45 pm X-Mailer: ELM [version 2.3 PL11] > Forwarded with permission. > From: Jeffrey I. Schiller > >A "freeware" version of bind may be developed and distributed on the > >Internet via anonymous FTP according to the terms of the RSAREF > >license. Why the "freeware" version is restricted by the license? As far as I know, non-commercial use of patent is free from licensing. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08802; 11 Apr 94 7:36 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07093; Mon, 11 Apr 94 07:35:44 EDT Received: by relay.tis.com; id AA12393; Mon, 11 Apr 94 07:36:35 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma012389; Mon Apr 11 07:36:14 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 20:28:01 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404111128.AA22598@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: kaufman@zk3.dec.com Date: Mon, 11 Apr 94 20:27:59 JST Cc: Greg_Minshall@novell.com, dns-security@tis.com In-Reply-To: <9404082020.AA19120@abyss.zk3.dec.com>; from "kaufman@zk3.dec.com" at Apr 8, 94 4:20 pm X-Mailer: ELM [version 2.3 PL11] > I agree with Don's responses, but would append a suspicious "why do you ask?". > > >4. Could at least the SA (security available) bit be carried in some other > >form rather than one of the reserved bits in the header? Inferred, say, > >from the presence of an unsolicited SIG? Or, some other unsolicited record > >in the reply? > > Are you concerned about interoperability, trying to preserve a bit > for some future use, or just trying to simplify the protocol? A resolver > needs to know whether a server supports the protocol so that - if not - it > can explicitly request SIG records. There are clever ways it could figure > that out without a bit in the formats, but it wouldn't simplify the > protocol in practice. While SD is useful to affect additional section processing, SA is useless. A resolver must be able to securely know whether SIG RRs are available or not for which purpose SA is nothing. > >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES > >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla > >encoding (with a hashed signet)? > > When might this happen? It can't happen, which is why I think the current proposal is too much complex. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa18246; 11 Apr 94 18:43 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06690; Mon, 11 Apr 94 18:43:39 EDT Received: by relay.tis.com; id AA17550; Mon, 11 Apr 94 18:44:31 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma017546; Mon Apr 11 18:44:26 1994 Received: by gw.home.vix.com id AA25306; Mon, 11 Apr 94 15:44:06 -0700 Date: Mon, 11 Apr 94 15:44:06 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: Security AD's assesment re RSAREF licensing Organization: Vixie Enterprises Message-Id: References: <9404111108.AA22390@necom830.cc.titech.ac.jp> Nntp-Posting-Host: office.home.vix.com In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 11 Apr 1994 07:00:58 -0700 >>>A "freeware" version of bind may be developed and distributed on the >>>Internet via anonymous FTP according to the terms of the RSAREF >>>license. >Why the "freeware" version is restricted by the license? > >As far as I know, non-commercial use of patent is free from licensing. If a BIND distribution includes only hooks for RSAREF without including RSAREF itself, then no change needs to be made to the BIND license. If, however, BIND includes portions of RSAREF, then those portions will still be covered by the RSA license. Noncommercial users won't be affected by the RSA license, since the terms of the RSA license that affect non- commercial users are substantially equal to the existing terms of the BSD and DEC copyrights that BIND is already subject to. However, none of BIND's current module copyrights restricts commercial use or redistribution (other than that the copyrights themselves must not be removed or altered, and other reasonable, "free" things). I am still pondering at least two issues: should the IETF or IAB specify a packet encoding which commercial users _cannot_use_ without paying a license fee or patent royalty to RSA? And: if that happens in spite of my protests, should BIND even include RSAREF, or just hooks and patches for it so that someone who wants it can pull it from RSA's ftp server and easily integrate it? Various politicking is still going on privately, but as far as I know, the author of the current RSA-based IP/DNS Security proposal has summarily written off my concerns. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa25028; 12 Apr 94 19:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11918; Tue, 12 Apr 94 19:24:22 EDT Received: by relay.tis.com; id AA28489; Tue, 12 Apr 94 19:25:15 EDT Received: from dell1.us.dell.com(143.166.224.203) by relay via smap (V1.3mjr) id sma028481; Tue Apr 12 19:24:57 1994 Received: from upurbmw.us.dell.com by dell1.us.dell.com (4.1/DELL-GATEWAY-SENDMAIL-5.67) id AA06963; Tue, 12 Apr 94 18:24:24 CDT Received: by upurbmw.us.dell.com (931110.SGI/930416.SGI) for @dell1.us.dell.com:dns-security@tis.com id AA01446; Mon, 11 Apr 94 18:26:35 -0500 From: "Steven C. Blair" Message-Id: <9404111826.ZM1444@upurbmw.us.dell.com> Date: Mon, 11 Apr 1994 18:26:35 -0500 In-Reply-To: James M Galvin "Re: SIG RR location in responses" (Apr 5, 10:29am) References: <9404051030.aa03631@magellan.TIS.COM> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: James M Galvin , Paul A Vixie Subject: Re: SIG RR location in responses..several comments. Cc: dns-security@tis.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Pardon me for melting three messages into one, but after reading a week of this subject, I feel that three good points, and apologize for my tardiness in replying. vixie: ------ Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. I for one am still thinking about what the overseas folks will do Paul. May I remind all about Austin Code Works and the current legal issue just surrounding PgP? Vendors are having a hard enough time keeping up with things as fast as they change. Not all companies have mechinisms in place that can support the audit trails well enough to be defeneded in court when RSA, etc. al., decides that they may not be getting their fair share of $$'s from the licensing issues. There are no clear winners, the vendor, the customers, loose, and the lawyers win. That is not the direction I'd like to see BIND/dnssec go. galvin: -------- Two bits of information to keep in mind. First, RSADSI has made RSAREF available for non-commercial use. However, I realize this does not solve the "vendors packaging a product." For that, may I direct your attention to the latest issue of Connexions, March 1984, in which commandment number 1 of "The Ten Commandments of Domain Name Service" is, "Thou shalt not run thy vendor's DNS software." That statement is personally disappointing James. It is a far cry from reality then if you consider that almost 50%(IMHO) of customers DO RUN the vendor shipped code. At least until it bites them in the arse. We have to keep in mind with anything that we consider publishing that customers may/may not have the smarts to run it, and not everyone has time to port every single "steenking piece of code" to get the latest-and-greatest widget. I feel that Art Harkin was right on the point: -------------------------------------------------- Where I feel the danger lies is how this 'problem' has been intepreted into a rule that vendor software is to be discarded. This might be a simplistic view, there are many network admins unwilling to delve into the issues of running unsupported software. Not recognizing this can cause problems later. I feel a better approach is to encourage rapid deployment of new features in both commercial and non-commercial arenas. Crocker: --------- As neither a lawyer nor an RSA representative, I can give only my general understanding, which is (a) I believe patents cover all use, commercial or not, and (b) I don't think RSA has given blanket permission for non-commercial implementations other than through RSAREF, but I strongly recommend you take this up with them. > I think we all better have a talk with RSA before this continues < > much further. Admins who can barely runa site now will be totally < > screwed if they can't understand what we implement. If the RSA < > folks are on this list, now is the time to speak up folks. < -- Steven C. Blair dell computer corp "Professionals are predictable, it's the amateurs that are dangerous"   Received: from sol.tis.com by magellan.TIS.COM id aa19061; 12 Apr 94 2:20 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17038; Tue, 12 Apr 94 02:20:12 EDT Received: by relay.tis.com; id AA19855; Tue, 12 Apr 94 02:21:03 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma019849; Tue Apr 12 02:20:09 1994 Received: by gw.home.vix.com id AA03819; Mon, 11 Apr 94 23:19:22 -0700 Message-Id: <9404120619.AA03819@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 12 Apr 1994 12:54:21 +0200." <9404120354.AA26666@necom830.cc.titech.ac.jp> Date: Mon, 11 Apr 1994 23:19:21 -0700 From: Paul A Vixie > Does someone know what happens if my RSA-BIND interact with RSA-BIND in US? that depends on how complete the eventual RFC is. if it specifies the algorythm, than if the RSA you use in japan is different from the one released publically by RSA here in the US, i suspect that japan's will lose out. > I think you should protest against bread-dead patent policy of your country. "never try to teach a pig to sing. it wastes your time, and it annoys the pig." -- lazarus long > > If a BIND distribution includes only hooks for RSAREF without including > > RSAREF itself, then no change needs to be made to the BIND license. > > I don't think so. As far as the patent protection, which is a protection > over idea, concerns, BIND is binded till the year 2000. > > That is, if your program use the "idea" of the patent, the idea on public > and private keys, it can't be used commercially without proper licensing. i've pretty much convinced myself that if the RSA specification goes through, BIND will have to support it somehow. however, i will never include any code in the release which has a restricted distribution other than the usual limits of the BSD copyrights (which require mainly that the copyright and attributions not be altered or removed). this means that a BIND kit that "works with" RSA- licensed software will require a BIND user to acquire their own copy of RSA's software and "link it into" BIND. > > However, none of > > BIND's current module copyrights restricts commercial use or redistribution > > (other than that the copyrights themselves must not be removed or altered, > > and other reasonable, "free" things). > > The copyright issue can be easily avoidable, unless the copyright > holder claims that "interface specification" is copyrightable. if RSA attempts to require something like the following code segment, written by me, to be covered by their license, then BIND will simply never (officially) use RSAREF, and there will be other versions of BIND that do include RSAREF but lag substantially in the area of other features: #ifdef USE_RSAREF if (rsaref_getkey(from_addr.sin_addr, buf) == -1) { syslog(LOG_ERROR, "getkey(%s): %m", inet_addr(from_addr.sin_addr)); return (NULL); } #endif /*USE_RSAREF*/ (that's assuming a lot about RSAREF -- i've never seen it and i am only wildly guessing that it might include a function called "rsaref_getkey()" with that implied function signature. but i think you get the idea and now know what i mean by "hooks to use RSAREF".) even if PKP's legal status gives RSA the right to restrict instantiations of the above "interface", i do not think that RSA or any company which valued its public image in even the smallest way would ever try to "protect" those rights. i could be wrong; i'm certainly not a lawyer. it's also devilishly possible that in order to prove due diligence for other patents and other cases, RSA would be _forced_ to bring suit against anyone who published code like the above. it's a funny world sometimes.   Received: from sol.tis.com by magellan.TIS.COM id aa18770; 11 Apr 94 23:39 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14364; Mon, 11 Apr 94 23:39:35 EDT Received: by relay.tis.com; id AA19103; Mon, 11 Apr 94 23:40:27 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma019099; Mon Apr 11 23:39:32 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Apr 94 12:33:38 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404120333.AA26523@necom830.cc.titech.ac.jp> Subject: Re: Possible use of public key technology in DNS authentication To: "Donald E. Eastlake 3rd" Date: Tue, 12 Apr 94 12:33:37 JST Cc: dns-security@tis.com In-Reply-To: <9404111656.AA15535@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 11, 94 12:56 pm X-Mailer: ELM [version 2.3 PL11] > >> My interpretation of the current RSAREF license > > > >As copyright lasts much longer than patent, it's better not to depend > >on licenced code. > > Although there are some references to copyright, I believe the RSAREF > license is primarily a patent right license. RSAREF in US is protectable both by copyright and patent. They both work for proection. Saying patent protection is "primary" is not meaningful. Copyright protection is, in some sense, stronger because it lasts much longer than patent. So, unless copyright is actively abandoned, we shouldn't use RSAREF. Instead we should replicate it by something with the equal functionality and interface, before formal release. We may do it by ourselves or expect FSF do the job if we think GPL is not so restrictive (I'm somewhat negative to FSF). Then, after the year 2000, all the commercial use of secure BIND will be absolutely free. > >Is RSA Inc. trying to protect the interface specification with > >copyright? If so, I don't think it appropriate to use it as > >Internet Standard. > > No, I think they are just using granting permission under their > patent(s) limited in this case by the RSAREF interface spec. That's fine. But we should make it sure. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa18850; 12 Apr 94 0:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14670; Mon, 11 Apr 94 23:59:40 EDT Received: by relay.tis.com; id AA19236; Tue, 12 Apr 94 00:00:32 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma019229; Tue Apr 12 00:00:13 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Apr 94 12:54:23 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404120354.AA26666@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Paul A Vixie Date: Tue, 12 Apr 94 12:54:21 JST Cc: dns-security@tis.com In-Reply-To: ; from "Paul A Vixie" at Apr 11, 94 3:44 pm X-Mailer: ELM [version 2.3 PL11] > I am still pondering at least two issues: should the IETF or IAB specify a > packet encoding which commercial users _cannot_use_ without paying a license > fee or patent royalty to RSA? Your problem is US domestic. I can use secure RSA-BIND commercially without paying royalities in Japan. Does someone know what happens if my RSA-BIND interact with RSA-BIND in US? > And: if that happens in spite of my protests, I think you should protest against bread-dead patent policy of your country. > >Why the "freeware" version is restricted by the license? > > > >As far as I know, non-commercial use of patent is free from licensing. > > If a BIND distribution includes only hooks for RSAREF without including > RSAREF itself, then no change needs to be made to the BIND license. I don't think so. As far as the patent protection, which is a protection over idea, concerns, BIND is binded till the year 2000. That is, if your program use the "idea" of the patent, the idea on public and private keys, it can't be used commercially without proper licensing. > However, none of > BIND's current module copyrights restricts commercial use or redistribution > (other than that the copyrights themselves must not be removed or altered, > and other reasonable, "free" things). The copyright issue can be easily avoidable, unless the copyright holder claims that "interface specification" is copyrightable. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24258; 12 Apr 94 15:33 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26266; Tue, 12 Apr 94 15:33:20 EDT Received: by relay.tis.com; id AA26252; Tue, 12 Apr 94 15:34:13 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma026247; Tue Apr 12 15:33:53 1994 Received: from [16.140.64.3] by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA17431; Tue, 12 Apr 1994 10:49:30 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA08661; Tue, 12 Apr 1994 10:41:51 -0400 Message-Id: <9404121441.AA08661@abyss.zk3.dec.com> To: paul@vix.com Cc: dns-security@tis.com, kaufman@zk3.dec.com Subject: Re: Security AD's assesment re RSAREF licensing Date: Tue, 12 Apr 94 10:41:44 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >I am still pondering at least two issues: should the IETF or IAB specify a >packet encoding which commercial users _cannot_use_ without paying a license >fee or patent royalty to RSA? And: if that happens in spite of my protests, >should BIND even include RSAREF, or just hooks and patches for it so that >someone who wants it can pull it from RSA's ftp server and easily integrate >it? > >Various politicking is still going on privately, but as far as I know, the >author of the current RSA-based IP/DNS Security proposal has summarily written >off my concerns. I wouldn't say written off so much as resigned. Basically, the sort of security we would like to see in DNS requires public key cryptography and there is no way to use any form of public key cryptography in the U.S. without dealing with RSADSI or PK Partners on whatever terms they dictate. The IETF and the IAB could be hardnosed and say "if it's not free, we won't standardize it". Such a stance might cause some people to abandon their patents, but it's not likely to work with RSADSI. More likely it would simply delay standardization of security. They have already decided to permit standardization of PEM; I don't see why DNS should be any different. It is certainly the case that deployment of both PEM and secure DNS will be delayed by licensing requirements and neither is likely to become ubiquitous (at least until September 19, 2000). RSADSI has made RSAREF available on what some would call generous terms and what some would label a shameless ploy to maximize their profits by getting the IETF and other "freeware" communities to standardize something that they can then force commercial enterprises to pay for. Both descriptions are accurate. There are some terms we should be careful about when it comes to deployment. We should make sure that RSADSI does not claim copyright on the interfaces to RSAREF, so that modules incorporating conditionally compiled calls remain freely distributable. I'm fairly certain they have done so, since any other claim would undermine their distribution strategy. [btw... in response to the first question, BIND should only incorporate calls to RSAREF and not RSAREF itself for many reasons including redistribution policy and export control rules. There is reason for concern about export control rules for even having the calls in place, but I suspect "don't ask; don't tell" is the right policy here]. But these are issues around implementation and deployment and not around the architecture. The only architectural issue is whether we should be trying to secure DNS with public key cryptography at all and if so whether we should limit the design to something that can be implemented with the existing RSAREF interfaces. The current design does not because it does some tricky manipulations for better performance. We expect RSADSI will grant a waiver for use of internal interfaces of RSAREF; if they don't, the design should be rethought. I have not personally participated in any discussions, but I've heard there have been some and initial indications are positive. --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa23939; 12 Apr 94 14:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22355; Tue, 12 Apr 94 14:53:50 EDT Received: by relay.tis.com; id AA25685; Tue, 12 Apr 94 14:54:40 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma025677; Tue Apr 12 14:54:16 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16500; Tue, 12 Apr 94 11:40:09 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA05194; Tue, 12 Apr 1994 14:41:40 -0400 Message-Id: <9404121841.AA05194@skidrow.lkg.dec.com> To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Mon, 11 Apr 94 15:44:06 PDT." Date: Tue, 12 Apr 94 14:41:40 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul, From: Paul A Vixie X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Organization: Vixie Enterprises References: <9404111108.AA22390@necom830.cc.titech.ac.jp> In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 11 Apr 1994 07:00:58 -0700 >>>>A "freeware" version of bind may be developed and distributed on the >>>>Internet via anonymous FTP according to the terms of the RSAREF >>>>license. >>Why the "freeware" version is restricted by the license? >> >>As far as I know, non-commercial use of patent is free from licensing. >If a BIND distribution includes only hooks for RSAREF without including >RSAREF itself, then no change needs to be made to the BIND license. If, >however, BIND includes portions of RSAREF, then those portions will still >be covered by the RSA license. Noncommercial users won't be affected by >the RSA license, since the terms of the RSA license that affect non- >commercial users are substantially equal to the existing terms of the >BSD and DEC copyrights that BIND is already subject to. However, none of >BIND's current module copyrights restricts commercial use or redistribution >(other than that the copyrights themselves must not be removed or altered, >and other reasonable, "free" things). I would think that no matter what scheme is used, all the cryptographic stuff would want to be in a separate module with its own notices. There are other implementations of RSA besides RSAREF. In fact, RSA sells BSAFE, a commercial version. >I am still pondering at least two issues: should the IETF or IAB specify a >packet encoding which commercial users _cannot_use_ without paying a license >fee or patent royalty to RSA? Of course the IETF should try to avoid this. But how can that be the only factor? Surely there are also technical considerations, on which basis I believe that RSA is superior, and other standards considerations such as the fact that RSA has already been adopted in other IETF standards and in international standards, and probably other dimensions I have left out. Wouldn't it make a difference if the patent had 18 years or 18 months or 18 days left to run? Doesn't it make a difference that RSA is patented only in the US while some other public key systems are patented world wide? I would think that the job of the IETF/IESG is to try to take all these factors into account. > And: if that happens in spite of my protests, >should BIND even include RSAREF, or just hooks and patches for it so that >someone who wants it can pull it from RSA's ftp server and easily integrate >it? I would think the second alternative would be prefered. There will probably be higher quality or at least alternative implementations of RSA available, especially outside the US where none of this patent stuff applies. >Various politicking is still going on privately, but as far as I know, the >author of the current RSA-based IP/DNS Security proposal has summarily written >off my concerns. I can't speak for Charlie Kaufman, it's just that I'm not willing to go to a lot of extra work so as to avoid a window of a few years during which people in the United States only who fall into the following two categories would probably have to pay a reasonable license fee: they want to (1) sell secure DNS software and don't already have a license or they want to (2) sell a service for which secure DNS is an essential part and don't want to buy secure DNS software (which would come with a license, at least if its from a US vendor). (I realize that to many people no software patent license fee can be "reasonable"...) >-- >Paul Vixie >Redwood City, CA >decwrl!vixie!paul > Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24868; 12 Apr 94 18:23 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08966; Tue, 12 Apr 94 18:22:58 EDT Received: by relay.tis.com; id AA27979; Tue, 12 Apr 94 18:23:51 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma027971; Tue Apr 12 18:22:51 1994 Received: by gw.home.vix.com id AA23689; Tue, 12 Apr 94 15:22:30 -0700 Message-Id: <9404122222.AA23689@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 12 Apr 1994 14:41:40 EDT." <9404121841.AA05194@skidrow.lkg.dec.com> Date: Tue, 12 Apr 1994 15:22:30 -0700 From: Paul A Vixie I'd like to speak to the recurring statement in this forum that since RSA's technology has already been written into the PEM standard, why should we readdress those issues now in DNS? My answer comes in several parts. First and foremost, the PEM agreements were wrong-headed and politically motivated, in my view. DNS could PEM as a PKP/RSA precedent only if the decision to use RSA had been quite a bit less controversial during the PEM standardization process, or if the results of that standardization process had been an uncontestable win. Neither case obtains. PEM is so far a failure, after having been a divisive, bitter battle between people who had formerly been but will probably not again become partners in various common causes. Second, DNS is an ``essential service'' in Internet. Mail has been important and will no doubt continue to be important, but I personally know several people who use only NNTP and WWW and consider themselves ``Internet citizens.'' I do not know of any person or any service which can survive and prosper on the Internet without being able to translate symbolic names into addresses, and vice-versa. Third, while PEM will (if it succeeds, which is still possible) merely enable new uses for Mail, an RSA version of DNS will have far more sweeping effects. Even if PEM becomes common, people will still be able to do the same things with unauthenticated mail that they did before PEM came out; the risk will be that senders of mail cannot be authenticated, allowing all kinds of forgeries. People whose businesses depend on authenticity of Mail can pay for and use PEM; it would be wildly silly of them to do otherwise, given its existence as an Internet standard. However, once a secure version of DNS comes out, people who aren't able to use it will be subject to all kinds of forgeries involving actual sessions on their computers or refusal of their sessions on other people's computers -- I predict that when secure DNS comes out, ``everybody'' will use it, out of a concern for self- defense that drawfs any worries they may have had about unauthenticated Mail. Unless someone wants to debate this point in greater detail, I would like all participants in the larger "should we use RSA in DNS" debate to stop quoting PEM as either a success story or a precedent. PEM has not been a success, and did/does not have a comparable result-domain. Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa24947; 12 Apr 94 18:57 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09797; Tue, 12 Apr 94 18:57:10 EDT Received: by relay.tis.com; id AA28259; Tue, 12 Apr 94 18:58:04 EDT Message-Id: <9404122258.AA28259@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma028254; Tue Apr 12 18:57:16 1994 To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 12 Apr 94 15:22:30 -0700. <9404122222.AA23689@gw.home.vix.com> Date: Tue, 12 Apr 94 18:55:03 -0400 From: Steve Kent Paul, Perhaps to the surprize of many, I agree with the general thrust of your statement, i.e., that PEM may not be a good precedent for adopting RSA for the DNS, but for different reasons. When we initially developed PEM, we were quite concerned about the issue of using technology that was patented in the US. The first version of PEM contained only symmetric (DES) crypto key management in large part because of that concern. We convinced ourselves that public key signatures and key management were essential for deployment of large scale email security, and we worked with RSADSI to reach an agreement that we felt would make deployment of the technology viable in the US portion of the Internet. I think most of us involved in that decision have been very pleased with the extent to which RSADSI has made software available, e.g., RSAREF, to facilitate implementation of PEM. However, we selected RSA at a time when we felt there were no viable public key alternatives, irrespective of patent status. Since that time, there has been more work in the area and there are other algorithm choices. None is as attractive as RSA for providing both signature and encryption key managent. However, in a signature only context, there are other candidates and the DNS is a signature only application. To that extent, I agree with your observation that PEM is not a perfect precedent on which to base adoption of RSA for the DNS. For exmaple, ElGamal is an alternative signature algorithm which is not itself patented, but which is embraced by the fundamental Diffie-Hellman public key patent that expires in 1997 (I believe). ElGamal is not very efficient, but it is an alternative that has a shorter duration patent status relative to RSA. The DSA, a variant of ElGamal, is covered by a much more recent patent, making it less desirable, but NIST has been claiming that it will arrange to make the DSA royalty free for everyone (at least in the U.S.). The DSA is much more efficient than ElGamal, though it is not very space efficient compared to RSA. Moreover, DSA signatures are more expensive to verify than to generate (just backwards for the DNS use), and they are slower than comparable RSA signatures. However, on an absolute performance basis, DSA software is getting better and its lower performance might be irrelevant in the grand scheme of things. The concern I did raise in the DNS Security WG meeting is that the current proposal is tied unalterablty to RSA. The same is true of the current PEM spec, but it is being revised to accommodate separate algorithms for signature vs. encryption key management. To the extent that folks have argued for this separation of public key functions in PEM, and thus makeing PEM more algorithm independent, it seems a pity to adopt a scheme for DNS security that is very much algorithm dependent, even independent of patent issues. It is clear from the spec that Donald and George worked hard to deisgn a scheme that minimizes the extra space taken up by signatures. That probably motivated the use of RSA, the only one of the algorithms mentioned above that is "reversable" in terms of signature data. In principle, I'd feel more comfortable with an algorithm independent design, but I realse there is a concern about overflowing DNS UDP responses. I'd like to see lots of statictics about current DNS use so that we could say, with confidence, that the design constraints addressed here are the right ones and that this design will, in fact, be successful in this regard. Even without implementation experience, we could predict overflow situations with adequate data on current usage patterns. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa25256; 12 Apr 94 21:00 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13704; Tue, 12 Apr 94 21:00:00 EDT Received: by relay.tis.com; id AA29164; Tue, 12 Apr 94 21:00:53 EDT Received: from sacmgr.mp.usbr.gov(140.214.12.4) by relay via smap (V1.3mjr) id sma029153; Tue Apr 12 20:59:52 1994 Received: by sacto.mp.usbr.gov (MX V3.3 VAX) id 2174; Tue, 12 Apr 1994 17:59:12 PDT Date: Tue, 12 Apr 1994 17:59:00 PDT From: "Henry W. Miller" To: sblair@upurbmw.us.dell.com Cc: dns-security@magellan.TIS.COM, henrym@sacto.mp.usbr.gov Message-Id: <0097CDB6.15533168.2174@sacto.mp.usbr.gov> Subject: Re: SIG RR location in responses..several comments. > From: MX%"sblair@upurbmw.us.dell.com" 12-APR-1994 17:15:21.95 > Subj: Re: SIG RR location in responses..several comments. > Pardon me for melting three messages into one, but after reading a week of this > subject, I feel that three good points, and apologize for my tardiness in > replying. > > > vixie: > ------ > Am I the only person reading all this who is concerned about > using RSA, a patented and licensed technology, for DNS security? > I am very reluctant to put into BIND any technology which would > require vendors to pay a royalty to RSA before they could ship > it with their systems. > > > I for one am still thinking about what the overseas folks will do Paul. > > May I remind all about Austin Code Works and the current legal issue just > surrounding PgP? Vendors are having a hard enough time keeping up with things > as fast as they change. Not all companies have mechinisms in place that can > support the audit trails well enough to be defeneded in court when RSA, etc. > al., decides that they may not be getting their fair share of $$'s from the > licensing issues. There are no clear winners, the vendor, the customers, loose, > and the lawyers win. That is not the direction I'd like to see BIND/dnssec go. > > This is probably an 11th hour suggestion, but I wonder if it might be better to develop an en/decryption technique explictly for use for DNS, and perhaps other Internet services? One that would not suffer from copyright and export restrictions? > galvin: > -------- > > Two bits of information to keep in mind. First, RSADSI has made RSAREF > available for non-commercial use. However, I realize this does not > solve the "vendors packaging a product." For that, may I direct your > attention to the latest issue of Connexions, March 1984, in which > commandment number 1 of "The Ten Commandments of Domain Name Service" > is, "Thou shalt not run thy vendor's DNS software." > > That statement is personally disappointing James. It is a far cry from reality > then if you consider that almost 50%(IMHO) of customers DO RUN the vendor > shipped code. At least until it bites them in the arse. We have to keep in mind > with anything that we consider publishing that customers may/may not have the > smarts to run it, and not everyone has time to port every single "steenking > piece of code" to get the latest-and-greatest widget. > I submit that those who run the stock software (of some vendors) and are connected to the Internet are damned fools? Remember the Internet worm, and how it exploited a WELL KNOWN set of bugs? To their credit, Sun has been pretty good recently about supplying patched versions of some utilities; other vendors have not. If a site cannot provide a systems programmer of sufficient apptitude to keep up with the changes (and the dangers) then they should hire a network consultant who can perform the task in a short time. There is no shortage of such consultants. There's no sense in bitching about the horse escaping if you leave the barn door and gate open! > I feel that Art Harkin was right on the point: > -------------------------------------------------- > > Where I feel the danger lies is how this 'problem' has been intepreted into a > rule that vendor software is to be discarded. This might be a simplistic view, > there are many network admins unwilling to delve into the issues of running > unsupported software. Not recognizing this can cause problems later. I feel a > better approach is to encourage rapid deployment of new features in both > commercial and non-commercial arenas. > I agree with the latter, but until the former becomes true, responsible system managers have to protect their systems. > Crocker: > --------- > As neither a lawyer nor an RSA representative, I can give only my general > understanding, which is (a) I believe patents cover all use, commercial or not, > and (b) I don't think RSA has given blanket permission for non-commercial > implementations other than through RSAREF, but I strongly recommend > you take this up with them. > > > I think we all better have a talk with RSA before this continues < > > much further. Admins who can barely runa site now will be totally < > > screwed if they can't understand what we implement. If the RSA < > > folks are on this list, now is the time to speak up folks. < > > -- > Steven C. Blair > dell computer corp > "Professionals are predictable, it's the amateurs that are dangerous" > -HWM ---------- Henry W. Miller Assistant Systems and Network Manager U.S. Bureau of Reclamation, Mid Pacific Region 2800 Cottage Way MP1130 Sacramento, CA 95825 (916) 978-5108 Inet: "henrym@sacto.mp.usbr.gov" "I've fallen, and I can't get up!"   Received: from sol.tis.com by magellan.TIS.COM id aa27527; 13 Apr 94 9:04 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28914; Wed, 13 Apr 94 09:03:36 EDT Received: by relay.tis.com; id AA03510; Wed, 13 Apr 94 09:04:29 EDT Received: from unknown(129.185.1.1) by relay via smap (V1.3mjr) id sma003502; Wed Apr 13 09:03:41 1994 Received: from cooper.frmy.bull.fr by mybull.frmy.bull.fr; Wed, 13 Apr 1994 14:58:38 +0200 (MET) Received: by cooper.frmy.bull.fr; Wed, 13 Apr 94 13:00:41 GMT (MET) From: Denis PINKAS Message-Id: <9404131300.AA24744@cooper.frmy.bull.fr> Subject: Re: dnssec draft To: "Donald E. Eastlake 3rd" Date: Wed, 13 Apr 94 15:00:41 EET Cc: dns-security@tis.com In-Reply-To: <9404042121.AA29270@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 5:21 pm X-Mailer: ELM [version 2.3 PL2] > > > I'd be the first to admit that the current draft is not particularly > well written. However, I think that even more than improvement and > some reorganization of the technical documentation, there is a drastic > need for an "overview". This would have no bit fields or binary/hex > numbers in it but would try to give a thorough overview of the > proposal. It might incorporate some of the introductory and overview > material in the current draft but substantially augmented and > rewritten. > > What do other people think? Well ! I strongly support this view. Since I have not participated to any meeting, the paper has to be read several times to be understandable. Denis. > > Donald > > PS: I have gone through and replaced the secure hash standard with MD5 > everywhere in the draft as well as fixing many of the typos and am in > the process of de-emphasizing NTP, all as discussed in Seattle. I > plan to post this revised draft in a few days so people with > complaints about typos might want to wait to see if I've caught > them... > > --------------------------------------------------------------------------- > 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) > > -- ============================================================================ Denis Pinkas, Bull S.A E-mail : D.Pinkas@frmy.bull.fr 7, Rue Ampere Phone : (33-1) 69 93 95 75 91343 MASSY Cedex, France Fax : (33-1) 69 93 73 53 ============================================================================   Received: from sol.tis.com by magellan.TIS.COM id aa25653; 13 Apr 94 0:42 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17215; Wed, 13 Apr 94 00:42:06 EDT Received: by relay.tis.com; id AA00577; Wed, 13 Apr 94 00:43:00 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma000572; Wed Apr 13 00:42:21 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Apr 94 13:34:54 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404130435.AA02338@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Steve Kent Date: Wed, 13 Apr 94 13:34:52 JST Cc: paul@vix.com, dns-security@tis.com In-Reply-To: <9404122258.AA28259@relay.tis.com>; from "Steve Kent" at Apr 12, 94 6:55 pm X-Mailer: ELM [version 2.3 PL11] > For exmaple, ElGamal is an alternative signature algorithm > which is not itself patented, but which is embraced by the fundamental > Diffie-Hellman public key patent that expires in 1997 (I believe). That's better, I think. > To the extent > that folks have argued for this separation of public key functions in > PEM, and thus makeing PEM more algorithm independent, it seems a pity > to adopt a scheme for DNS security that is very much algorithm > dependent, even independent of patent issues. If we choose to support ElGamal to avoid RSA, it is still necessary to make the scheme algorithm dependent. If both algorithms are allowed to be supported by DNS, implementations will most certainly be forced to support RSA. > It is clear from the spec that Donald and George worked hard > to deisgn a scheme that minimizes the extra space taken up by > signatures. True. > That probably motivated the use of RSA, the only one of > the algorithms mentioned above that is "reversable" in terms of > signature data. I've found another reason not to use "reversable" property. If public key is not made public and distributed to limited number of people, it is confidentiality. So, to avoid issues such as US export control, I think we should use "one way" signature. > In principle, I'd feel more comfortable with an > algorithm independent design, but I realse there is a concern about > overflowing DNS UDP responses. As far as I know, the serious issue is on unavoidable fragmentation, not on overflowing responses. I've heard that some broken name servers or some wrong configuration have once caused a lot of backbone DNS traffic. But that's a separate issue. BTW, regardles of whether we use "reversable" property or not, some additional section processing will become impractical which will cause extra queries. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa01544; 13 Apr 94 13:52 EDT Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA18210; Wed, 13 Apr 94 13:51:43 EDT Message-Id: <9404131751.AA18210@tis.com> Reply-To: James M Galvin To: minutes@cnri.reston.va.us Cc: dns-security@tis.com Subject: Minutes of DNS Security March 1994 (Seattle) Meeting Mime-Version: 1.0 Content-Type: multipart/signed; boundary="----- =_aaaaaaaaaa1"; protocol="pem"; hashalg="md5" Date: Wed, 13 Apr 1994 13:51:56 -0400 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1516.766259444.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1516.766259444.3@tis.com> Enclosed below are the minutes from DNS Security working group. If there are any questions please let me know. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1516.766259444.4@tis.com> Content-Description: DNS Security WG Minutes DNS Security WG Meeting Minutes March 1994 Seattle Recorded by Jim Galvin, Chair The DNS Security Working Group met on Tuesday morning for a 2.5 hour meeting. Donald Eastlake and Charlie Kaufman had previously submitted a proposal (as an internet draft) for enhancing the DNS to support a digital signature security service. This meeting was dedicated to a review of that proposal. The meeting began with a review of the desired requirements identified at the BOF meeting held at the November 1993 Houston meeting. Donald and Charlie then led a presentation and discussion of their proposal. The following issues were discussed and resolved as indicated. o choice of algorithm The proposal currently specifies the SHA and RSA algorithms. It was agreed to replace SHA with MD5, the current Internet preference. o revisit DNS architecture The addition of SIG RRs increases the probability that the maximum UDP payload per packet may be exceeded. The requirement that we remain backward compatible with the existing installed base and the lack of empirical data to support the premise caused us to agree to leave the DNS architecture alone. o where do SIG RRs go in the reply A question was raised as to whether which section of the reply the SIG RRs should be placed. This is an issue because it was noted that, if necessary, implementations may ignore (and truncate) the additional records portion of a reply. It was agreed to query Paul Mockapetris in particular and to followup on the mailing list. o key per zone or key per server The proposal currently specifies that a public/private key pair is assigned to a zone, which is responsible for signing its data. In this way the data may be distributed by any server and, in fact, the actual signing of the data may (and should) occur as an off-line function. In addition, a specification is included for servers to optionally sign responses to queries. At this time it was agreed to leave the optional alternative in the document. We will revisit this issue after we have some implementation experience. o split the document It was suggested that the document may be better organized as several related documents. It was agreed Donald and/or Charlie would initiate a discussion of this issue on the mailing list. o use of the NTP time service The proposal currently emphasizes (if not requires) the use of a reliable time service, in particular NTP. It was agreed that DNS may depend on loosely synchronized clocks, on the order of a few hours. The authors agreed to rework this aspect of the proposal and to not mention any particular way of achieving synchronization. o partial and/or hash records The point was raised that the ability to directly include RRs of a particular type in more than one SIG record was overly complicated in that it caused the need for the "partial RR" signet to be sure you had all the relevant SIGs. The suggestion was that if all the RRs of a particular type did not fit directly into one SIG, the use of a hashed signet be required which would in turn require the RRs to be present in plain text outside the SIG. It was agreed to wait for implementation experience to see if this simplification to the proposal made sense. o key management It was observed that an integral part of the proposal is the specification of a key management protocol. As the new security area director was present at the meeting he was asked if the security area believed it was appropriate to specify another key management protocol, observing that both PEM and SNMP Security have also specified key management protocols. The response was that this key management protocol was sufficiently different from the other two that it was valuable in its own right and should remain part of the proposal. The meeting concluded with Jim Galvin noting that TIS would be implementing the proposal using the bind implementation of the DNS as a baseline. This software would be openly available to the Internet community. This group expects to meet in Toronto. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/signature Content-ID: <1516.766259444.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE= ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0= 2 MIC-Info: RSA-MD5,RSA,tprXf8o6YPOZMAL74VKG5b2kfC8MWVYlX8TmAaznlUrJZG/p49tY= aUw37Xa2nVdhFof0mz9N0O8czMws+9kgngd1JxMS7H17T5Ul7MOmsKPp9xTQWFoFR5oUUze1z1= FA ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa02479; 13 Apr 94 17:29 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06079; Wed, 13 Apr 94 17:29:27 EDT Received: by relay.tis.com; id AA07749; Wed, 13 Apr 94 17:30:21 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma007739; Wed Apr 13 17:29:44 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16688; Wed, 13 Apr 94 14:24:42 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA14309; Wed, 13 Apr 1994 17:26:18 -0400 Message-Id: <9404132126.AA14309@skidrow.lkg.dec.com> To: "Henry W. Miller" Cc: dns-security@tis.com Subject: Re: SIG RR location in responses..several comments. In-Reply-To: Your message of "Tue, 12 Apr 94 17:59:00 PDT." <0097CDB6.15533168.2174@sacto.mp.usbr.gov> Date: Wed, 13 Apr 94 17:26:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Henry W. Miller" To: sblair@upurbmw.us.dell.com Cc: dns-security@magellan.TIS.COM, henrym@sacto.mp.usbr.gov >> From: MX%"sblair@upurbmw.us.dell.com" 12-APR-1994 17:15:21.95 >> Subj: Re: SIG RR location in responses..several comments. >>... >> vixie: >> ------ >> Am I the only person reading all this who is concerned about >> using RSA, a patented and licensed technology, for DNS security? >> I am very reluctant to put into BIND any technology which would >> require vendors to pay a royalty to RSA before they could ship >> it with their systems. >> >> I for one am still thinking about what the overseas folks will do Paul. ? There are plenty of free reasonably high quality implementations of RSA available outside the United States. Just look in ftp.informatik.uni-hamburg.de or ghost.dsi.unimi.it or garbo.uwasa.fi. >> May I remind all about Austin Code Works and the current legal issue just >> surrounding PgP? Vendors are having a hard enough time keeping up with things >> as fast as they change. Not all companies have mechinisms in place that can >> support the audit trails well enough to be defeneded in court when RSA, etc. >> al., decides that they may not be getting their fair share of $$'s from the >> licensing issues. There are no clear winners, the vendor, the customers, loose, >> and the lawyers win. That is not the direction I'd like to see BIND/dnssec go. >> > This is probably an 11th hour suggestion, but I wonder if it >might be better to develop an en/decryption technique explictly for >use for DNS, and perhaps other Internet services? One that would not >suffer from copyright and export restrictions? It's a lot of work to develop good different crypto algorithms, people don't have that much confidence in them until they have undergone years of examination and, while you might avoid copyright restrictions, the export restrictions will be the same if it is equally strong and of the same type. As for patent restrictions, which you don't mention, RSADSI/PKP claims to control, at least until 1997, the idea of public key crypto regardless of the algorithm. Many people dispute this claim but you are not going to get out from under the patent shadow and possibility of law suits by designing a new public key algorithm. >>... >... >-HWM >---------- >Henry W. Miller >Assistant Systems and Network Manager >U.S. Bureau of Reclamation, Mid Pacific Region >2800 Cottage Way MP1130 >Sacramento, CA 95825 (916) 978-5108 >Inet: "henrym@sacto.mp.usbr.gov" > >"I've fallen, and I can't get up!" Donald   Received: from sol.tis.com by magellan.TIS.COM id aa03232; 14 Apr 94 0:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18366; Thu, 14 Apr 94 00:19:39 EDT Received: by relay.tis.com; id AA10290; Thu, 14 Apr 94 00:20:33 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma010284; Thu Apr 14 00:19:37 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Wed, 13 Apr 1994 21:16:24 -0700 Message-Id: <199404140416.AA02513@zephyr.isi.edu> To: "Donald E. Eastlake 3rd (Beast)" Cc: Paul A Vixie , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 12 Apr 1994 14:41:40 -0400. <9404121841.AA05194@skidrow.lkg.dec.com> Date: Wed, 13 Apr 94 21:14:34 PDT From: Paul Mockapetris I feel a bit responsible for adding some fuel to the fire, and wanted to suggest two principles: RSA deserves something for use of its technology, but consumers get to decide whether the price is fair and vote with their feet. But we can't make an informed decision on terms until we know them. Since I don't plan on going to law school, I'd like a simple statement from RSA. I am perfectly willing to believe that factoring large primes is tough, but crypto interfaces should probably admit to other choices; among other things, its just good modularity. (Yes I know that public and private key systems aren't the same, some systems claim to offer only authentication not...) paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa03317; 14 Apr 94 1:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18459; Thu, 14 Apr 94 00:30:41 EDT Received: by relay.tis.com; id AA10349; Thu, 14 Apr 94 00:31:36 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma010344; Thu Apr 14 00:31:03 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Wed, 13 Apr 1994 21:30:29 -0700 Message-Id: <199404140430.AA02692@zephyr.isi.edu> To: Steve Kent Cc: Paul A Vixie , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 12 Apr 1994 18:55:03 -0400. <9404122258.AA28259@relay.tis.com> Date: Wed, 13 Apr 94 21:28:40 PDT From: Paul Mockapetris DNS packets will get bigger, the only question is how much and how soon. We should plan on altering the present limit rather than squeezing bits. Truncation pressures will happen soon, even without security, because of several new applications coming up. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa03322; 14 Apr 94 1:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19049; Thu, 14 Apr 94 01:12:52 EDT Received: by relay.tis.com; id AA10581; Thu, 14 Apr 94 01:13:47 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma010575; Thu Apr 14 01:13:10 1994 Received: by gw.home.vix.com id AA27384; Wed, 13 Apr 94 22:12:35 -0700 Message-Id: <9404140512.AA27384@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: pvm@isi.edu Cc: Steve Kent , dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 13 Apr 1994 21:28:40 PDT." <199404140430.AA02692@zephyr.isi.edu> Date: Wed, 13 Apr 1994 22:12:35 -0700 From: Paul A Vixie i agree that DNS responses (and perhaps queries) are growing and will need more room. this isn't going to be a backward compatible change, though, and once we're paying the rip-everything-apart-and-put-in-new-software penalty, i think we should use the oppty to examine some other issues that have come up in the last few years.   Received: from sol.tis.com by magellan.TIS.COM id aa03071; 13 Apr 94 22:35 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16254; Wed, 13 Apr 94 22:35:06 EDT Received: by relay.tis.com; id AA09655; Wed, 13 Apr 94 22:36:02 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma009650; Wed Apr 13 22:35:54 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 14 Apr 94 11:28:30 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404140228.AA06895@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Thu, 14 Apr 94 11:28:28 JST Cc: dns-security@tis.com In-Reply-To: <9404111650.AA15440@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 11, 94 12:50 pm X-Mailer: ELM [version 2.3 PL11] > >A resolver must be able to securely know whether SIG RRs are available > >or not for which purpose SA is nothing. > > In a secure environment, your resolver will hopefully start from a > known secure zone. The way it tells whether other zones are secure is > by travering the DNS tree and looking at the RSA RRs. I now thinking your scheme does not work at all for traversing. You wrote: 7.1 Boot File Format 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. But I think updating of root keys is only as difficut as updating of root name servers and should be done anyway. As for traversing, suppose that there are Zones: A, B and C and assume the following: 1) B is a child zone of A 2) A and C is located independent region of the entire DNS tree 3) Neither A's nor C's parent is secure. 4) A is served by host X 5) B is served by host Y 6) C is served by host Z 7) B is poited from A 8) C is poited from B 9) host H knows KEY of A 10) Neither X nor H does not know that C is pointed from B. A C / \ / \ / \ / \ / \ / \ B / \ / \ / \ / \ / \ / pointer to C If zone C is traversed from the root, it is not secure, of course. So, how can a resolver on host H traverse DNS tree to know C is secure? In general, I think resolvers can't be sure that a zone is secure unless it knows key of its ancestor zone in advance. > The SA bit, which tells > about the characteristics of a particular server, has nothing to do > with this. Different servers for the same zone might some be security > aware with the SA bit on in their responses and some be security > non-aware with the SA bit off. Hmmm, I see. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa06594; 14 Apr 94 10:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04030; Thu, 14 Apr 94 10:21:49 EDT Received: by relay.tis.com; id AA13694; Thu, 14 Apr 94 10:22:45 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma013689; Thu Apr 14 10:21:52 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA06410; Thu, 14 Apr 94 07:15:12 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA20745; Thu, 14 Apr 1994 10:16:48 -0400 Message-Id: <9404141416.AA20745@skidrow.lkg.dec.com> To: pvm@isi.edu Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 13 Apr 94 21:28:40 PDT." <199404140430.AA02692@zephyr.isi.edu> Date: Thu, 14 Apr 94 10:16:48 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Yes, we need to eventually aim for a DNS-II with provision for bigger packets and some ideas that will help in that are in the *ixfr* draft you co-authored. I hope to post a message on that topic on namedroppers in not too long. However, I think we need vast improvements in Internet security urgently, DNS security can play a big part in that (particularly for key distribution), and all this will happen a lot sooner if existing DNS servers and DNS servers with only minor modifications can particiapte. The only server changes required for the current DNS security proposal are at the primaries and there all you need is to be able to recognize the new RRs in zone files and have an off line application to sign/secure a zone. This seems pretty easy to me. (You do also need extensive changes to the resolvers/clients that will be using security.) I don't think the current DNS proposal squeezes bits though I would admit to squeezing bytes. A much higher density (though more complex) proposal could be come up with if you were willing to squeeze bits. Donald From: Paul Mockapetris To: Steve Kent Cc: Paul A Vixie , dns-security@tis.com Reply-To: pvm@isi.edu In-Reply-To: Your message of Tue, 12 Apr 1994 18:55:03 -0400. <9404122258.AA28259@relay.tis.com> >DNS packets will get bigger, the only question is how much and how >soon. We should plan on altering the present limit rather than >squeezing bits. Truncation pressures will happen soon, even without >security, because of several new applications coming up. > >paul > >USC/Information Sciences Institute phone: 310-822-1511 x285 >4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 >90292   Received: from sol.tis.com by magellan.TIS.COM id aa07122; 14 Apr 94 11:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04059; Thu, 14 Apr 94 10:22:50 EDT Received: by relay.tis.com; id AA13706; Thu, 14 Apr 94 10:23:46 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma013697; Thu Apr 14 10:23:15 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA06853; Thu, 14 Apr 1994 10:21:48 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA06737; Thu, 14 Apr 94 10:17:21 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA02924; Thu, 14 Apr 94 10:21:06 EDT Message-Id: <9404141421.AA02924@pkarger.tcc> To: Masataka Ohta Cc: Steve Kent , paul@vix.com, dns-security@tis.com, pak0@gte.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 13 Apr 94 13:34:52 +0200." <9404130435.AA02338@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 94 10:21:05 -0400 From: "Paul A. Karger" The last few messages have discussed algorithm independence in the context of patents/licensing/legal issues. There is another more fundamental reason to design standards to be encryption algorithm independent. The history of cryptology clearly teaches us that (except for one-time pads) no algorithm lasts forever. Whether the algorithm is DES or RSA or ROT-13, a communications protocol should always have a provision for easily and quickly switching to a new algorithm in preparation for the day when the current algorithm of choice gets broken. - Paul   Received: from sol.tis.com by magellan.TIS.COM id aa07486; 14 Apr 94 12:51 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15148; Thu, 14 Apr 94 12:51:01 EDT Received: by relay.tis.com; id AA15185; Thu, 14 Apr 94 12:51:57 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma015173; Thu Apr 14 12:50:57 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA29770; Thu, 14 Apr 1994 18:51:57 +0200 Message-Id: <199404141651.AA29770@mitsou.inria.fr> To: Masataka Ohta Cc: Paul A Vixie , pvm@isi.edu, kent@bbn.com, dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Fri, 15 Apr 1994 00:40:05 +0200." <9404141540.AA10587@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 1994 18:51:56 +0200 From: Christian Huitema => > i agree that DNS responses (and perhaps queries) are growing and will need => > more room. this isn't going to be a backward compatible change, though, and => > once we're paying the rip-everything-apart-and-put-in-new-software penalty, => > i think we should use the oppty to examine some other issues that have come => > up in the last few years. => => I think we should start making name servers and resolvers can accept => (but not send) 64K byte UDP packets, immediately. => => Masataka Ohta That is really a terrible idea. The only error correction you can do on UDP is repeat the whole packet. In case of semi congested link, this is a sure kill. You could only do that if you replaced UDP by a "transaction" variant of TCP. Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa08173; 14 Apr 94 14:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17988; Thu, 14 Apr 94 13:24:27 EDT Received: by relay.tis.com; id AA15559; Thu, 14 Apr 94 13:25:22 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma015554; Thu Apr 14 13:24:57 1994 Received: by gw.home.vix.com id AA10646; Thu, 14 Apr 94 10:24:33 -0700 Message-Id: <9404141724.AA10646@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Fri, 15 Apr 1994 00:40:05 +0200." <9404141540.AA10587@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 1994 10:24:32 -0700 From: Paul A Vixie > I think we should start making name servers and resolvers can accept > (but not send) 64K byte UDP packets, immediately. > > Masataka Ohta i don't think so, for two reasons: (1) larger queries and responses cannot be generated without a protocol revision, which will almost certainly involve other changes than just maximum datagram size; (2) for a stub resolver, the maximum size of a response translates to stack space for the receive buffer -- and 64K is too large to ask every stub resolver client to have to grow. i was thinking that 1500 bytes would be reasonable, but before i put that into BIND i'll need at least an FYI blessed by pvm that gives the conditions under which a TC can be inferred when the sender puts more than 512 bytes into a dns datagram and the receiver isn't prepared to catch that many; also, i'll need some conceptual convergence from the wider DNS WG (not just this security group) on whether/when/why a sender would consider it reasonable to send a larger-than-512-byte datagram. sending it always seems like a bad plan. sending it if the packet size is in some range might not be right either. allocating one of the unused bits in the header to "long datagrams accepted" could be reasonable, but once again, this is something i'll need to see a blessed FYI on before i add code to BIND.   Received: from sol.tis.com by magellan.TIS.COM id aa08090; 14 Apr 94 14:03 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20937; Thu, 14 Apr 94 14:02:45 EDT Received: by relay.tis.com; id AA15948; Thu, 14 Apr 94 14:03:40 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma015942; Thu Apr 14 14:02:45 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 14 Apr 1994 10:59:16 -0700 Message-Id: <199404141759.AA13180@zephyr.isi.edu> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Thu, 14 Apr 1994 10:16:48 -0400. <9404141416.AA20745@skidrow.lkg.dec.com> Date: Thu, 14 Apr 94 10:57:27 PDT From: Paul Mockapetris > Yes, we need to eventually aim for a DNS-II with provision for bigger > packets and some ideas that will help in that are in the *ixfr* draft > you co-authored. I hope to post a message on that topic on > namedroppers in not too long. I'm unaware of any draft I co-authored. > However, I think we need vast improvements in Internet security > urgently, DNS security can play a big part in that (particularly for > key distribution), and all this will happen a lot sooner if existing > DNS servers and DNS servers with only minor modifications can > particiapte. > > The only server changes required for the current DNS security proposal > are at the primaries and there all you need is to be able to recognize > the new RRs in zone files and have an off line application to > sign/secure a zone. This seems pretty easy to me. (You do also need > extensive changes to the resolvers/clients that will be using > security.) > > I don't think the current DNS proposal squeezes bits though I would > admit to squeezing bytes. A much higher density (though more complex) > proposal could be come up with if you were willing to squeeze bits. I was trying to relax constraints, not impose them. Your design should not be constrained to fit all responses in 512ish packets. paul   Received: from sol.tis.com by magellan.TIS.COM id aa08636; 14 Apr 94 15:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26968; Thu, 14 Apr 94 15:24:28 EDT Received: by relay.tis.com; id AA16895; Thu, 14 Apr 94 15:25:24 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma016890; Thu Apr 14 15:24:43 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26746; Thu, 14 Apr 94 12:16:58 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23847; Thu, 14 Apr 1994 15:18:34 -0400 Message-Id: <9404141918.AA23847@skidrow.lkg.dec.com> To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 94 10:24:32 PDT." <9404141724.AA10646@gw.home.vix.com> Date: Thu, 14 Apr 94 15:18:34 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul, From: Paul A Vixie To: dns-security@tis.com In-Reply-To: Your message of "Fri, 15 Apr 1994 00:40:05 +0200." <9404141540.AA10587@necom830.cc.titech.ac.jp> >> I think we should start making name servers and resolvers can accept >> (but not send) 64K byte UDP packets, immediately. >> >> Masataka Ohta > >i don't think so, for two reasons: > >(1) larger queries and responses cannot be generated without a protocol > revision, which will almost certainly involve other changes than just > maximum datagram size; > >(2) for a stub resolver, the maximum size of a response translates to > stack space for the receive buffer -- and 64K is too large to ask every > stub resolver client to have to grow. > >i was thinking that 1500 bytes would be reasonable, but before i put that >into BIND i'll need at least an FYI blessed by pvm that gives the >conditions under which a TC can be inferred when the sender puts more than >512 bytes into a dns datagram and the receiver isn't prepared to catch that >many; also, i'll need some conceptual convergence from the wider DNS WG >(not just this security group) on whether/when/why a sender would consider >it reasonable to send a larger-than-512-byte datagram. sending it always >seems like a bad plan. sending it if the packet size is in some range >might not be right either. allocating one of the unused bits in the header >to "long datagrams accepted" could be reasonable, but once again, this is >something i'll need to see a blessed FYI on before i add code to BIND. I would think something more like 1250 bytes of DNS payload would be good. Then it would likely fit on Ethernet even with a considerable amount of header info (IPng, IPsec, ...) wrapped around it. If its true that many DNS implementations blindly copy header bits from a query into recursive queries they send, as I believe Ohta-san said, then wouldn't this cause problems if such a bit were used to indicate receptivity to long datagrams? Donald   Received: from sol.tis.com by magellan.TIS.COM id aa08666; 14 Apr 94 15:29 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27289; Thu, 14 Apr 94 15:29:31 EDT Received: by relay.tis.com; id AA16939; Thu, 14 Apr 94 15:30:27 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma016929; Thu Apr 14 15:30:08 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA27065; Thu, 14 Apr 94 12:22:03 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23911; Thu, 14 Apr 1994 15:23:38 -0400 Message-Id: <9404141923.AA23911@skidrow.lkg.dec.com> To: pvm@isi.edu Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 94 10:57:27 PDT." <199404141759.AA13180@zephyr.isi.edu> Date: Thu, 14 Apr 94 15:23:38 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Paul Mockapetris To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Reply-To: pvm@isi.edu In-Reply-To: Your message of Thu, 14 Apr 1994 10:16:48 -0400. <9404141416.AA20745@skidrow.lkg.dec.com> >> Yes, we need to eventually aim for a DNS-II with provision for bigger >> packets and some ideas that will help in that are in the *ixfr* draft >> you co-authored. I hope to post a message on that topic on >> namedroppers in not too long. > >I'm unaware of any draft I co-authored. My confusion I guess. You were among the short explicit list of people to whom I was told I should send comments on draft*ixfr*. >> However, I think we need vast improvements in Internet security >> urgently, DNS security can play a big part in that (particularly for >> key distribution), and all this will happen a lot sooner if existing >> DNS servers and DNS servers with only minor modifications can >> particiapte. >> >> The only server changes required for the current DNS security proposal >> are at the primaries and there all you need is to be able to recognize >> the new RRs in zone files and have an off line application to >> sign/secure a zone. This seems pretty easy to me. (You do also need >> extensive changes to the resolvers/clients that will be using >> security.) >> >> I don't think the current DNS proposal squeezes bits though I would >> admit to squeezing bytes. A much higher density (though more complex) >> proposal could be come up with if you were willing to squeeze bits. > >I was trying to relax constraints, not impose them. Your design >should not be constrained to fit all responses in 512ish packets. There are ceratinly cases where the response to a query won't fit into 512 bytes no matter what you do. However, any dns security proposal can be deployed more rapidly if most responses will fit into the current 512 bytes and if, as with our proposal, most DNS servers need not change at all for initial use. >paul Donald   Received: from sol.tis.com by magellan.TIS.COM id aa09479; 14 Apr 94 17:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06946; Thu, 14 Apr 94 17:29:44 EDT Received: by relay.tis.com; id AA18435; Thu, 14 Apr 94 17:30:40 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma018428; Thu Apr 14 17:30:18 1994 Received: by gw.home.vix.com id AA15573; Thu, 14 Apr 94 14:27:07 -0700 Message-Id: <9404142127.AA15573@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 1994 15:18:34 EDT." <9404141918.AA23847@skidrow.lkg.dec.com> Date: Thu, 14 Apr 1994 14:27:06 -0700 From: Paul A Vixie > 1250 bytes sounds reasonable. but like i said, this isn't a dns-security issue and i won't make a change of this nature in BIND without seeing at least an FYI published and knowing that PVM and the DNS WG have blessed it. > If its true that many DNS implementations blindly copy header bits > from a query into recursive queries they send, as I believe Ohta-san > said, then wouldn't this cause problems if such a bit were used to > indicate receptivity to long datagrams? yes. however, this will only hurt cases where the client sets them for its own nefarious purposes. the BIND resolver always clears the unused bits. if other resolvers (are there any?) do the same, we can safely allocate unused bits without hurting (or being hurt by) old software. bind's reuse of the query header for sending the response is something i'll probably try to change in 4.9.3's alpha test cycle, to see whether it causes widespread breakage. that's how it inherits all the query flags in the response. changing it will lead to great trepidation, since many reasonable changes to BIND have resulted in vastly unreasonable reactions from other/older software.   Received: from sol.tis.com by magellan.TIS.COM id aa09577; 14 Apr 94 18:10 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09242; Thu, 14 Apr 94 18:10:05 EDT Received: by relay.tis.com; id AA18779; Thu, 14 Apr 94 18:11:01 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma018773; Thu Apr 14 18:10:59 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA06335; Thu, 14 Apr 94 15:06:02 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25997; Thu, 14 Apr 1994 18:07:38 -0400 Message-Id: <9404142207.AA25997@skidrow.lkg.dec.com> To: Paul A Vixie Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 94 14:27:06 PDT." <9404142127.AA15573@gw.home.vix.com> Date: Thu, 14 Apr 94 18:07:38 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Paul A Vixie X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com In-Reply-To: Your message of "Thu, 14 Apr 1994 15:18:34 EDT." <9404141918.AA23847@skidrow.lkg.dec.com> >> If its true that many DNS implementations blindly copy header bits >> from a query into recursive queries they send, as I believe Ohta-san >> said, then wouldn't this cause problems if such a bit were used to >> indicate receptivity to long datagrams? > >yes. however, this will only hurt cases where the client sets them for >its own nefarious purposes. the BIND resolver always clears the unused >bits. if other resolvers (are there any?) do the same, we can safely >allocate unused bits without hurting (or being hurt by) old software. ? I was talking about a server getting a query and leaving bits that were set in the query it received set in *queries* that it sends. This seems like broken behavior which could lead to lots of problems and which you indicates that BIND does *not* do. For example, under the present dns sec proposal, if a security aware client set the Security Desired bit and sent off a query to a non-security aware server, one would hope this would have no effect except that possibly the SD bit would be on in the response. If this non-security aware server forwarded the SD bit on a recursive query to a security aware server, then that security aware server might, under the current proposal, surpress some RRs in responses because they are embodies in SIG RRs. This would confuse the intermediate non-security aware server which would not know how to unpack this stuff from the SIG. As a result, the original client might easily get a wrong failure indication for, say, an A RR it was looking for. >bind's reuse of the query header for sending the response is something >i'll probably try to change in 4.9.3's alpha test cycle, to see whether >it causes widespread breakage. that's how it inherits all the query >flags in the response. changing it will lead to great trepidation, >since many reasonable changes to BIND have resulted in vastly unreasonable >reactions from other/older software. I don't see much problem with leaving unknown bits that are on in a query on the the *response* sent to that query. That was what I assumed DNS servers would do. Why change this behaviour? Donald   Received: from sol.tis.com by magellan.TIS.COM id aa07227; 14 Apr 94 11:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10318; Thu, 14 Apr 94 11:45:21 EDT Received: by relay.tis.com; id AA14440; Thu, 14 Apr 94 11:46:16 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma014430; Thu Apr 14 11:46:06 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 00:40:07 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404141540.AA10587@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Paul A Vixie Date: Fri, 15 Apr 94 0:40:05 JST Cc: pvm@isi.edu, kent@bbn.com, dns-security@tis.com In-Reply-To: <9404140512.AA27384@gw.home.vix.com>; from "Paul A Vixie" at Apr 13, 94 10:12 pm X-Mailer: ELM [version 2.3 PL11] > i agree that DNS responses (and perhaps queries) are growing and will need > more room. this isn't going to be a backward compatible change, though, and > once we're paying the rip-everything-apart-and-put-in-new-software penalty, > i think we should use the oppty to examine some other issues that have come > up in the last few years. I think we should start making name servers and resolvers can accept (but not send) 64K byte UDP packets, immediately. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa10502; 15 Apr 94 1:40 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22681; Fri, 15 Apr 94 01:39:49 EDT Received: by relay.tis.com; id AA21981; Fri, 15 Apr 94 01:40:45 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma021976; Fri Apr 15 01:40:14 1994 Received: by gw.home.vix.com id AA23717; Thu, 14 Apr 94 22:39:48 -0700 Message-Id: <9404150539.AA23717@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Reply-To: paul@vix.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Fri, 15 Apr 1994 11:41:49 +0200." <9404150242.AA13052@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 1994 22:39:47 -0700 From: Paul A Vixie i remain convinced that this is not a thread that ought to be pursued on dns-security; it belongs in the DNS WG proper. however, several points here need addressing, so i'll address them here. > > >i was thinking that 1500 bytes would be reasonable, > > Reasonable today, but not in the future, I'm afraid. IPng will need 20 > byte NSAP or 8, 16, 24, ... byte ASEQ, at least. Rob Austin mentioned > the possibility to have a lot more root NSes at the last DNS BOF, 1500 bytes may or may not be a reasonable upper bound for DNS responses; that's not an issue i've considered debating. 1500 bytes _is_ a reasonable size for a UDP datagram that wants to avoid fragmentation in most of 1994's networks. 1500 bytes is also a reasonable buffer size for a stub resolver to use without unduly affecting the application it is being called from. > > >it reasonable to send a larger-than-512-byte datagram. sending it always > > >seems like a bad plan. sending it if the packet size is in some range > > >might not be right either. > > Like root NS cases, there will be a lot of cases when one must send > packets > 512. So, if we must change something, we should change the > protocol so that they can be sent always. i don't know who the DNS WG chair is; perhaps she would like to hear your suggestion. > > >allocating one of the unused bits in the header > > >to "long datagrams accepted" could be reasonable, but once again, this is > > >something i'll need to see a blessed FYI on before i add code to BIND. > > Still, it might be good to allocate a bit to indicate that client can > receive larger (maybe 4096 or 8192) packet or psuedo TCP reply. that's what i said? > > If its true that many DNS implementations blindly copy header bits > > from a query into recursive queries they send, as I believe Ohta-san > > said, then wouldn't this cause problems if such a bit were used to > > indicate receptivity to long datagrams? > > It is unlikely that forwarders can't have enough amount of buffer > (recent processors have more than 64KB of onchip chache), but if > you mind, make forwarders not blidnly copy bits. that doesn't matter! i admit that i am becoming most frustrated with your repeated misunderstandings of the ideas expressed in this forum. you cannot possibly be as ignorant of the actual issues as the above paragraph indicates; i therefore suspect a translation error or great carelessness or both. please take the time to understand the issues being discussed before you post a message to the entire forum which proclaims your ignorance as this one did. i will be glad to help you, constructively, to understand the issues under discussion; all you need to do is approach me privately rather than sending broadcast messages. (hint: many of the forwarders that are "blindly copying bits" are going to keep doing that, and we need to design any/all protocol enhancements with that thought clearly in our minds.) > As a candidate of other changes, I'd like to propose the preservance > of the order of RRs. It'll make load balancing work better. it would have been wonderful indeed if that had been designed into the DNS spec originally. however, i know of one popular caching forwarder that LIFO's its RR's under certain conditions. since DNS datagrams have no version stamp, it will never be possible for a resolver to know whether a response has been generated or cached by some forwarder that does this; absent a complete protocol turn, it will not be possible to depend on RR ordering. i have directed replies to myself, to spare the list any further messages on this non-security-related thread.   Received: from sol.tis.com by magellan.TIS.COM id aa10085; 14 Apr 94 22:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18944; Thu, 14 Apr 94 22:17:43 EDT Received: by relay.tis.com; id AA20690; Thu, 14 Apr 94 22:18:39 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma020685; Thu Apr 14 22:18:07 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 11:09:45 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404150210.AA12880@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Christian Huitema Date: Fri, 15 Apr 94 11:09:43 JST Cc: paul@vix.com, pvm@isi.edu, kent@bbn.com, dns-security@tis.com In-Reply-To: <199404141651.AA29770@mitsou.inria.fr>; from "Christian Huitema" at Apr 14, 94 6:51 pm X-Mailer: ELM [version 2.3 PL11] > => I think we should start making name servers and resolvers can accept > => (but not send) 64K byte UDP packets, immediately. > That is really a terrible idea. The only error correction you can do on UDP is > repeat the whole packet. In case of semi congested link, this is a sure kill. That's why I haven't said we should generate 64K reply. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa10177; 14 Apr 94 22:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19309; Thu, 14 Apr 94 22:49:53 EDT Received: by relay.tis.com; id AA20918; Thu, 14 Apr 94 22:50:49 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma020906; Thu Apr 14 22:50:02 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 11:41:50 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404150242.AA13052@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: "Donald E. Eastlake 3rd" Date: Fri, 15 Apr 94 11:41:49 JST Cc: paul@vix.com, dns-security@tis.com In-Reply-To: <9404141918.AA23847@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 14, 94 3:18 pm X-Mailer: ELM [version 2.3 PL11] > >i was thinking that 1500 bytes would be reasonable, Reasonable today, but not in the future, I'm afraid. IPng will need 20 byte NSAP or 8, 16, 24, ... byte ASEQ, at least. Rob Austin mentioned the possibility to have a lot more root NSes at the last DNS BOF, > >it reasonable to send a larger-than-512-byte datagram. sending it always > >seems like a bad plan. sending it if the packet size is in some range > >might not be right either. Like root NS cases, there will be a lot of cases when one must send packets > 512. So, if we must change something, we should change the protocol so that they can be sent always. > >allocating one of the unused bits in the header > >to "long datagrams accepted" could be reasonable, but once again, this is > >something i'll need to see a blessed FYI on before i add code to BIND. Still, it might be good to allocate a bit to indicate that client can receive larger (maybe 4096 or 8192) packet or psuedo TCP reply. > I would think something more like 1250 bytes of DNS payload would be > good. Then it would likely fit on Ethernet even with a considerable > amount of header info (IPng, IPsec, ...) wrapped around it. IPng is OK and 1250 might be reasonable. But, IPsec will be constructed over secure DNS, not vice versa, I think. > If its true that many DNS implementations blindly copy header bits > from a query into recursive queries they send, as I believe Ohta-san > said, then wouldn't this cause problems if such a bit were used to > indicate receptivity to long datagrams? It is unlikely that forwarders can't have enough amount of buffer (recent processors have more than 64KB of onchip chache), but if you mind, make forwarders not blidnly copy bits. Masataka Ohta PS As a candidate of other changes, I'd like to propose the preservance of the order of RRs. It'll make load balancing work better.   Received: from sol.tis.com by magellan.TIS.COM id aa15234; 18 Apr 94 11:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28628; Mon, 18 Apr 94 11:18:26 EDT Received: by relay.tis.com; id AA18075; Mon, 18 Apr 94 11:19:27 EDT Message-Id: <9404181519.AA18075@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma018067; Mon Apr 18 11:18:49 1994 To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Thu, 14 Apr 94 10:16:48 -0400. <9404141416.AA20745@skidrow.lkg.dec.com> Date: Mon, 18 Apr 94 11:13:24 -0400 From: Steve Kent Donald, I didn't personally use the term "squeeing bits" but I think it is fair to say that the scheme in question, does strive to be space efficient, in that it eschews the algorithm-independent approach of basing signatures on one-way hash values, for a hybrid approach that relies on RSA's ability to sign data in a reversible fashion. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa18583; 19 Apr 94 1:25 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18128; Tue, 19 Apr 94 01:24:36 EDT Received: by relay.tis.com; id AA24249; Tue, 19 Apr 94 01:25:39 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma024199; Tue Apr 19 01:20:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Apr 94 14:08:59 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404190509.AA01554@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: paul@vix.com Date: Tue, 19 Apr 94 14:08:57 JST Cc: dns-security@tis.com In-Reply-To: <9404150539.AA23717@gw.home.vix.com>; from "Paul A Vixie" at Apr 14, 94 10:39 pm X-Mailer: ELM [version 2.3 PL11] > > Reasonable today, but not in the future, I'm afraid. IPng will need 20 > > byte NSAP or 8, 16, 24, ... byte ASEQ, at least. Rob Austin mentioned > > the possibility to have a lot more root NSes at the last DNS BOF, > > 1500 bytes may or may not be a reasonable upper bound for DNS responses; > that's not an issue i've considered debating. 1500 bytes _is_ a reasonable > size for a UDP datagram that wants to avoid fragmentation in most of 1994's > networks. 1500 bytes is also a reasonable buffer size for a stub resolver > to use without unduly affecting the application it is being called from. There are several goals and limitations on DNS packet data size. My estimations are: size which does not cause fragmentation (8) size which does not cause fragmentation most of the time in the past (512) size which does not cause fragmentation most of the time today (1400) size which does not cause serious fragmentation today (4K~8K) size which does not cause fragmentation most of the time in the future (4K~8K) size which does not cause serious fragmentation in the future (64K) size for stub resolvers (512~64K, opinions vary) minimum size necessary for DNS today (>512) minimum size necessary for DNS in the future (>1500) size which is assured to be accepted by existing servers (512) size which can be accepted by most of the existing servers (1024) > that doesn't matter! i admit that i am becoming most frustrated with your > repeated misunderstandings of the ideas expressed in this forum. You are too narrowly sighted on the issue. If we are to make backward incompatile change, we should do so not to require such a change again in the future. > (hint: many of the forwarders that are "blindly copying bits" are going to > keep doing that, and we need to design any/all protocol enhancements with > that thought clearly in our minds.) Many of the existing forwarders (including your BIND) won't accept packets larger than 1024 bytes, which makes the proposed protocaol change backward incompatible. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa19084; 19 Apr 94 5:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18426; Tue, 19 Apr 94 01:42:42 EDT Received: by relay.tis.com; id AA24348; Tue, 19 Apr 94 01:43:45 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma024313; Tue Apr 19 01:39:43 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Apr 94 14:33:16 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404190533.AA01660@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Steve Kent Date: Tue, 19 Apr 94 14:33:14 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9404181519.AA18075@relay.tis.com>; from "Steve Kent" at Apr 18, 94 11:13 am X-Mailer: ELM [version 2.3 PL11] > Donald, > > I didn't personally use the term "squeeing bits" but I think > it is fair to say that the scheme in question, does strive to be space > efficient, in that it eschews the algorithm-independent approach of > basing signatures on one-way hash values, for a hybrid approach that > relies on RSA's ability to sign data in a reversible fashion. It is signature which is large. Unfortunately, as signatures are truely random, you can't squeeze bits at all. On the other hand, other data are small. You don't have to vigorously squeeze bits from them unless it is absoltely necessary. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa21055; 19 Apr 94 9:58 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02472; Tue, 19 Apr 94 09:58:13 EDT Received: by relay.tis.com; id AA27367; Tue, 19 Apr 94 09:59:17 EDT Message-Id: <9404191359.AA27367@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma027358; Tue Apr 19 09:58:17 1994 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 19 Apr 94 14:33:14 +0200. <9404190533.AA01660@necom830.cc.titech.ac.jp> Date: Tue, 19 Apr 94 09:53:54 -0400 From: Steve Kent Masataka, While it is true that signatures are large, the use of RSA in the current scheme enables one to pack multiple, short data items into a single signature block. If one were required to sign hashes, not data items, then data items that are shorter than the hash could not be packed in this fashion. This is the feature of the current scheme that makes its RSA-dependent and which is clearly motivated by a desire to optimize for space in server responses. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa21807; 19 Apr 94 13:13 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22373; Tue, 19 Apr 94 13:12:56 EDT Received: by relay.tis.com; id AA29263; Tue, 19 Apr 94 13:14:00 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma029258; Tue Apr 19 13:13:39 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20397; Tue, 19 Apr 94 10:05:15 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17982; Tue, 19 Apr 1994 13:06:55 -0400 Message-Id: <9404191706.AA17982@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-Reply-To: Your message of "Thu, 07 Apr 94 12:04:18 +0200." <9404070304.AA00261@necom830.cc.titech.ac.jp> Date: Tue, 19 Apr 94 13:06:55 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: <9404062135.AA10640@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Apr 6, 94 5:35 pm X-Mailer: ELM [version 2.3 PL11] >> Well, I went and read Section 4.2.1 of RFC 1034 very carefully and it >> didn't change my opinion that you could retrieve the type A glue >> record with a separate query, just like you can retrieve the RSA >> and/or SIG RR's with a separate query. You seem to be assuming that I >> meant an A RR query to the server pointed to by the NS RR and, as you >> say, you can't query that unless you have its IP address. What I >> meant was an A RR query to the same server where you initially found >> the NS for this lower level zone, i.e., the server where the A record >> is present as glue. Would this actually not work in current >> implementations? > >It does not work. Have you actually tried it? Using nslookup I have no problems at all retrieving type A glue records by doing specific queries for them. That includes from the root servers which, I understand, have chaching turned off. So I must really be getting it from their zone database and not because they also happen to have cached, it. I still think that if you need a name (NS, for example) and its IP address and the key for its zone and you need all this signed because you are doing secure resolution and all this won't fit in a UDP packet, then it makes no logical difference what is dropped as long as you can get it later with an additional query(s). Having said all that, it is probably more "natural" for a resolver to do additional queries for RRs of the same name, such as key or signature RRs, and less "natural" to do a glue RR retrieval with the appropriate different owner name. The current draft already clearly states that additional info type A's are included in the additional info seciton with *higher* priority than the corresponding key RR. I've put in a change that says that if an additional info type A and its SIG won't both fit, the type A should be included. (Previously said it may be included.) >What do you think "truncation problem" means, at all? It seems to me that what problem is caused by truncation depends on the context. In the context we are talking about, it could, for example, be that all the name servers for a zone had names inside that zone so you could never get to any of them unless you could get their IP address via a type A glue record. However, a sufficiently clever resolver could, on noticing truncation in the additional information section on an NS retreival, do explicit A retrieval from the server where it got the NS's looking for glue information. I don't know if any existing resolvers do that. >> As long as you need the A glue RR and the RSA RR and the SIG RR >> signing them to securely look into a zone, I just don't see that much >> difference between truncation losing different ones of them. > >Anyway, if you think the problem does not exist, it's OK. If you have >any further concern on the real truncation prolem related to glue records, >ask it in "namedroppers". > >The conclusion here is not to make secure DNS complex only trying to >solve non-existent problem. > >That's because you don't udnerstand Sorry I don't always understand you but I find many of your remarks to be very short and cryptic. While I certainly don't claim that all of my remarks are models of clarity or anything, when there is confusion, I try my best to give clearer and more complete explanations. >> >That is: >> > 1) Don't introduce new abbreviaiton and use the RR format >> > currently used in the DNS packets. >> > 2) Always use MD5 >> > 3) Use a single record for authenticaiton, not multiple SIGs >> >> Re your points 1 & 2: >> A specific requirement decided at the Houston IETF was not to >> take significantly more queries. If you start getting lots of >> truncation, you will start having to make twice as many queries. Many >> people think this would be a problem. > >With 1 and 2, there will be no extra queries, because there won't be >much truncations occure. Only statistics and/or reasonable projections are going to convince anyone on this question. >> Re your point 3: >> I am not willing to accept the limits a single SIG RR with >> only hash signets places on the number of types of RR you can have >> under a name. Even completely ignoring glue and message signets, you >> need 18 bytes. With the minimum allowed key size, then only 3 types >> of RRs you would be allowed to have securely under a name. > >I'm assuming to use something like RSA-CBC here. Sorry, but I don't know what you means by RSA-CBC. And the kinds of things "RSA-CBC" suggest to me don't seem like they would be useful in the DNS case. Please give a more detailed explatation. >> >SD copied by security unaware forwarders will cause a lot of problems. >> >> Ahh... It was not clear to me that you were talking about copying >> into forwarded requests rather than responses. If they are being >> copied forward like that, then it clearly is a problem. The next >> thing I would suggest is not to set the SD bit until you actually get >> a reply with the SA (security available bit). This means your first >> query would be less efficient but you would cache this flag and later >> queries could be more efficient. > >It might be an acceptable hack if your scheme were already widely deplyed. > >Otherwise, IMHO, it is too complex to be acceptable. According to later posts by Paul Vixie, at least BIND clears all these bits in queries it sends so it would not have problems with an initial resolver set SD bit. >> If unused bits are also being copied >> back into replies sent by servers in response to recursive queries >> from the bit set on replies they receive, then using header bits to >> indicate security awareness is pretty hopeless and security awareness >> will probably have to wait for "DNS-II" or whatever based on a >> different op code or something else that does not have these unused >> header bit problems. > >I'm afraid your proposal, using new representation of RR records and >breaks several DNS architechture, is pretty much close to DNS-II. > >SD bit on means too much. I don't think so. I'm about to post something re "DNS-II" on namedroppers so you can see what I mean. The SD bit just means that the resolver is announcing it is security aware. If you are ever going to have a server do anything different for security aware resolvers, you need some way to signal this. >> >> >Is it really meaningfull to remove one or two 14 byte record when you >> >> >are using 128 byte (1024) SIG RR(s)? >> >> >> >> I make no assumptions about the total size of RRs >> > >> >Then, you can't evaluate the effect of your optimizaiton. >> >> What I meant was that I tried to make the minimum of limiting >> assumptions on the total size of RRs. > >Neither do I. > >> By not assuming such limits, I >> came up with a scheme which works when the optimizations it proposes >> are required and when a scheme without such optimizations will not >> work. Thus, under my broad assumptions, I can evaluate my >> optimizations as being required to meet the dns security design goals. > >My opinion is that with usual circumstance, your optimization is >ineffective and, thus, should be removed. Why are the optimizations in our scheme "ineffective"? They do save space and there are cases when they reduce the number of queries necessary. Or did you mean "unnecessary" becasue you don't think such cases will ever occur? >> >> Eliminating an RR when it is incorporated inside the SIG is optional >> >> under the current draft. >> > >> >Name servers with different OPTIONS can't communicate each other. >> >So, it can't be optional. >> >> Why can't they communicate with each other? >> >> Under the proposal, a security aware server composing a reply to a >> security aware resolver can surpress RR's included in a SIG or not. A >> security aware resolver has to be able to handle it either way. > >Then, it is mandatory for resolvers. Yes, it is mandatory for resolvers that declare themselves to be security aware using the SD bit (or possibly in some other way if there turn out to be insurmountable problems with the SD bit). Non-security aware resolvers don't have to do anything about it because they won't get replies where RRs have been surpressed. >> Under >> the general Internet principle of being conservative in what you send >> and liberal in what you accept, security aware servers should always >> surpress the RR in replies they send but security aware resolvers >> should accept replies where they are not surpressed. > >I'm afraid you completely misunderstand the Internet. > >Under the general Internet principle of being conservative in what you >send, security aware servers should always ADD the RR in replies, which >is what current DNS is doing. I guess what is conservative and what is liberal is in the eye of the beholder. You are comparing behavious with current DNS. I am comparing behavior (for an exchange between a secruity aware resolver and a security aware server only) with the recommended optimized behavior. >As such a behaviour is quite basic to the current DNS, even the >most conservative secutiry aware resolvers don't have to accept >completely broken replies. > >Your proposal to try to handle partial RRs makes many assumptions, >such as caching behaviour, of the current implementaiton of DNS. ? There aren't any "partial RRs" in our proposal. Perhaps you mean the partial RR signet? >> >> But there are clearly cases when not >> >> eliminating a plain text RR that did fit into the SIG will cause >> >> truncation. It might, for example, force the RSA RR additional >> >> information mentioned above to not fit and cause truncation. >> > >> >Unlike glue As, you can remove large RRs from the additional >> >section without causing any problem. OK? >> >> It causes the problem of twice as many queries. > >In rare case when SIG is large, yes, which affect the expected number >of queries very little. See remarks above about how this will only be settled by reasonable statistics/projections. >> >> I thought people considered the draft complicated enough as it is. >> > >> >That's why I suggest simplification. Why don't we use MD5 all the time? >> >> Because it leads to bigger replies, more truncation, and more queries. > >No. If RRs of a type is large, truncation occurs anyway. If it is small >truncation won't occure. The latter is almost always the case. See remarks above about how this will only be settled by reasonable statistics/projections. >> >> suppose some compression scheme could be added but I would not want to >> >> do that unless implementation experience indicated it was necessary. >> >> >> >> If I did want to add compression, >> > >> >No, please. >> >> Sorry, I thought you were complaining about the lack of compression of >> RRs when they were incorporated in SIGs. Certainly more compression >> could be done. > >I'm complaining about the complexity of your scheme trying to reduce >the packet size which will, most of the time, result in the increase >of the size. ? The various signature encoding means in our proposal provide many ways to get the maximum benefit from each signature RR. I don't see why you say they will increase the packet size. >> >What I suggested was to use block authentication to cover larger >> >number of signets. >> >> ? Block authentication? Do you mean transaction/message >> authentication? If you suggested something like this in an earlier >> message, either I didn't understand it or I don't remember it. > >As I wrote, something like RSA-CBC. As I say above, I really have no idea what you mean by RSA-CBC. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa21879; 19 Apr 94 13:17 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22707; Tue, 19 Apr 94 13:17:00 EDT Received: by relay.tis.com; id AA29297; Tue, 19 Apr 94 13:18:03 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma029290; Tue Apr 19 13:18:00 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20803; Tue, 19 Apr 94 10:11:37 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA18021; Tue, 19 Apr 1994 13:13:16 -0400 Message-Id: <9404191713.AA18021@skidrow.lkg.dec.com> To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 12 Apr 94 15:22:30 PDT." <9404122222.AA23689@gw.home.vix.com> Date: Tue, 19 Apr 94 13:13:16 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Paul A Vixie >I'd like to speak to the recurring statement in this forum that since RSA's >technology has already been written into the PEM standard, why should we >readdress those issues now in DNS? I have never said that. I think, however, that the selection of RSA public keys for PEM, various international security standards, and many other systems is one factor that it is quite reasonable to take into account, along with numerious other factors. >My answer comes in several parts. > >First and foremost, the PEM agreements were wrong-headed and politically >motivated, in my view. DNS could [use] PEM as a PKP/RSA precedent only if the >decision to use RSA had been quite a bit less controversial during the PEM >standardization process, or if the results of that standardization process >had been an uncontestable win. Neither case obtains. PEM is so far a >failure, after having been a divisive, bitter battle between people who had >formerly been but will probably not again become partners in various common >causes. I agree that PEM is dismal failure but, unfortunately, I don't agree with much else in the paragraph above. The failure of PEM has nothing to do with RSA. (In my opinion, it has to do with trying to force a single hierarchy instead of making any hierarchy optional, using the hopeless "Distinguished Name"s, X.500 viewpoint, Asinine One syntax, etc.) Look at a more successful secure mail system, PGP. It uses RSA also. Secondly, the harder fought was the decision to use RSA in PEM, the stronger a precedent it is. If RSA had just sailed through, the decision to adopt there could have been overlooked problems. But if it was highly controversial, then I think it very likely that most problems were considered and overcome. >Second, DNS is an ``essential service'' in Internet. Mail has been important >and will no doubt continue to be important, but I personally know several >people who use only NNTP and WWW and consider themselves ``Internet citizens.' ' >I do not know of any person or any service which can survive and prosper on >the Internet without being able to translate symbolic names into addresses, >and vice-versa. So? There is no proposal to cause any existing DNS service to stop working. >Third, while PEM will (if it succeeds, which is still possible) merely >enable new uses for Mail, an RSA version of DNS will have far more sweeping >effects. Even if PEM becomes common, people will still be able to do the >same things with unauthenticated mail that they did before PEM came out; ditto DNS. >the risk will be that senders of mail cannot be authenticated, allowing all >kinds of forgeries. People whose businesses depend on authenticity of Mail >can pay for and use PEM; it would be wildly silly of them to do otherwise, >given its existence as an Internet standard. However, once a secure >version of DNS comes out, people who aren't able to use it will be subject >to all kinds of forgeries involving actual sessions on their computers or >refusal of their sessions on other people's computers -- I predict that when >secure DNS comes out, ``everybody'' will use it, out of a concern for self- >defense that drawfs any worries they may have had about unauthenticated Mail. Come on. Based on the type of analysis you are doing above, there is no difference at all between secure mail and secure DNS. With unsecure mail, you get bogus messages. With unsecure DNS, you get bogus RRs. Your wording above strongly suggests that the deployment of secure DNS will *cause* people without it to be subject to forgeries they are not subject to now. I can't see how that can be true. Furthermore, secure DNS does not protect you against forged TCP sessions. All it does in enable you to tell if RRs you have retrieved are authentic. Period. Someone can still forge random TCP/IP packets. So I think the gains of secure DNS are not such that "everyone" will be compelled to jump on it immediately, though of course it will be quite useful and, I hope, popular. >Unless someone wants to debate this point in greater detail, I would like all >participants in the larger "should we use RSA in DNS" debate to stop quoting >PEM as either a success story or a precedent. PEM has not been a success, >and did/does not have a comparable result-domain. I don't quote PEM as a success story. And, while the importance of PEM as a precedent is debatable, I don't see how you can claim it is not a precedent. I plan to continue to quote PEM, PGP, ISO, Lotus Notes (which uses RSA) and other precedents where appropriate. >Paul Vixie >Redwood City, CA >decwrl!vixie!paul > ><><><><><><><><><><><><><><><><><><><><><><><><><>< I believe that public key tchnology is essential to a workable secure DNS and that RSA is technically superior to alternatives. Why are we giving such enormous weight to the small cost that will temporarily be imposed on US providers of services requiring secure DNS that have not bought their DNS with a pubic key license included? Any public key system will impose some cost on this segment of the market. No one outside the US needs to worry about RSA at all (although they would for some other public key technologies). No one giving away their TCP/IP stack or BIND in the US needs to worry. No one selling their TCP/IP stack inside the US needs to worry if either they are already licensed for RSA or they are willing to simply sell their product with non-secure DNS and give away the tailored secure DNS that goes with their product. No one offering a commercial service requiring secure DNS inside the US need worry if they buy their DNS from someone who is licensed. So what's left? A few years in which people in the US only who offer services requiring secure DNS and who don't get their DNS software from a licensed vendor will have to pay a reasonable license fee. Donald From: Paul A Vixie To: Masataka Ohta Cc: dns-security@tis.com In-Reply-To: Your message of "Tue, 12 Apr 1994 12:54:21 +0200." <9404120354.AA26666@necom830.cc.titech.ac.jp> >> Does someone know what happens if my RSA-BIND interact with RSA-BIND in US? > >that depends on how complete the eventual RFC is. if it specifies the >algorythm, than if the RSA you use in japan is different from the one >released publically by RSA here in the US, i suspect that japan's will >lose out. Paul, Given the simplicity and elegance of RSA (there is really only one right answer to modular exponentiation of positive whole integers), I can't see how different sets of RSA routines could be any problem at all. You sound a little like the people from NSA trying to convince Congressmen that there is something inferior to foreign (ie, non-US) implemented DES and that only American DES is good DES, to justify export restrictions. Really, all DESes and all RSAs interoperatve whether implemented by US citizens in the USA or otherwise. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa23077; 19 Apr 94 15:33 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03224; Tue, 19 Apr 94 15:33:06 EDT Received: by relay.tis.com; id AA00679; Tue, 19 Apr 94 15:34:10 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma000672; Tue Apr 19 15:34:03 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA29445; Tue, 19 Apr 94 12:26:39 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA19319; Tue, 19 Apr 1994 15:28:19 -0400 Message-Id: <9404191928.AA19319@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Thu, 14 Apr 94 11:28:28 +0200." <9404140228.AA06895@necom830.cc.titech.ac.jp> Date: Tue, 19 Apr 94 15:28:19 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: "Donald E. Eastlake 3rd" In-Reply-To: <9404111650.AA15440@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Apr 11, 94 12:50 pm >> >A resolver must be able to securely know whether SIG RRs are available >> >or not for which purpose SA is nothing. >> >> In a secure environment, your resolver will hopefully start from a >> known secure zone. The way it tells whether other zones are secure is >> by travering the DNS tree and looking at the RSA RRs. > >I now thinking your scheme does not work at all for traversing. I'm not sure what you mean. See below. >You wrote: > > 7.1 Boot File Format > > 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. > >But I think updating of root keys is only as difficut as updating of >root name servers and should be done anyway. Yes, the root zone key should be updated occasionally. The draft recommends chainging zone keys annually. My point was that if there are 1,000,000 stub resolvers out there, having them all start only knowing the root zone key is a *bad* idea. >As for traversing, suppose that there are Zones: A, B and C and assume >the following: > > 1) B is a child zone of A > 2) A and C is located independent region of the entire DNS tree > 3) Neither A's nor C's parent is secure. > 4) A is served by host X > 5) B is served by host Y > 6) C is served by host Z Security is based on the zone structure. What zone is on what server(s) does not make any difference. All the zones could be served from one host or all from different hosts. It makes no difference. > 7) B is pointed from A > 8) C is pointed from B > 9) host H knows KEY of A > 10) Neither X nor H does not know that C is pointed from B. > > > A C > / \ / \ > / \ / \ > / \ / \ > B / \ / \ > / \ / \ > / \ > / > pointer to C > > >If zone C is traversed from the root, it is not secure, of course. > >So, how can a resolver on host H traverse DNS tree to know C is secure? For host H to securely know that C is secure, it must get to it entirely through secured RRs. In the case you describe, then if H tries to go up to root or the first common domain name from A and then back down to C, it must treat C as not secure. After all, someone may be spoofing output from root or this common higher node. The only way around this is for the pointer to C in zone B to be accompanied by an RSA RR for zone C. Since zone B is secure, this RSA RR will be signed. Since zone A was secure, the key for zone B was signed by A along with the NS RRs for B in A. So host H can trust zone C. This was the question that Jeff Schiller was asking at the DNS SEC WG meeting in Seattle. >In general, I think resolvers can't be sure that a zone is secure >unless it knows key of its ancestor zone in advance. That's easier but there is nothing to stop horizontal signing of keys between arbitrary parts of the DNS tree. >> The SA bit, which tells >> about the characteristics of a particular server, has nothing to do >> with this. Different servers for the same zone might some be security >> aware with the SA bit on in their responses and some be security >> non-aware with the SA bit off. > >Hmmm, I see. > > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa23931; 19 Apr 94 18:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13319; Tue, 19 Apr 94 18:12:29 EDT Received: by relay.tis.com; id AA01990; Tue, 19 Apr 94 18:13:33 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma001983; Tue Apr 19 18:13:25 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA09128; Tue, 19 Apr 94 15:05:40 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21085; Tue, 19 Apr 1994 18:07:19 -0400 Message-Id: <9404192207.AA21085@skidrow.lkg.dec.com> To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 94 10:21:05 EDT." <9404141421.AA02924@pkarger.tcc> Date: Tue, 19 Apr 94 18:07:19 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp The Domain Name System seems like one are where you really want global interoperability and universal adoption of one algorithm at a time. This was discussed at the Working Group Meeting and it was felt that some must be zero bits that could be used to signal a change to a new algorithm, should one ever prove necessary, were adequate. Actually, while there are such bits in the signature RR, right now there is no such bit in the key RR. The write up on the key RR says to ignore ones in the undefined bits so I will change that so there is a clear escape bit. From: "Paul A. Karger" To: Masataka Ohta Cc: Steve Kent , paul@vix.com, dns-security@tis.com, pak0@gte.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories In-Reply-To: Your message of "Wed, 13 Apr 94 13:34:52 +0200." <9404130435.AA02338@necom830.cc.titech.ac.jp> >The last few messages have discussed algorithm independence in >the context of patents/licensing/legal issues. There is >another more fundamental reason to design standards to be >encryption algorithm independent. The history >of cryptology clearly teaches us that (except for one-time pads) >no algorithm lasts forever. Whether the algorithm is DES >or RSA or ROT-13, a communications protocol DES and ROT-13 are terrible examples for you to pick. ROT-13 is a deliberately trivial algorithm. DES was known to be just on the verge of computational inadequacy from day one. These algorithms were doomed from the start. No forseeable amount of processor improvement or an reasonable projection of algorithm improvements will obsolete RSA in the next few decades with the key sizes provided which is all I'm willing to worry about. It would take a discontinuous mathematical breakthrough, which is certainly not impossible but, in my mind, improbable. >should always have a provision for easily and quickly switching to >a new algorithm in preparation for the day when the current algorithm >of choice gets broken. > > - Paul While I do not believe that RSA will be broken anytime soon, I agree that there should be a provision for phasing over to some other algorithms should that prove necessary for any reason. Putting the flag bytes first in the signature and key RRs and having a must-be-zero bit to flag such a change seems adequate to me. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24011; 19 Apr 94 18:52 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13788; Tue, 19 Apr 94 18:51:46 EDT Received: by relay.tis.com; id AA02250; Tue, 19 Apr 94 18:52:50 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma002245; Tue Apr 19 18:52:20 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA17172; Tue, 19 Apr 1994 18:50:02 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA06391; Tue, 19 Apr 94 18:48:30 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA13784; Tue, 19 Apr 94 18:49:21 EDT Message-Id: <9404192249.AA13784@pkarger.tcc> To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 19 Apr 94 18:07:19 EDT." <9404192207.AA21085@skidrow.lkg.dec.com> Date: Tue, 19 Apr 94 18:49:15 -0400 From: "Paul A. Karger" Don Eastlake writes: >DES and ROT-13 are terrible examples for you to pick. ROT-13 is a >deliberately trivial algorithm. DES was known to be just on the verge >of computational inadequacy from day one. These algorithms were >doomed from the start. > >No forseeable amount of processor improvement or an reasonable >projection of algorithm improvements will obsolete RSA in the next few >decades with the key sizes provided which is all I'm willing to worry >about. It would take a discontinuous mathematical breakthrough, which >is certainly not impossible but, in my mind, improbable. I don't expect RSA to be broken anytime soon, either, BUT ----- The entire history of cryptography is littered with crypto algorithms that were thought to be unbreakable until someone broke them. The ONLY provably unbreakable algorithm is one-time pads. Everything else is potentially breakable. I really think that no matter how secure we think RSA (or any other algorithm) is, a communications standard should provide a mechanism to allow a change in algorithm if the unthinkable should actually happen. >While I do not believe that RSA will be broken anytime soon, I agree >that there should be a provision for phasing over to some other >algorithms should that prove necessary for any reason. Putting the >flag bytes first in the signature and key RRs and having a >must-be-zero bit to flag such a change seems adequate to me. A one bit flag to define an algorithm change is not adequate. Just as for many other protocols, the right thing to do is to define an algorithm type field and a registry of algorithms and define a protocol negotiation over what algorithm is actually going to be used. I have no problem with defining a default algorithm, so that negotiation need not be done unless you actually want some other algorithm. By doing this, you also provide the mechanism so that communities of interest who find RSA unacceptable (for whatever reason) can substitute crypto algorithms of their own choosing. That would allow substituting a weak algorithm for compliance with US export control or an NSA-provided algorithm for DoD purposes or some other algorithm whose use was required in some other country or an algorithm free of patent license restrictions, etc. (NO - I'm not advocating CLIPPER here - only flexibility in choice of algorithm) Obviously, if different communities choose different algorithms, then communications between those communities will fail, but that is by their choice.   Received: from sol.tis.com by magellan.TIS.COM id aa24523; 20 Apr 94 0:49 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22592; Wed, 20 Apr 94 00:48:46 EDT Received: by relay.tis.com; id AA04447; Wed, 20 Apr 94 00:49:51 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma004442; Wed Apr 20 00:48:58 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA22103; Tue, 19 Apr 94 21:06:39 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23362; Wed, 20 Apr 1994 00:08:17 -0400 Message-Id: <9404200408.AA23362@skidrow.lkg.dec.com> To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 19 Apr 94 18:49:15 EDT." <9404192249.AA13784@pkarger.tcc> Date: Wed, 20 Apr 94 00:08:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Paul A. Karger" To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories In-Reply-To: Your message of "Tue, 19 Apr 94 18:07:19 EDT." <9404192207.AA21085@skidrow.lkg.dec.com> Paul, >Don Eastlake writes: >>DES and ROT-13 are terrible examples for you to pick. ROT-13 is a >>deliberately trivial algorithm. DES was known to be just on the verge >>of computational inadequacy from day one. These algorithms were >>doomed from the start. >> >>No forseeable amount of processor improvement or an reasonable >>projection of algorithm improvements will obsolete RSA in the next few >>decades with the key sizes provided which is all I'm willing to worry >>about. It would take a discontinuous mathematical breakthrough, which >>is certainly not impossible but, in my mind, improbable. > >I don't expect RSA to be broken anytime soon, either, BUT ----- > >The entire history of cryptography is littered with crypto algorithms >that were thought to be unbreakable until someone broke them. The ONLY >provably unbreakable algorithm is one-time pads. Everything else >is potentially breakable. So? I agreed with you that RSA might be broken. Why are you still pounding on a point where I agree with you? >I really think that no matter how secure we think RSA (or any >other algorithm) is, a communications standard should provide a >mechanism to allow a change in algorithm if the unthinkable should >actually happen. So? I agreed with you that a mechanism should be provided to "allow a change in algorithm if the unthinkable should actually happen" and will make the one minor change in the draft needed to complete this feature. Why are you still pounding on a point where I agree with you? >>While I do not believe that RSA will be broken anytime soon, I agree >>that there should be a provision for phasing over to some other >>algorithms should that prove necessary for any reason. Putting the >>flag bytes first in the signature and key RRs and having a >>must-be-zero bit to flag such a change seems adequate to me. > >A one bit flag to define an algorithm change is not adequate. >Just as for many other protocols, the right thing to do is to define >an algorithm type field and a registry of algorithms and define a >protocol negotiation over what algorithm is actually going to be used. >I have no problem with defining a default algorithm, so that negotiation >need not be done unless you actually want some other algorithm. WRONG! This is not IPSEC, where it is reasonable for different groups to be able to communicate only disjointly. This is The Domain Name Service. It is designed on the principles that all of the information in it is public, that it gives the same answers to all who query it, that there is one unified service. The DNS Security Working group, without a single objection, rejected any ideas of access control or confidentiality. And you want to have different groups unable to communicate due to different algorithms! The WG, quite reasonably, didn't want *any* increase in the number of datagram involved in queries, if possible. And you want to add cyrpto algorithm negotiation!?!? >By doing this, you also provide the mechanism so that communities of >interest who find RSA unacceptable (for whatever reason) can substitute >crypto algorithms of their own choosing. That would allow substituting >a weak algorithm for compliance with US export control or an NSA-provided >algorithm for DoD purposes or some other algorithm whose use was required >in some other country or an algorithm free of patent license restrictions, >etc. (NO - I'm not advocating CLIPPER here - only >flexibility in choice of algorithm) Give me a break with this export crap. Can you name one Internet connected country that does not have the domestic expertise to implement RSA or use anonymous ftp? And they have no patent considerations being outside the US. Weak security is usually a *bad* idea, whether for export or other reasons. It's frequently misleading and thus worse than no security. And what in the world is the use of exporting this braindamaged weak security DNS when it then couldn't interoperate with stronger hypothetically non-exported security? Or do you think we should just give up on being secure because of the short sighted US Government policies? If DoD or some other country wants something different, its a free world and they can screw themselves by cutting themselves off from the main DNS servic if they want. The patent restrictions on RSA, which I believe to be the techncially superior public key algorithm choice, seem so minor that I really don't understand what all the fuss is about. >Obviously, if different communities choose different algorithms, then >communications between those communities will fail, but that is by >their choice. If it does not interoperate with the real DNS, its not DNS. Any community that wants to can write their own informational RFC on how they are doing DNS security and, if they want too, set up their own root and do their own thing. But none on that has anything to do with the secure Internet DNS service. No all "communications" protocols are the same (actully DNS is more of a database protocol...). The right thing for DNS is that tere should be EXACTLY ONE security algorithm for The DNS for global interoperability. However, it is reasonable to make provisions for rolling over to a new algorithm eventually, should that prove necessary for any reason. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24996; 20 Apr 94 4:14 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25583; Wed, 20 Apr 94 04:13:52 EDT Received: by relay.tis.com; id AA05810; Wed, 20 Apr 94 04:14:57 EDT Received: from munnari.oz.au(128.250.1.21) by relay via smap (V1.3mjr) id sma005802; Wed Apr 20 04:14:48 1994 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02264; Wed, 20 Apr 1994 17:03:22 +1000 (from kre@munnari.OZ.AU) To: "Donald E. Eastlake 3rd (Beast)" Cc: Masataka Ohta , dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-Reply-To: Your message of "Tue, 19 Apr 1994 13:06:55 -0400." <9404191706.AA17982@skidrow.lkg.dec.com> Date: Wed, 20 Apr 1994 17:03:23 +1000 Message-Id: <14814.766825403@munnari.OZ.AU> From: Robert Elz Date: Tue, 19 Apr 94 13:06:55 -0400 From: "Donald E. Eastlake 3rd (Beast)" Message-ID: <9404191706.AA17982@skidrow.lkg.dec.com> >> What I >> meant was an A RR query to the same server where you initially found >> the NS for this lower level zone, i.e., the server where the A record >> is present as glue. Would this actually not work in current >> implementations? > >It does not work. Have you actually tried it? I was going to stay out of this, however ... In most present implementations this probably will work (ie: in BIND it works). However it probably shouldn't work. Unless a request is asking for a recursive search (RD) of a server that permits recursive queries (RA), I believe that the proper response to an A query in a zone that is (one or more levels) delegated from the current server is to return the NS records for the delegation, and in the additional info section, any extra data that may be present, appropriate, and fit (ie: generate a referral). Returning the A record, just because the current server happens to know it, or think it knows it, seems totally bogus to me, whether or not BIND (and possibly other servers) act that way now. If the reason for the A request was that a previous NS request was returned without the necessary A glue records in the additional info section, then I can't think of a single reason why an A query of the same server (unless it happens to be authoritative for the zone in question) should return anything even slightly different. kre   Received: from sol.tis.com by magellan.TIS.COM id aa24375; 19 Apr 94 23:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20559; Tue, 19 Apr 94 22:33:05 EDT Received: by relay.tis.com; id AA03745; Tue, 19 Apr 94 22:34:09 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma003740; Tue Apr 19 22:34:05 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 11:27:56 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404200228.AA05898@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Steve Kent Date: Wed, 20 Apr 94 11:27:55 JST Cc: dns-security@tis.com In-Reply-To: <9404191340.AA24373@cc.titech.ac.jp>; from "Steve Kent" at Apr 19, 94 9:53 am X-Mailer: ELM [version 2.3 PL11] > Masataka, > > While it is true that signatures are large, the use of RSA in > the current scheme enables one to pack multiple, short data items into > a single signature block. Most of the time, the data item is small so that it is not meaningful to try to remove it. > If one were required to sign hashes, not > data items, then data items that are shorter than the hash could not > be packed in this fashion. Data shorter than hash? That is exactly the case where removal of the data (it's short) is not so meaningful. > This is the feature of the current scheme > that makes its RSA-dependent and which is clearly motivated by a > desire to optimize for space in server responses. My point is that such an optimizaiton is just an optimization at most, not an optimization most of the time and incompatible to basic architechture of name servers. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24785; 20 Apr 94 3:35 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25018; Wed, 20 Apr 94 03:34:39 EDT Received: by relay.tis.com; id AA05369; Wed, 20 Apr 94 03:35:44 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma005361; Wed Apr 20 03:35:25 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 16:29:12 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404200729.AA07346@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses & Re: Real truncation problem To: "Donald E. Eastlake 3rd" Date: Wed, 20 Apr 94 16:29:10 JST Cc: dns-security@tis.com In-Reply-To: <9404191706.AA17982@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 19, 94 1:06 pm X-Mailer: ELM [version 2.3 PL11] > >It does not work. > > Have you actually tried it? Using nslookup I have no problems at all > retrieving type A glue records by doing specific queries for them. The problem is that the information returned is glue information and should not be treated otherwise. Unlike authoritative information, it should not be cached lightly. Though BIND (4.8.3, at least) is doing otherwise, it is a secutiry hole. RFC1034 says: :4.2.1. Technical considerations :To fix this problem, a zone contains "glue" RRs which are not :part of the authoritative data, and are address RRs for the servers. :These RRs are only necessary if the name server's name is "below" the :cut, and are only used as part of a referral response. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Having said all that, it is probably more "natural" for a resolver to > do additional queries for RRs of the same name, such as key or > signature RRs, and less "natural" to do a glue RR retrieval with the > appropriate different owner name. Exactly. Unlike As, SIGs shouldn't be glue and can be dropped. So, elaborated compaction is not necessary. > >What do you think "truncation problem" means, at all? > It seems to me that what problem is caused by truncation depends on > the context. In the context we are talking about, it could, for > example, be that all the name servers for a zone had names inside that > zone so you could never get to any of them unless you could get their > IP address via a type A glue record. Correct. > However, a sufficiently clever > resolver could, on noticing truncation in the additional information > section on an NS retreival, do explicit A retrieval from the server > where it got the NS's looking for glue information. I don't know if > any existing resolvers do that. The problem is that properly implemented name servers shouldn't answer such queries unless it also have (a cached copy of) authoritative information. > >> >That is: > >> > 1) Don't introduce new abbreviaiton and use the RR format > >> > currently used in the DNS packets. > >> > 2) Always use MD5 > >> > 3) Use a single record for authenticaiton, not multiple SIGs > >> > >> Re your points 1 & 2: > >> A specific requirement decided at the Houston IETF was not to > >> take significantly more queries. If you start getting lots of > >> truncation, you will start having to make twice as many queries. Many > >> people think this would be a problem. > > > >With 1 and 2, there will be no extra queries, because there won't be > >much truncations occure. > > Only statistics and/or reasonable projections are going to convince > anyone on this question. I have locally run etherfind. Most DNS replay are less then 256 bytes. > Sorry, but I don't know what you means by RSA-CBC. And the kinds of > things "RSA-CBC" suggest to me don't seem like they would be useful in > the DNS case. Please give a more detailed explatation. As you should know, block encryption for long text is done block by block. That's all. I'm not interested in the detail of whether it is by EBC or CBC (Cipher Block Chaining). > According to later posts by Paul Vixie, at least BIND clears all these > bits in queries it sends so it would not have problems with an initial > resolver set SD bit. What? He wrote: >Moreover, aren't the current name servers copying the unused bits >of query packets? yes. and later > (hint: many of the forwarders that are "blindly copying bits" are going to > keep doing that, and we need to design any/all protocol enhancements with > that thought clearly in our minds.) > >My opinion is that with usual circumstance, your optimization is > >ineffective and, thus, should be removed. > > Why are the optimizations in our scheme "ineffective"? Ineffective? No, it's often worse than compressed domain names. > >Under the general Internet principle of being conservative in what you > >send, security aware servers should always ADD the RR in replies, which > >is what current DNS is doing. > > I guess what is conservative and what is liberal is in the eye of the > beholder. Wrong. You just misunderstand conservative behaviour of SD bit copying. > >Your proposal to try to handle partial RRs makes many assumptions, > >such as caching behaviour, of the current implementaiton of DNS. > > ? There aren't any "partial RRs" in our proposal. Perhaps you mean > the partial RR signet? No. I mean partial set of SIG RRs. See section 7.4 of RFC1035. > ? The various signature encoding means in our proposal provide many > ways to get the maximum benefit from each signature RR. I don't see > why you say they will increase the packet size. Lack of domain name compression. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24964; 20 Apr 94 4:03 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25446; Wed, 20 Apr 94 04:02:48 EDT Received: by relay.tis.com; id AA05605; Wed, 20 Apr 94 04:03:53 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma005597; Wed Apr 20 04:03:19 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 16:57:26 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404200757.AA07527@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Wed, 20 Apr 94 16:57:24 JST Cc: dns-security@tis.com In-Reply-To: <9404191928.AA19319@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 19, 94 3:28 pm X-Mailer: ELM [version 2.3 PL11] > >But I think updating of root keys is only as difficut as updating of > >root name servers and should be done anyway. > > Yes, the root zone key should be updated occasionally. The draft > recommends chainging zone keys annually. Hmmm, I think it is bad to specify the period of time to update keys in the draft. It is an operational issue to be determinded elsewhere. > My point was that if there > are 1,000,000 stub resolvers out there, having them all start only > knowing the root zone key is a *bad* idea. What? Stub resolvers knows friendly recursive name servers (by thier addresses and, optionaly, host keys (not zone keys)) only. > > > > A C > > / \ / \ > > / \ / \ > > / \ / \ > > B / \ / \ > > / \ / \ > > / \ > > / > > pointer to C > >So, how can a resolver on host H traverse DNS tree to know C is secure? > The only way around this is for the pointer to C in zone B to be > accompanied by an RSA RR for zone C. Since zone B is secure, this RSA > RR will be signed. Since zone A was secure, the key for zone B was > signed by A along with the NS RRs for B in A. So host H can trust > zone C. Things does not work in such a way. As H serves zone A only, not zone B, it can't traverse the secure pointers from zone A through B to zone C. H won't perform exhaustive search of secure zones to know whether C is reachable or not. Note that the pointer to C in Zone B is not authoritative to B. It seems to me that you, again, don't understand what authoritativeness implies. > This was the question that Jeff Schiller was asking at the DNS SEC WG > meeting in Seattle. I remembeer. I now think that is the real problem. > >In general, I think resolvers can't be sure that a zone is secure > >unless it knows key of its ancestor zone in advance. > > That's easier but there is nothing to stop horizontal signing of keys > between arbitrary parts of the DNS tree. Why, do you think, the current DNS is designed NOT to horizontaly travers name servers? There ARE reasons. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa29452; 20 Apr 94 12:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09588; Wed, 20 Apr 94 11:29:33 EDT Received: by relay.tis.com; id AA09116; Wed, 20 Apr 94 11:30:39 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma009111; Wed Apr 20 11:30:14 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBE85DK1O0000ZNO@FNAL.FNAL.GOV>; Wed, 20 Apr 1994 10:29:31 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA09926; Wed, 20 Apr 94 10:28:46 CDT Date: Wed, 20 Apr 1994 10:28:45 -0500 From: Matt Crawford Subject: Re: DNS security draft In-Reply-To: Your message of Wed, 20 Apr 94 16:57:24 +0200. <9404200757.AA07527@necom830.cc.titech.ac.jp> To: dns-security@tis.com Cc: Masataka Ohta , "Donald E. Eastlake 3rd" Message-Id: <9404201528.AA09926@munin.fnal.gov> Content-Transfer-Encoding: 7BIT What it boils down to seems to be this. Any resolver or server which preserves the distinction between authoritative and non-authoritative (example: glue) data better than BIND does will break the proposed scheme of cross-authentication of zones. What other ways are there for a client to start with one trusted zone A (a zone whose public it believes it knows) and find the public key of another zone B, or learn that B is not secured? In the most general case, A's zone administrator will not have signed B's key. If there isn't a chain of certificates for parent zones of A all the way up to a common ancestor C of A and B, and a then chain of certificates for subzones from C down to B, then I don't see any deterministic way to get trusted information about B by mechanisms stridtly within DNS. What about putting certificates of arbitrary other zones within zone A's authoritative namespace? This could be done with or without a special name in the zone, in order to place certificates at a known point, such as B.certificates.A (example: es.net.certificate.fnal.gov). We don't have special names now, and I don't suppose anyone is keen to introduce them. Without a special name, all certificates would have to be stored at the top of a zone, and include information within the RDATA. The client could only ask for all certificates at once, and should expect to need a TCP connection to get them. The RSA RDATA format described in the draft has no room for the name of the owner of the key, so I propose a third RR type: the CERT, or "certificate" RR. The RDATA field of a CERT RR would contain a (as defined in RFC 1035) and all the fields of the RSA RDATA. Needless to say, a CERT not covered by a SIG record MUST be discarded. Because of the similarity between the RSA and the CERT RR, an alternative is to add a usually-redundant to the RSA RDATA. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa00965; 20 Apr 94 17:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03406; Wed, 20 Apr 94 17:47:49 EDT Received: by relay.tis.com; id AA13002; Wed, 20 Apr 94 17:48:55 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma012995; Wed Apr 20 17:47:54 1994 Received: by gw.home.vix.com id AA02559; Wed, 20 Apr 94 14:47:21 -0700 Date: Wed, 20 Apr 94 14:47:21 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: DNS security draft Organization: Vixie Enterprises Message-Id: References: <9404201528.AA09926@munin.fnal.gov> Nntp-Posting-Host: office.home.vix.com In-Reply-To: crawdad@munin.fnal.gov's message of 20 Apr 1994 10:03:42 -0700 >What it boils down to seems to be this. Any resolver or server which >preserves the distinction between authoritative and non-authoritative >(example: glue) data better than BIND does will break the proposed >scheme of cross-authentication of zones. > >[...] BIND as of 4.9 preserves the distinction between authoritative and nonauthoritative data; a future (post-4.9.3) version will probably answer with a NOERROR/referral if a query arrives without RD for a name with non-authoritative matching RR's. as of 4.9 we are already deleting all previous data in a node when more-authoritative info comes in. credibility levels are, in increasing order: additional or authority data nonauthoritative answer authoritative answer authoritative local zone (pri or sec) more details wouldn't be relevant to this thread. i just wanted to keep everybody from believing the BIND is still as brain-dead as it used to be. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa01808; 21 Apr 94 3:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14066; Thu, 21 Apr 94 03:22:06 EDT Received: by relay.tis.com; id AA16564; Thu, 21 Apr 94 03:23:12 EDT Received: from munnari.oz.au(128.250.1.21) by relay via smap (V1.3mjr) id sma016558; Thu Apr 21 03:22:56 1994 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28124; Thu, 21 Apr 1994 17:20:27 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: Paul A Vixie , dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Thu, 21 Apr 1994 15:23:54 +0200." <9404210624.AA13149@necom830.cc.titech.ac.jp> Date: Thu, 21 Apr 1994 17:20:21 +1000 Message-Id: <14973.766912821@munnari.OZ.AU> From: Robert Elz Date: Thu, 21 Apr 94 15:23:54 JST From: Masataka Ohta Message-ID: <9404210624.AA13149@necom830.cc.titech.ac.jp> That's not enough. For a little more secure DNS, if RD is on, the server should perform recursive search even if it has glue data. My preference would be for glue A's to be treated just like the root server hints, and for the server to query the appropriate servers soon after it starts and replace the glue with answers from the authoritative servers, and then refresh that as the TTL requires (I'd probably start a refresh at about half TTL expired - except for TTL's that are absurdly small, in which case I'd probably just refresh at some moderate period). Given that, the recursive search has already been performed, and the glue can be returned like any other cached answer. It would slow the DNS system absurdly if we required that cached answers never be used to reply to queries. Still, other additional information such as A for MX is a security hole, I'm afraid. I'm not sure I believe that. Or, not any more than any other non security aware DNS lookup is a security hole. If I trust a DNS server enough to tell me the name of the host to which I should send mail for some domain, then I think I will also trust it enough to tell me the associated address. If that server is in untrustworthy hands, then anything goes anyway (the MX name value isn't worth anything), if on the other hand it can be fooled into believing an invalid address, then I see no reason that any other server can't be fooled the same way. ie: I see nothing inherantly wrong in believing the A record that may be in additional info with an MX answer. kre   Received: from sol.tis.com by magellan.TIS.COM id aa01692; 21 Apr 94 2:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13094; Thu, 21 Apr 94 02:29:54 EDT Received: by relay.tis.com; id AA16260; Thu, 21 Apr 94 02:30:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma016254; Thu Apr 21 02:30:20 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 21 Apr 94 15:23:56 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404210624.AA13149@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Paul A Vixie Date: Thu, 21 Apr 94 15:23:54 JST Cc: dns-security@tis.com In-Reply-To: ; from "Paul A Vixie" at Apr 20, 94 2:47 pm X-Mailer: ELM [version 2.3 PL11] > BIND as of 4.9 preserves the distinction between authoritative and > nonauthoritative data; a future (post-4.9.3) version will probably answer > with a NOERROR/referral if a query arrives without RD for a name with > non-authoritative matching RR's. That's not enough. For a little more secure DNS, if RD is on, the server should perform recursive search even if it has glue data. Still, other additional information such as A for MX is a security hole, I'm afraid. > more details wouldn't be relevant to this thread. i just wanted to keep > everybody from believing the BIND is still as brain-dead as it used to be. So, in general, DNS, not specifically BIND, is unsecure. That's why secure DNS is necessary. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa04243; 21 Apr 94 9:55 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24975; Thu, 21 Apr 94 09:55:16 EDT Received: by relay.tis.com; id AA18963; Thu, 21 Apr 94 09:56:23 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma018951; Thu Apr 21 09:55:25 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA03281; Thu, 21 Apr 94 06:46:35 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA08028; Thu, 21 Apr 1994 09:48:17 -0400 Message-Id: <9404211348.AA08028@skidrow.lkg.dec.com> To: Matt Crawford , Robert Elz Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Wed, 20 Apr 94 10:28:45 CDT." <9404201528.AA09926@munin.fnal.gov> Date: Thu, 21 Apr 94 09:48:16 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Matt, From: Matt Crawford In-Reply-To: Your message of Wed, 20 Apr 94 16:57:24 +0200. <9404200757.AA07527@necom830.cc.titech.ac.jp> To: dns-security@tis.com >What it boils down to seems to be this. Any resolver or server which >preserves the distinction between authoritative and non-authoritative >(example: glue) data better than BIND does will break the proposed >scheme of cross-authentication of zones. I believe I understand this issue much better now. >What other ways are there for a client to start with one trusted zone >A (a zone whose public it believes it knows) and find the public key >of another zone B, or learn that B is not secured? > >In the most general case, A's zone administrator will not have signed >B's key. If there isn't a chain of certificates for parent zones of >A all the way up to a common ancestor C of A and B, and a then chain of >certificates for subzones from C down to B, then I don't see any >deterministic way to get trusted information about B by mechanisms >strictly within DNS. > >What about putting certificates of arbitrary other zones within zone >A's authoritative namespace? This could be done with or without a >special name in the zone, in order to place certificates at a known >point, such as B.certificates.A (example: es.net.certificate.fnal.gov). >We don't have special names now, and I don't suppose anyone is keen to >introduce them. In the proposed dns security scheme, a certificate is just a signed key RR. Special names seem kind of kludgy... >Without a special name, all certificates would have to be stored at the >top of a zone, and include information within the RDATA. The client >could only ask for all certificates at once, and should expect to need >a TCP connection to get them. The RSA RDATA format described in the >draft has no room for the name of the owner of the key, so I propose a >third RR type: the CERT, or "certificate" RR. The RDATA field of a >CERT RR would contain a (as defined in RFC 1035) and all >the fields of the RSA RDATA. Needless to say, a CERT not covered by a >SIG record MUST be discarded. If a key for anther zone is present for some particular reason, such as an NS for a subzone or because of an MX, PTR, CNAME, or whatever, then the key RR should have the same owner name. It would usually be retrieved as additional info if you have a security aware resolver and server. This doesn't have anything to do with finding the zone where, say, the CNAME is. It just means that if you find it via non-secure intervening zones, you will have a trusted key that you can use to validate it. If you find it via secure intervening zones, you could end up with another trusted key which is probably more recent but you can trust the results if they are signed either key. However, in the general case, you can just store some other zone keys under the zone name. For a secure zone, its own key and the superzone key would normally occur at the zone name node anyway. (You need the superzone to be able to climb the tree and its a good idea to have its own key so that even if you get to the zone insecurely, you can at least do internal signature verification in the zone.) The only problem with this is that if enough keys were there that they overflowed the UDP limit then, as you say, you would need to use TCP. I tend to think of the superzone key as the most important so perhaps the spec should require that it be returned first so you could always get it with UDP even if other keys were lost to truncation... I don't know how much cross certfication like this is going to occur but, if you are willing to use TCP, there is no particular reason you couldn't have hundreds of keys for miscellaneous zones stored in and vouched for by your trusted local zone. >Because of the similarity between the RSA and the CERT RR, an >alternative is to add a usually-redundant to the RSA >RDATA. This is the first thing that occurred to me. Unless people object, I'll change the key RR in the next draft to have the object name that the key is associated with explicit rather than being the RR owner name. In the common case where they are the same, this will cost only one byte with DNS name compression. >_________________________________________________________ >Matt Crawford crawdad@fnal.gov Fermilab All this means that a secure DNS implementation will have to be able to find keys based on the domain name of the object the key is associated with, not just the owner name of the key RR. Donald To: Robert Elz cc: dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-reply-to: Your message of "Wed, 20 Apr 94 17:03:23 +1000." <14814.766825403@munnari.OZ.AU> -------- Robert, Thanks for your clear and detailed response. From: Robert Elz To: "Donald E. Eastlake 3rd (Beast)" Cc: Masataka Ohta , dns-security@tis.com In-Reply-To: Your message of "Tue, 19 Apr 1994 13:06:55 -0400." <9404191706.AA17982@skidrow.lkg.dec.com> > Date: Tue, 19 Apr 94 13:06:55 -0400 > From: "Donald E. Eastlake 3rd (Beast)" > Message-ID: <9404191706.AA17982@skidrow.lkg.dec.com> > > >> What I > >> meant was an A RR query to the same server where you initially found > >> the NS for this lower level zone, i.e., the server where the A record > >> is present as glue. Would this actually not work in current > >> implementations? > > > >It does not work. > > Have you actually tried it? > >I was going to stay out of this, however ... In most present >implementations this probably will work (ie: in BIND it works). > >However it probably shouldn't work. Unless a request is asking >for a recursive search (RD) of a server that permits recursive >queries (RA), I believe that the proper response to an A >query in a zone that is (one or more levels) delegated from the >current server is to return the NS records for the delegation, >and in the additional info section, any extra data that may be >present, appropriate, and fit (ie: generate a referral). Minor comment: It seems to me that even currently required glue records need not be to an inferior zone. I'm not sure if such cases occur but you could have zone A serverd by host A and zone X served by host X and then have B.A served by Y.X and Y.X served by B.A (or equivalent more realistic and complicated cases). In this case zone A must have glue to Y.X and zone X must have glue to B.A or you aren't going to get very far. >Returning the A record, just because the current server happens >to know it, or think it knows it, seems totally bogus to me, >whether or not BIND (and possibly other servers) act that way >now. > >If the reason for the A request was that a previous NS request >was returned without the necessary A glue records in the >additional info section, then I can't think of a single reason >why an A query of the same server (unless it happens to be >authoritative for the zone in question) should return anything >even slightly different. > >kre Donald   Received: from sol.tis.com by magellan.TIS.COM id aa04477; 21 Apr 94 11:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28596; Thu, 21 Apr 94 10:48:43 EDT Received: by relay.tis.com; id AA19543; Thu, 21 Apr 94 10:49:49 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma019538; Thu Apr 21 10:49:02 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA22503; Thu, 21 Apr 1994 10:47:09 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA11781; Thu, 21 Apr 94 10:44:51 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA17525; Thu, 21 Apr 94 10:46:28 EDT Message-Id: <9404211446.AA17525@pkarger.tcc> To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 20 Apr 94 00:08:17 EDT." <9404200408.AA23362@skidrow.lkg.dec.com> Date: Thu, 21 Apr 94 10:46:22 -0400 From: "Paul A. Karger" I'm sorry that you found my suggestion of supporting multiple crypto algorithms so controversial or that you thought I was "pounding on a point". I was only trying to make what I thought was a mild and non-controversial suggestion that mandating a particular algorithm is not necessarily the best approach, even for a public directory service, such as DNS. If my messages came across otherwise, then I apologize for causing a problem. Multiple algorithm support provides a number of features, some of which may be of value to DNS and some of which may only be "nice to haves" or may be irrelevant to DNS. The remainder of this message will try to summarize what these features are in as non-controversial a way as I can manage. I will repeat some thoughts from my previous message, not to "pound a point", but to put all the thoughts together in one place for easy reading. I am not an advocate of the current export control laws in the US, nor of the CLIPPER proposals. However, it is reality that not all countries will accept the use of the same cryptographic algorithms either in their own countries or for export to other countries. While those attitudes are regrettable, they are also reality. Supporting multiple algorithms can make life under some of these irrational export and use rules easier. Some algorithms are subject to patent and licensing restrictions. Supporting multiple algorithms can make it possible for selected communities to choose not to pay license fees if they don't want to. I don't personally consider this a major problem, but some members of the Internet community get very upset at the thought of paying royalties on the RSA patent. Supporting multiple algorithms might make it easier to adopt RSA as the preferred algorithm, if those who don't wish to pay royalties have a way to avoid them. If DNS security is for one and only one DNS for one and only one true Internet, then one algorithm is sufficient. On the other hand, if the DNS protocols are to be useful in a broader environment where one community may wish to establish a second network that uses the same protocols but has only limited connections to the one true Internet, then there might be value for multiple algorithms. However, this is not a big issue, and if the DNS community has decided that this is not a feature of sufficient value (as your message indicates), then this benefit may be totally irrelevant to DNS. Cryptographic algorithms (other than one-time pads) do get broken periodically. Allowing for replacing an algorithm that proves too weak is a good thing. Allowing for replacing the replacement algorithm is also a good thing, because the replacement might also be broken. This implies that a single bit indicating old or new algorithm is not sufficient. Instead, some kind of algorithm version number is preferable. Finally, negotiating crypto algorithms adds overhead to a communications protocol. If we believe that the vast majority of users will in fact use a single algorithm that we don't expect to be broken any time soon, then algorithm negotiation should be designed to not add extra messages in the case of the default algorithm. This can be achieved by the client and server both assuming the default, unless one or the other sends a special message requesting something else. In conclusion, I hope my suggestions are useful to the DNS security WG. I am not an active participant in the WG, and I only wanted to offer what might be useful ideas. If they are not relevant or useful, then feel free to throw them away. If they are partially useful, then feel free to take those parts that are useful and ignore the rest. I am NOT trying to start a flame war or a major controversy! - Paul   Received: from sol.tis.com by magellan.TIS.COM id aa05028; 21 Apr 94 14:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17647; Thu, 21 Apr 94 14:12:19 EDT Received: by relay.tis.com; id AA21599; Thu, 21 Apr 94 14:13:26 EDT Message-Id: <9404211813.AA21599@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma021594; Thu Apr 21 14:13:13 1994 To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Thu, 21 Apr 94 10:46:22 -0400. <9404211446.AA17525@pkarger.tcc> Date: Thu, 21 Apr 94 14:11:13 -0400 From: Steve Kent Paul, I think your message does a good job of explaining your concerns for algorithm independence in the DNS context. There may be some others as well. Some organizations operate closed internets (with reused IP net numbers) and may employ closed DNS systems. Such organizations might wish to adopt a crypto-secure form of DNS, but might have reasons for using an algorithm other than the one widely used in the open Internet. It is not inconcievable that the DNS could be configured to support multiple algorithms, though at the cost of added management complexity and extra space. Multiple records carrying signatues and keys for use with different algorithms could be established. Given the DNS capability to add new record types, to configure multiple aliases, to introduce new domains for wholly new applications (e.g., the Internet fax facility), the addition of more records does not seem out of character. Some people have argued for the ability to accommodate multiple signature algorithms in certification systems and it is concievable to do this, though it raises the spectre of non-interoperability among portions of the system, e.g., should the signature algorithms used in some areas not be available to users in others. The same could be true here, e.g., non-interoperability across zone boundaries. The possibility of non-interoperability is certainly a concern. However, given a laize fare approach this proposal alreday embodies, enabling arbitrary cross-certification in the name hierarchy, it's not clear that accommodating multiple algorithms would be inconsistent with the overall flavor of the proposal. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05673; 21 Apr 94 15:26 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29373; Thu, 21 Apr 94 15:26:06 EDT Received: by relay.tis.com; id AA22508; Thu, 21 Apr 94 15:27:12 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma022500; Thu Apr 21 15:26:44 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA23491; Thu, 21 Apr 94 12:16:13 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA11256; Thu, 21 Apr 1994 15:17:54 -0400 Message-Id: <9404211917.AA11256@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: dee@lkg.dec.com, Charlie Kaufman Subject: no key flag and improved hash Changes Date: Thu, 21 Apr 94 15:17:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Unless there is substantial of opposition, we would like to make two additional changes in the next draft, one very simple and one more subtle: No key flag: The current draft says that an RSA RR with a modulus length of zero specifically asserts the absence of a key. This will be changed to a "no key" bit in the flag byte. Since the next version will have some sort of algorithm version field, it will in any case be necessary to look at the initial fixed part of the RDATA before looking at anything else in a key RR as, with some other algorithm, their might not be a "modulus length" field at all. Improved hash: The hash codes used inside signatures will be made stronger by having them change more often. This gives adversaries less time to find a false hash match by brute force. This will be accomplished by including the "self hash" field as part of the data hashed into all other hashes inside the signature. Since the self hash includes the date signed, all hashes will change with the frequency with which the zone is re-signed. Assuming their might otherwise have been hashes of RR sets that could have been unchanging for 10 years and that a zone is signed daily, this reduces the time an adversary has to find a false hash match by three and half orders of magnitude. (The attack being defended against is one where, for example, there is a set of MX RRs under a name which are signed by a hash inside the signature. If an adversary can find another set of MXs that hash to the same value and the have the adversary's host as the highest priority reachable MX destination and can substitute these RRs, along with the original genuine signature, in a DNS response, they can steal your mail.) 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)   Received: from sol.tis.com by magellan.TIS.COM id aa07188; 22 Apr 94 0:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26067; Thu, 21 Apr 94 23:58:22 EDT Received: by relay.tis.com; id AA26492; Thu, 21 Apr 94 23:59:30 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma026487; Thu Apr 21 23:58:46 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 12:52:18 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404220352.AA18149@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Robert Elz Date: Fri, 22 Apr 94 12:52:16 JST Cc: paul@vix.com, dns-security@tis.com In-Reply-To: <14973.766912821@munnari.OZ.AU>; from "Robert Elz" at Apr 21, 94 5:20 pm X-Mailer: ELM [version 2.3 PL11] > Given that, the recursive search has already been performed, and > the glue can be returned like any other cached answer. It > would slow the DNS system absurdly if we required that cached > answers never be used to reply to queries. > > Still, other additional information such as A for MX is a security hole, > I'm afraid. > > I'm not sure I believe that. Or, not any more than any other > non security aware DNS lookup is a security hole. If I trust > a DNS server enough to tell me the name of the host to which I > should send mail for some domain, then I think I will also trust > it enough to tell me the associated address. You can believe DNS servers provide correct information of the zone it serves. The problem is that a DNS server can put false information for other zones in the addtional section. foo.bar. MX 10 mail.foo.bar. MX 100 your.host. foo.bar A your.host A To make DNS as secure as IP, information in the additional section may be cached and copied to additional sections of other answers but should never be copied to the answer section, unless it belongs to the same domain to the answer. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09239; 22 Apr 94 9:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18267; Fri, 22 Apr 94 09:27:15 EDT Received: by relay.tis.com; id AA29832; Fri, 22 Apr 94 09:28:23 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma029821; Fri Apr 22 09:27:48 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16625; Fri, 22 Apr 94 06:20:34 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17466; Fri, 22 Apr 1994 09:22:17 -0400 Message-Id: <9404221322.AA17466@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Fri, 22 Apr 94 20:51:01 +0200." <9404221151.AA20068@necom830.cc.titech.ac.jp> Date: Fri, 22 Apr 94 09:22:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: Matt Crawford Cc: dns-security@tis.com, dee In-Reply-To: <9404201528.AA09926@munin.fnal.gov>; from "Matt Crawford" at Apr 20, 94 10:28 am >> Without a special name, all certificates would have to be stored at the >> top of a zone, and include information within the RDATA. > >It's too much inelegant. Such information should properly be included >in "named.boot" of BIND and should carefully maintained. To be really secure you need at least one key in the boot file of each host running secure DNS. The current proposal allows putting however may trusted keys you want there. But it seems to me that there would be cases where putting cross certification keys in a zone and maintaining them just in the zone master file would be easier than maintaining these keys in many boot files. This would not eliminate the need to have at least one key in every boot file. >Why, do you think, current DNS does not have list of name servers of >all the related zones at the top of a zone? Because it will create >a total chaos. > >What, do you think, will happen, when a key of some zone is changed? How >can a zone administrator know from which zones his zone is pointed by? > >What happens when a key of root or near root zone is changed to which >a lot of zones point? You do an excellent job of pointing out operational problems with keeping cross certification pointers up to date. It's much easier to avoid them and use the hierarchy if you can. However, being able to do such cross certification was specified as a requirement by the DNSSEC WG. Such cross certification is necessary to do secure resolution if any zones on the hierarchy path from where you start to the zone holding the node you are seeking are either insecure or all their servers are inaccessible to you. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa07650; 22 Apr 94 4:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00195; Fri, 22 Apr 94 03:50:31 EDT Received: by relay.tis.com; id AA27721; Fri, 22 Apr 94 03:51:39 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma027716; Fri Apr 22 03:51:33 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 16:44:19 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404220744.AA19145@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: "Donald E. Eastlake 3rd" Date: Fri, 22 Apr 94 16:44:17 JST Cc: pkarger@gte.com, dns-security@tis.com In-Reply-To: <9404200408.AA23362@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 20, 94 12:08 am X-Mailer: ELM [version 2.3 PL11] > >A one bit flag to define an algorithm change is not adequate. > >Just as for many other protocols, the right thing to do is to define > >an algorithm type field and a registry of algorithms and define a > >protocol negotiation over what algorithm is actually going to be used. > >I have no problem with defining a default algorithm, so that negotiation > >need not be done unless you actually want some other algorithm. > > WRONG! This is not IPSEC, where it is reasonable for different groups > to be able to communicate only disjointly. This is The Domain Name > Service. It is designed on the principles that all of the information > in it is public, that it gives the same answers to all who query it, > that there is one unified service. Having multiple authentication mechanism will make DNS a little more complex. As the mechanism would be cleanly modularized, it is not so complex. Moreover, even if authentication fails, raw data is still available. That all. > The DNS Security Working group, without a single objection, rejected > any ideas of access control or confidentiality. On the other hand, with your scheme with RSA which contains raw data, access restriction is possible by restricting the distribution of the public keys. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa11584; 22 Apr 94 11:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27362; Fri, 22 Apr 94 11:17:48 EDT Received: by relay.tis.com; id AA01512; Fri, 22 Apr 94 11:18:55 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma001501; Fri Apr 22 11:18:33 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBH0BIQ8IO001OI4@FNAL.FNAL.GOV>; Fri, 22 Apr 1994 10:17:44 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA14817; Fri, 22 Apr 94 10:17:00 CDT Date: Fri, 22 Apr 1994 10:17:00 -0500 From: Matt Crawford Subject: Re: DNS security draft In-Reply-To: Your message of Fri, 22 Apr 94 20:51:01 +0200. <9404221151.AA20068@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com Message-Id: <9404221517.AA14817@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > > Without a special name, all certificates would have to be stored at the > > top of a zone, and include information within the RDATA. > It's too much inelegant. Such information should properly be included > in "named.boot" of BIND and should carefully maintained. I don't see any difference in elegance. I see a difference in convenience, since I rarely touch named.boot. And named.boot does not now contain any RRs at all. Might you have meant the initial cache file? > What, do you think, will happen, when a key of some zone is changed? How > can a zone administrator know from which zones his zone is pointed by? He can't know. But he can do one of two things to ease the transition when he changes keys: Sign his zone with both the old and new keys or (better) Sign his new key with his old key. Thus zones primed with his old key can securely learn the new. > What happens when a key of root or near root zone is changed to which > a lot of zones point? Same as above, for a transitional period. DNS administrators will no doubt run a tool that looks for changes in keys for zones whose keys they have previously certified. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa12130; 22 Apr 94 12:08 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01399; Fri, 22 Apr 94 12:08:16 EDT Received: by relay.tis.com; id AA02162; Fri, 22 Apr 94 12:09:24 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma002157; Fri Apr 22 12:09:22 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBH23JS14W001PF4@FNAL.FNAL.GOV>; Fri, 22 Apr 1994 11:08:33 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA15071; Fri, 22 Apr 94 11:07:51 CDT Date: Fri, 22 Apr 1994 11:07:50 -0500 From: Matt Crawford Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of Fri, 22 Apr 94 21:44:55 +0200. <9404221245.AA20257@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com Message-Id: <9404221607.AA15071@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > If a list of all the names in a zone is available, authenticated NXDOMAIN > is easy. But it is unrealistic to extract such lengthy information. > > So, how is the following idea to make NXDOMAIN response authenticated? > > Have the following new RR type: XD (eXisting Domains) > > XD ... Why isn't the carried in a separate SIG RR, as for other RRs?   Received: from sol.tis.com by magellan.TIS.COM id aa08165; 22 Apr 94 8:03 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04659; Fri, 22 Apr 94 08:02:38 EDT Received: by relay.tis.com; id AA29084; Fri, 22 Apr 94 08:03:46 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma029048; Fri Apr 22 08:03:05 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 20:51:03 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404221151.AA20068@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Matt Crawford Date: Fri, 22 Apr 94 20:51:01 JST Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404201528.AA09926@munin.fnal.gov>; from "Matt Crawford" at Apr 20, 94 10:28 am X-Mailer: ELM [version 2.3 PL11] > Without a special name, all certificates would have to be stored at the > top of a zone, and include information within the RDATA. It's too much inelegant. Such information should properly be included in "named.boot" of BIND and should carefully maintained. Why, do you think, current DNS does not have list of name servers of all the related zones at the top of a zone? Because it will create a total chaos. What, do you think, will happen, when a key of some zone is changed? How can a zone administrator know from which zones his zone is pointed by? What happens when a key of root or near root zone is changed to which a lot of zones point? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08179; 22 Apr 94 8:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06025; Fri, 22 Apr 94 08:11:44 EDT Received: by relay.tis.com; id AA29147; Fri, 22 Apr 94 08:12:51 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma029139; Fri Apr 22 08:12:46 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 21:06:19 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404221206.AA20138@necom830.cc.titech.ac.jp> Subject: Re: no key flag and improved hash Changes To: "Donald E. Eastlake 3rd" Date: Fri, 22 Apr 94 21:06:18 JST Cc: dns-security@tis.com, dee@lkg.dec.com, kaufman@zk3.dec.com In-Reply-To: <9404211917.AA11256@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 21, 94 3:17 pm X-Mailer: ELM [version 2.3 PL11] > Unless there is substantial of opposition, we would like to make two > additional changes in the next draft, one very simple and one more > subtle: As I'm tired of correcting your misunderstandings, I would like to write another draft which is fanatically royal to the existing DNS architechture. As a result, it will be simpler than yours and proved to work in the real world environment. Any objections? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa13055; 22 Apr 94 15:08 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13339; Fri, 22 Apr 94 15:07:46 EDT Received: by relay.tis.com; id AA03706; Fri, 22 Apr 94 15:08:55 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma003697; Fri Apr 22 15:08:04 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBH8CA91JK001OX2@FNAL.FNAL.GOV>; Fri, 22 Apr 1994 14:07:24 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA15421; Fri, 22 Apr 94 14:06:42 CDT Date: Fri, 22 Apr 1994 14:06:42 -0500 From: Matt Crawford Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of Fri, 22 Apr 94 11:07:50 CDT. <9404221607.AA15071@munin.fnal.gov> To: Masataka Ohta Cc: dns-security@tis.com Message-Id: <9404221906.AA15421@munin.fnal.gov> Content-Transfer-Encoding: 7BIT (I should finish thinking before I send ...) > > Have the following new RR type: XD (eXisting Domains) > > > > XD ... > > Why isn't the carried in a separate SIG RR, as for other RRs? Also, you need the SIG record's "time signed", or something equivalent, to prevent replays. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa09074; 22 Apr 94 9:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11923; Fri, 22 Apr 94 08:49:59 EDT Received: by relay.tis.com; id AA29535; Fri, 22 Apr 94 08:51:06 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma029527; Fri Apr 22 08:50:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 21:44:57 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404221245.AA20257@necom830.cc.titech.ac.jp> Subject: Authenticated NXDOMAIN response To: dns-security@tis.com Date: Fri, 22 Apr 94 21:44:55 JST X-Mailer: ELM [version 2.3 PL11] If a list of all the names in a zone is available, authenticated NXDOMAIN is easy. But it is unrealistic to extract such lengthy information. So, how is the following idea to make NXDOMAIN response authenticated? Have the following new RR type: XD (eXisting Domains) XD ... where is the neggative cache period, , ... are all the domain names within the zone (including the toplevel name of child zones) which is located between and with some dictionary order. covers the data of the record (not all the XD records) signed by the zone's key. Then, to authenticate that some domain does not exist, an XD (not necessarily all the XDs) containing the queried domain between and should be added in the additional section. As there should be a lot of XD, the additional section should almost always be truncated, even if the query is by TCP. For example, if "com." zone contains only the following three domains beginning with "b": bar.com. bizzare.com. buzz.com. XD for them will be com. XD 3600 b.com. c.com. bar.com. bizzare.com. buzz.com. Then, a query for "best.com." will fail with authentication. To authenticate "foo.bar.com." does not exist, it is further necessary to confirm NS for "bar.com" does not exist. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa10449; 22 Apr 94 10:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22124; Fri, 22 Apr 94 10:00:37 EDT Received: by relay.tis.com; id AA00410; Fri, 22 Apr 94 10:01:45 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma000396; Fri Apr 22 10:00:57 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 22:54:50 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404221355.AA20519@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Fri, 22 Apr 94 22:54:48 JST Cc: dns-security@tis.com In-Reply-To: <9404221322.AA17466@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 22, 94 9:22 am X-Mailer: ELM [version 2.3 PL11] > >> Without a special name, all certificates would have to be stored at the > >> top of a zone, and include information within the RDATA. > > > >It's too much inelegant. Such information should properly be included > >in "named.boot" of BIND and should carefully maintained. > > To be really secure you need at least one key in the boot file of each > host running secure DNS. The current proposal allows putting however > may trusted keys you want there. But it seems to me that there would > be cases where putting cross certification keys in a zone and > maintaining them just in the zone master file would be easier than > maintaining these keys in many boot files. I don't mind someone develop a secure protocol to distribute boot files around all the related servers, OUTSIDE of the DNS protocol. If the protocol can somehow solve the serious operational issues I raised, it might be used by some of the people. If it can't, it won't be used widely. Doesn't it effectively satisfies the (rather bogus) cross certification requirement? > This would not eliminate > the need to have at least one key in every boot file. Boot file should contain as much keys as necessary. To make the scheme of secure DNS parallel to the existing one, all the name servers should know the public key of the root zone in "root.cache" file of BIND. Then, for each zone served by a name server as a secondary, the boot file should contain IP address(es) of other name server(s) of the zone and zone's public key. > Such cross certification is necessary to do secure > resolution if any zones on the hierarchy path from where you start to > the zone holding the node you are seeking are either insecure or all > their servers are inaccessible to you. No, it's not necessary. If you want to cover two disconnected zones, you should configure your name server boot file with public keys of both zones. That's all. You don't have to put them as DNS data with glue-like style, which does not work. So, put them in the boot file. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa12189; 22 Apr 94 12:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27016; Fri, 22 Apr 94 11:13:44 EDT Received: by relay.tis.com; id AA01469; Fri, 22 Apr 94 11:14:52 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma001463; Fri Apr 22 11:14:40 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Apr 94 00:08:33 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404221508.AA20758@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Masataka Ohta Date: Sat, 23 Apr 94 0:08:31 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9404221355.AA20519@necom830.cc.titech.ac.jp>; from "Masataka Ohta" at Apr 22, 94 10:54 pm X-Mailer: ELM [version 2.3 PL11] > > This would not eliminate > > the need to have at least one key in every boot file. > > Boot file should contain as much keys as necessary. > > To make the scheme of secure DNS parallel to the existing one, > all the name servers should know the public key of the root zone > in "root.cache" file of BIND. Then, for each zone served by a name > server as a secondary, the boot file should contain IP address(es) > of other name server(s) of the zone and zone's public key. A minor improvement. MD5 signature of the zone's public key is enough for boot files and for referral information. Masataka Ohta PS May we assume MD5 is unforgeable forever?   Received: from sol.tis.com by magellan.TIS.COM id aa22892; 23 Apr 94 2:16 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08136; Sat, 23 Apr 94 02:16:25 EDT Received: by relay.tis.com; id AA08048; Sat, 23 Apr 94 02:17:31 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008043; Sat Apr 23 02:16:39 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Apr 94 15:10:32 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404230610.AA22841@necom830.cc.titech.ac.jp> Subject: Re: Authenticated NXDOMAIN response To: Matt Crawford Date: Sat, 23 Apr 94 15:10:31 JST Cc: dns-security@tis.com In-Reply-To: <9404221607.AA15071@munin.fnal.gov>; from "Matt Crawford" at Apr 22, 94 11:07 am X-Mailer: ELM [version 2.3 PL11] > > If a list of all the names in a zone is available, authenticated NXDOMAIN > > is easy. But it is unrealistic to extract such lengthy information. > > > > So, how is the following idea to make NXDOMAIN response authenticated? > > > > Have the following new RR type: XD (eXisting Domains) > > > > XD ... > > Why isn't the carried in a separate SIG RR, as for other RRs? Because it is necessary that: covers the data of the record (not all the XD records) ^^^^^^^^^^^^^^^^^^^^^^ signed by the zone's key. > > If a list of all the names in a zone is available, authenticated NXDOMAIN > > is easy. But it is unrealistic to extract such lengthy information. As you pointed out, time signed (and some additional informaton, maybe) should also be signed. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa22928; 23 Apr 94 2:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08174; Sat, 23 Apr 94 02:22:25 EDT Received: by relay.tis.com; id AA08080; Sat, 23 Apr 94 02:23:33 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008069; Sat Apr 23 02:22:39 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Apr 94 15:16:30 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404230616.AA22876@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Matt Crawford Date: Sat, 23 Apr 94 15:16:28 JST Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404221517.AA14817@munin.fnal.gov>; from "Matt Crawford" at Apr 22, 94 10:17 am X-Mailer: ELM [version 2.3 PL11] > I don't see any difference in elegance. I see a difference in > convenience, since I rarely touch named.boot. It is a lot more convenient if you don't have to touch something so often, which is, in some sense, engineering elegance. > And named.boot does > not now contain any RRs at all. Might you have meant the initial > cache file? Named.boot doesn't and won't contain any RRs, of course. Named.boot does contain raw IP addresses of name servers and will contain raw MD5 signature of zone keys. > > What, do you think, will happen, when a key of some zone is changed? How > > can a zone administrator know from which zones his zone is pointed by? > > He can't know. But he can do one of two things to ease the > transition when he changes keys: > > Sign his zone with both the old and new keys > > or (better) > > Sign his new key with his old key. Thus zones primed with > his old key can securely learn the new. So, the remaining job is to develop automatic mechanism to propagate such a change. I'll be happy if you do so outside of DNS protocol. > > What happens when a key of root or near root zone is changed to which > > a lot of zones point? > > Same as above, for a transitional period. DNS administrators will no > doubt run a tool that looks for changes in keys for zones whose keys > they have previously certified. Fine. Put it boot files. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa28709; 25 Apr 94 2:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15194; Mon, 25 Apr 94 02:38:25 EDT Received: by relay.tis.com; id AA21680; Mon, 25 Apr 94 02:39:33 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma021675; Mon Apr 25 02:38:50 1994 Received: by gw.home.vix.com id AA05035; Sun, 24 Apr 94 23:38:10 -0700 Message-Id: <9404250638.AA05035@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Subject: here's something i just sent off to the big-internet and SIPP lists Date: Sun, 24 Apr 1994 23:38:09 -0700 From: Paul A Vixie ------- Forwarded Message Message-Id: <9404250618.AA04495@gw.home.vix.com> To: big-Internet@munnari.oz.au, sipp@sunroof2.Eng.Sun.COM Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 1994 22:32:43 PDT." <9404250532.AA20742@jurassic.Eng.Sun.COM> Date: Sun, 24 Apr 1994 23:18:58 -0700 From: Paul A Vixie I've been watching this discussion for a couple of days now, and I've been alarmed to see references to the RSA proposal on dns-security as if it were a given. That work is very much still ``in progress'' and should not form a part of the strata on which you folks base any IP++ ideas. Today, Bob Hinden made an oblique reference to something I've been thinking about in connection with DNS security, when he said: >I don't think we should delay deploying IPng based on this. I do think >that we should send a strong message to the security folks that the >Internet needs a key-management mechanism soon. We shouldn't delay the >IPng work, we should accelerate the security work. I likewise feel that a standard mechanism for key distribution has to come about before we start trying to implement lots of different protocols which depend on it. After all, when a protocol designer wants to _depend_on_ some cryptographic tool which itself depends on key distribution, and then at some point realizes, "oh, yeah, and we need key distribution if this is going to work," then the key distribution mechanism is likely to be (a) less robust than the protocol which happens to require it, (b) incompatible with other key distribution mechanisms, (c) not scalable or generalized enough so that other protocols can also use it, or (d) all three. I didn't come to this thought through quite the same means Bob Hinden did, though. My problem is that the DNS protocol is not extensible in the dimension dns-security is currently requiring it to bend and stretch, and I came up with an "it sure would be nice if..." when I realized that It Sure Would Be Nice If any given host "just knew" or had the means to determine whether it could (or had already) exchange(d) keys with any other given host. Of course, the protocol itself would probably have to look a lot like DNS, since it would have as its key some unique host identifier (not just a name or an address, given multi-homed hosts, but probably some kind of hash of all its names and addresses, with CNAME-ish links to that hash from each individual name or address) and as its data a list of tuples of the form: (algorithm, public key) With enough rending and tearing and gnashing, this could probably be made a new RR in the existing DNS. But I don't think that's a terribly good idea. Ideally it would be or become the basis for the next rev of the DNS, which is an idea whose time has long since come except that I don't think we have collectively enough cycles to take on this general a problem right now. But I have seen the chaos that can erupt when the same feature is needed by lots of different protocols or subsystems but never becomes a ``first class'' subsystem or protocol of its own. Consider the feature called "queuing" and examine for yourself the many suboptimal implementations of it in the various UNIX subsystems (sendmail, uucp, lpd, at, and so on.) I dread the day when there are two sets of encryption datum offered by each host: one for IP++, one for Secure DNS. And two protocols for this. And two probably-variant implementations, each with their own foibles. Say it isn't so, someone, please! This sounds to me like a task for another new working group. (Sorry!) ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa01807; 25 Apr 94 9:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27626; Mon, 25 Apr 94 09:37:52 EDT Received: by relay.tis.com; id AA24113; Mon, 25 Apr 94 09:39:05 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma024108; Mon Apr 25 09:38:45 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBL3OSS6TC00273X@FNAL.FNAL.GOV>; Mon, 25 Apr 1994 08:37:53 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA18747; Mon, 25 Apr 94 08:37:05 CDT Date: Mon, 25 Apr 1994 08:37:05 -0500 From: Matt Crawford Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of Sat, 23 Apr 94 15:10:31 +0200. <9404230610.AA22841@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com Message-Id: <9404251337.AA18747@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > > > Have the following new RR type: XD (eXisting Domains) > > > XD ... > > > > Why isn't the carried in a separate SIG RR, as for other RRs? > > Because it is necessary that: > covers the data of the record (not all the XD records) > signed by the zone's key. The off-line process that signs a zone could know that XD records must be signed individually. The Eastlake & Kaufman draft does have a zone file syntax for showing which RRs are covered by each SIG. (But it's really ugly!) _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa01826; 25 Apr 94 9:42 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27888; Mon, 25 Apr 94 09:41:57 EDT Received: by relay.tis.com; id AA24149; Mon, 25 Apr 94 09:43:10 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma024141; Mon Apr 25 09:42:49 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBL3TUH6BK00274P@FNAL.FNAL.GOV>; Mon, 25 Apr 1994 08:41:57 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA18763; Mon, 25 Apr 94 08:41:13 CDT Date: Mon, 25 Apr 1994 08:41:13 -0500 From: Matt Crawford Subject: Re: DNS security draft In-Reply-To: Your message of Sat, 23 Apr 94 15:16:28 +0200. <9404230616.AA22876@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com Message-Id: <9404251341.AA18763@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > Named.boot doesn't and won't contain any RRs, of course. > > Named.boot does contain raw IP addresses of name servers and will > contain raw MD5 signature of zone keys. Then how do the DNS *clients* securely get that information? They can be told the address of a server they should trust, but without transaction authentication, that server could be spoofed. I think you need a whole zone key in the resolv.conf file (or the equivalent of it). _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa01945; 25 Apr 94 10:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29694; Mon, 25 Apr 94 10:15:11 EDT Received: by relay.tis.com; id AA24550; Mon, 25 Apr 94 10:16:23 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma024544; Mon Apr 25 10:16:14 1994 Received: by atc.boeing.com (5.57) id AA10782; Mon, 25 Apr 94 07:10:48 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA05999; Mon, 25 Apr 94 07:10:28 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25621; Mon, 25 Apr 1994 07:08:41 -0700 Message-Id: <9404251408.AA25621@commanche.ca.boeing.com> To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Cc: paul@vix.com, dee@skidrow.lkg.dec.com, mohta@necom830.cc.titech.ac.jp Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Sun, 24 Apr 94 23:38:09 MST.) <9404250638.AA05035@gw.home.vix.com> Date: Mon, 25 Apr 94 07:08:40 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" I've also been quietly watching these discussions but with the momentum building to adapt RSA so globally I do have to respond. I happen to agree with Paul Vixie that designing a generic key distribution protocol is far superior to building in proprietary ones. I ask that you consider the following thoughts: 1) It was always my impression that standards were implemented to avoid incorporating proprietary technologies so that each implementor could take advantage of his/her best mix of public, proprietary, and licensed solutions. Building in fixed requirements of this type certainly defeats that. 2) To me it is still totally unclear that any corporation could use RSA technology within a their established business or production processes without licensing it. I think several armies of lawyers could be enlisted here without definitive answers. 3) As anyone who has had even a minimal experience with cryptography knows, what often times what seems to be the most totally invulnerable algorithm possible often falls to a trivial solution. Just consider for a moment the impact to the Internet, should a trivial solution for de-crypting RSA algorithms be found in a few years with the entire structure of world-wide communication security resting solely on it. I personally cannot imagine designing security mechanisms for global use that will rely on any single technology; the risks are simply to great. If nothing else, consider the incentives you offer to the dark side of humanity for succeeding in breaking that single technology; un-imagined wealth and power for the taking. Take care | Terry L. Davis,P.E.| Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | -------------- Monday April 25,1994 07:01 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa02718; 25 Apr 94 12:17 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08608; Mon, 25 Apr 94 12:17:18 EDT Received: by relay.tis.com; id AA25952; Mon, 25 Apr 94 12:18:30 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma025947; Mon Apr 25 12:18:26 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA11885; Mon, 25 Apr 94 12:16:34 EDT Date: Mon, 25 Apr 94 12:16:34 EDT From: Theodore Ts'o Message-Id: <9404251616.AA11885@tsx-11.MIT.EDU> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com, mohta@necom830.cc.titech.ac.jp In-Reply-To: Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA's message of Mon, 25 Apr 94 07:08:40 -0800, <9404251408.AA25621@commanche.ca.boeing.com> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 25 Apr 94 07:08:40 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" I've also been quietly watching these discussions but with the momentum building to adapt RSA so globally I do have to respond. I happen to agree with Paul Vixie that designing a generic key distribution protocol is far superior to building in proprietary ones. Generic protocols also mean "non-interoperable". I would have thought we would have learned to avoid the mistakes of OSI by now. Like it or not, whether or not we have an algorithm identifier field or not, in order for this thing to work, the IETF is going to have to put a stake in the ground and say that everyone is going to use this *one* cryptographic algorithm. It's the same problem as the one that's facing the IPNG decision process. Sometimes, you just have to pick one, and picking anything protocol is better than not picking a protocol at all. 1) It was always my impression that standards were implemented to avoid incorporating proprietary technologies so that each implementor could take advantage of his/her best mix of public, proprietary, and licensed solutions. Building in fixed requirements of this type certainly defeats that. It is certainly desierable to avoid incorporating proprietary technologies whenever possible. However, it is one thing to avoid trying to use propietary protocols; it is another thing to say we can not use a particular concept at all because it has been patented. After all, Ethernet is patented, and yet the fact that it has been patented has not stopped it from being widely deployed all over world, has it not? For all of the people who have been bitching and moaning --- if you don't like the current proposal, then come up with something new! Unfortunately, public key cryptography is a key technology, without which, many things in cryptography and security architecture become much harder. Don't get me wrong --- I think software patents and algorithm patents are particularily evil, and Congress should wake up and ban the Patent Office from issuing any more of them. But I also think we need to wake up and face reality. The Internet needs public key cryptography --- badly; and if making peace with RSADSI is what's required until the patent runs out in a few more years, then we should do what is necessary to do so. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa03308; 25 Apr 94 13:31 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14417; Mon, 25 Apr 94 13:31:14 EDT Received: by relay.tis.com; id AA27153; Mon, 25 Apr 94 13:32:25 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027137; Mon Apr 25 13:31:51 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12388; Mon, 25 Apr 94 10:13:08 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA13136; Mon, 25 Apr 1994 13:14:53 -0400 Message-Id: <9404251714.AA13136@skidrow.lkg.dec.com> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Mon, 25 Apr 94 07:08:40 -0800." <9404251408.AA25621@commanche.ca.boeing.com> Date: Mon, 25 Apr 94 13:14:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Terry, From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Cc: paul@vix.com, dee, mohta@necom830.cc.titech.ac.jp In-Reply-To: (Your message of Sun, 24 Apr 94 23:38:09 MST.) <9404250638.AA05035@gw.home.vix.com> > >... > >2) To me it is still totally unclear that any corporation could use RSA > technology within a their established business or production processes > without licensing it. I think several armies of lawyers could be > enlisted here without definitive answers. Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in Redwood City, California. (Or have your lawyer call their lawyer.) They will confirm that any company can use RSA internally, use PEM to communicate with other companies, etc., all in a profit making setting. The only thing RSA is still asking for royalties for is people who want to sell software incorporating RSA or sell a service where RSA is an essential part. >3) As anyone who has had even a minimal experience with cryptography > knows, what often times what seems to be the most totally invulnerable > algorithm possible often falls to a trivial solution. Just consider > for a moment the impact to the Internet, should a trivial solution for > de-crypting RSA algorithms be found in a few years with the entire > structure of world-wide communication security resting solely on it. Whatever algoritm is chosen, the people who want to interoperate will all have to speak it. Everyone knows you will need a method to roll over to a new algorithm when / if that is necessary. >I personally cannot imagine designing security mechanisms for global >use that will rely on any single technology; the risks are simply to >great. If nothing else, consider the incentives you offer to the dark >side of humanity for succeeding in breaking that single technology; >un-imagined wealth and power for the taking. So you want multiple algorithms so that those who want to interoperate will have to speak all of them so that if *any* *one* *of* *them* is broken, things will fall apart? Sounds like a great way to weaken network security to me. (Of course there should also be a way for consenting adults to use whatever algorithm they want, not that you could stop them anyway.) >Take care > > | Terry L. Davis,P.E.| Boeing Computer Services, Bellevue, WA | > | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | > | INTERNET EMAIL: tld5032@atc.boeing.com. | > -------------- Monday April 25,1994 07:01 AM PDT ------------- > > == As always, the above cannot be construed as representing BOEING, == > == the thoughts, comments, and ideas contained herein are mine alone! == Donald   Received: from sol.tis.com by magellan.TIS.COM id aa03369; 25 Apr 94 13:52 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA17273; Mon, 25 Apr 94 13:52:32 EDT Message-Id: <9404251752.AA17273@tis.com> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: RSA technology [Was: SIPP Routing ... & DNS Security] In-Reply-To: Your message of "Mon, 25 Apr 94 13:14:53 EDT." <9404251714.AA13136@skidrow.lkg.dec.com> Date: Mon, 25 Apr 94 13:52:24 -0400 From: Stephen D Crocker Donald, You wrote: > >2) To me it is still totally unclear that any corporation could use RSA > > technology within a their established business or production processes > > without licensing it. I think several armies of lawyers could be > > enlisted here without definitive answers. > > Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in > Redwood City, California. (Or have your lawyer call their lawyer.) > They will confirm that any company can use RSA internally, use PEM to > communicate with other companies, etc., all in a profit making > setting. The only thing RSA is still asking for royalties for is > people who want to sell software incorporating RSA or sell a service > where RSA is an essential part. I see three distinctions which are not evident in your advice. Here's my understanding, with the usual caveats about legal advice. a) There is RSA technology. If you write your own software and implement the RSA algorithms for key exchange or signature, I believe you're using RSA technology. This is patented technology, and I believe you have to deal with Public Key Partners for permission to make, use, etc. this technology. (Consult your own lawyer for details on fair use or other doctrine; I won't attempt to speak to that sort of thing.) b) RSA Data Security Inc. makes available a general purpose package, RSAREF, which implements the RSA technology. It comes with a specific license governing how it's to be used. Some forms of non-commercial use are permitted. c) There are specific application programs, including RIPEM/SIG from RSADSI and TIS/PEM from TIS, which have broad permission for use in non-sales contexts. These incorporate RSAREF, but may be usable without charge in some contexts not covered by the generic RSAREF license. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa04260; 25 Apr 94 16:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28601; Mon, 25 Apr 94 16:00:41 EDT Received: by relay.tis.com; id AA28882; Mon, 25 Apr 94 16:01:54 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma028875; Mon Apr 25 16:01:10 1994 Received: by ginger.lcs.mit.edu id AA28202; Mon, 25 Apr 94 16:00:11 -0400 Date: Mon, 25 Apr 94 16:00:11 -0400 From: Noel Chiappa Message-Id: <9404252000.AA28202@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu Generic protocols also mean "non-interoperable". ... Like it or not, whether or not we have an algorithm identifier field or not, in order for this thing to work, the IETF is going to have to put a stake in the ground and say that everyone is going to use this *one* cryptographic algorithm. I have no problem with picking one, as long as the hooks are there to use something else, as you desire. For a number of reasons (not wanting to intrude on patents, algorithmic expense, discovery of holes in algorithms) you might want to use something else. So, let's make sure to keep "algorithm identifier field"! It's the same problem as the one that's facing the IPNG decision process. Not quite. You and I may decide to use some private encryption algorithm, and nobody but us has to know. (I know, key distribution is a trickier case, since you may have to deal with many other sites, but...) The internetwork packet format, on the other hand, is *the* glue that holds it all together. Not just you and I, but all sites in between, have to use the same thing for us to communicate. Noel   Received: from sol.tis.com by magellan.TIS.COM id aa04616; 25 Apr 94 17:06 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03785; Mon, 25 Apr 94 17:06:26 EDT Received: by relay.tis.com; id AA29624; Mon, 25 Apr 94 17:07:40 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma029619; Mon Apr 25 17:06:52 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA15683; Mon, 25 Apr 94 17:04:50 EDT Date: Mon, 25 Apr 94 17:04:50 EDT From: Theodore Ts'o Message-Id: <9404252104.AA15683@tsx-11.MIT.EDU> To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 25 Apr 94 16:00:11 -0400, <9404252000.AA28202@ginger.lcs.mit.edu> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 25 Apr 94 16:00:11 -0400 From: Noel Chiappa Not quite. You and I may decide to use some private encryption algorithm, and nobody but us has to know. (I know, key distribution is a trickier case, since you may have to deal with many other sites, but...) The internetwork packet format, on the other hand, is *the* glue that holds it all together. Not just you and I, but all sites in between, have to use the same thing for us to communicate. What I am talking about is specifically key distribution, and signatures for the DNS. (The original complaints originally arose out of discussions from the DNS Security working group.) And, specifically within this context, I will claim that we do need to pick one protocol, because like the internetwork packet format, an internet-wide key distribution and certification system is *the* glue to hold any cryptographic security system all together. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa04705; 25 Apr 94 17:28 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05740; Mon, 25 Apr 94 17:28:35 EDT Received: by relay.tis.com; id AA29811; Mon, 25 Apr 94 17:29:48 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma029806; Mon Apr 25 17:29:17 1994 Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13909; Mon, 25 Apr 1994 17:28:34 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA23917; Mon, 25 Apr 1994 17:28:32 -0400 Message-Id: <9404252128.AA23917@abyss.zk3.dec.com> To: dns-security@tis.com Cc: kaufman@zk3.dec.com Subject: Re: DNS security draft Date: Mon, 25 Apr 94 17:28:31 -0400 From: kaufman@zk3.dec.com X-Mts: smtp The current proposal for DNS security is tightly tied to a particular set of cryptographic algorithms (RSA and MD5) and a particular way of using them. It is quite likely that someone will at some point want to secure DNS in some different way with some different cryptographic algorithms. (Digital's ULTRIX product, for example, already secures DNS with Kerberos). It would be desireable if the various DNS security schemes developed over time be sufficiently aware of one another that a single resolver could deal with the security mechanisms of different domains and (less likely) a domain could support multiple mechanisms for the benefit of different kinds of resolvers. This will generally be possible if the schemes pay minimal attention to one another or are lucky. (For example, the current proposal was developed without detailed knowledge of the existing ULTRIX implementation, but I believe the two could coexist comfortably). What would it mean to develop an "algorithm-independent" security protocol, as some have proposed? It might mean several things: 1) It could mean we specify cryptographic algorithms in a separate document from the one with elements that might be used with different algorithms (as the PEM standards have done). We could do that, but I believe there would be little benefit and a non-trivial cost in readability unless someone wants to invest in actually specifying a second set of algorithms. 2) It could mean we specify the crypto-algorithm independent aspects of the protocol first and defer design of the algorithm-specific parts. I think this would be a big mistake both because it would delay production of something useful (a complete stack) and in the absence of real-world constraints we could probably do a bad job on the algorithm independent parts. 3) It could mean we specify the crypto-algorithm independent aspects of the protocol only and let individual implementations go there own way on algorithm-specific parts since they (if they use public key cryptography) are proprietary due to patents. I think this would be a waste of time. People can do proprietary solutions without our help; if we can't specify enough to guarantee that compliant solutions interoperate, we might as well all go home. 4) It could mean we leave explicit hooks for future algorithms in the current design. For example, instead of RSA resource records, we could have PUBKEY resource records with an algorithm identifier at the beginning of the field. This would mean that to add - say - DSS keys, one would have to get a new value assigned for the algorithm identifier field instead of getting a new resource record field type assigned. I don't think it makes much difference in practice as to which is more expandable. The currently proposed way saves a few bytes. I will concede that perhaps the SIG record should be renamed the RSASIG record if it isn't going to have such an identifier. Could people who want "algorithm independence" say which of these they want and defend it? (or explain the fifth option I didn't think of). --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa04746; 25 Apr 94 17:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06394; Mon, 25 Apr 94 17:47:46 EDT Received: by relay.tis.com; id AA00121; Mon, 25 Apr 94 17:48:59 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma000107; Mon Apr 25 17:48:22 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA28600; Mon, 25 Apr 94 14:33:01 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA15352; Mon, 25 Apr 1994 17:34:46 -0400 Message-Id: <9404252134.AA15352@skidrow.lkg.dec.com> To: Matt Crawford Cc: dns-security@tis.com Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of "Mon, 25 Apr 94 08:37:05 CDT." <9404251337.AA18747@munin.fnal.gov> Date: Mon, 25 Apr 94 17:34:46 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Matt Crawford In-Reply-To: Your message of Sat, 23 Apr 94 15:10:31 +0200. <9404230610.AA22841@necom830.cc.titech. ac.jp> To: Masataka Ohta Cc: dns-security@tis.com Content-Transfer-Encoding: 7BIT >> > > Have the following new RR type: XD (eXisting Domains) >> > > XD ... >> > >> > Why isn't the carried in a separate SIG RR, as for other RRs? >> >> Because it is necessary that: >> covers the data of the record (not all the XD records) >> signed by the zone's key. > >The off-line process that signs a zone could know that XD records >must be signed individually. The Eastlake & Kaufman draft does have >a zone file syntax for showing which RRs are covered by each SIG. >(But it's really ugly!) If you have an idea for a less-ugly syntax, I'd like to see it. At least the zone maintainer should not have to see our proposed syntax much. It would be automatically added by the off-line signing process and would not have to be there in the basic master file. >_________________________________________________________ >Matt Crawford crawdad@fnal.gov Fermilab Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05168; 25 Apr 94 22:47 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13266; Mon, 25 Apr 94 22:47:35 EDT Received: by relay.tis.com; id AA01946; Mon, 25 Apr 94 22:48:49 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma001941; Mon Apr 25 22:48:07 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14090; Mon, 25 Apr 94 19:35:49 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17332; Mon, 25 Apr 1994 22:37:32 -0400 Message-Id: <9404260237.AA17332@skidrow.lkg.dec.com> To: Steve Kent Cc: dns-security@tis.com Subject: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) In-Reply-To: Your message of "Tue, 12 Apr 94 18:55:03 EDT." <9404122258.AA28259@relay.tis.com> Date: Mon, 25 Apr 94 22:37:32 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, From: Steve Kent To: Paul A Vixie Cc: dns-security@tis.com In-Reply-To: Your message of Tue, 12 Apr 94 15:22:30 -0700. <9404122222.AA23689@gw.home.vix.com> >Paul, > > Perhaps to the surprize of many, I agree with the general >thrust of your statement, i.e., that PEM may not be a good precedent >for adopting RSA for the DNS, but for different reasons. > >... > > For exmaple, ElGamal is an alternative signature algorithm >which is not itself patented, but which is embraced by the fundamental >Diffie-Hellman public key patent that expires in 1997 (I believe). >ElGamal is not very efficient, but it is an alternative that has a >shorter duration patent status relative to RSA. Looks to me like ElGamal would produce signatures that were twice as big and took at least a *hundred* and in some cases over a *thousand* times more computation effort to verify than profiled RSA. And it's not like RSA is all that cheap computationally. ElGamal is quite inferior in my mind. > The DSA, a variant of ElGamal, is covered by a much more >recent patent, making it less desirable, but NIST has been claiming >that it will arrange to make the DSA royalty free for everyone (at >least in the U.S.). The DSA is much more efficient than ElGamal, >though it is not very space efficient compared to RSA. Moreover, DSA >signatures are more expensive to verify than to generate (just >backwards for the DNS use), and they are slower than comparable RSA >signatures. However, on an absolute performance basis, DSA software >is getting better and its lower performance might be irrelevant in the >grand scheme of things. Most of the world is outside of the US. Besides its poor performance, would it really make sense to standardize for the Global DNS on something like DSA with patent royalties in much of the rest of the world until 2008+ ? And, as far as I know, there isn't a SchnorrREF letting you practice the Schnorr patent (which DSA allegedly infringes) even for non-commerical use. Doesn't it make more sense to adopt the technically superior algorithm which is completely unrestricted outside the US and will be effectively free for the vast majority of US users? Is saving just that small fraction of US users that will have to pay a small fee for a few years worth going with an obviously inferior algorithm? > The concern I did raise in the DNS Security WG meeting is that >the current proposal is tied unalterablty to RSA. The same is true of >the current PEM spec, but it is being revised to accommodate separate >algorithms for signature vs. encryption key management. To the extent >that folks have argued for this separation of public key functions in >PEM, and thus makeing PEM more algorithm independent, it seems a pity >to adopt a scheme for DNS security that is very much algorithm >dependent, even independent of patent issues. The structure of the current proposal is entirely algorithm independent. There are signature RRs and key RRs. Zones are signed by a zone key, preferably off line. Servers need not be trusted or security aware. There are some header bits so resolvers and servers can tell if the other is security aware and do what is most efficient if both are. What does this have to do with any particular algorithm? Then, if you use RSA, or anything else where you can pull the trick, you can put some data directly inside the signature when it optimizes things. > It is clear from the spec that Donald and George worked hard That's Donald and Charlie. >to deisgn a scheme that minimizes the extra space taken up by >signatures. That probably motivated the use of RSA, the only one of >the algorithms mentioned above that is "reversable" in terms of >signature data. > >... > >Steve Donald PS: Note: this mailing list may shortly be receiving messages from one or more persons who believe that the patent issue is more important than any other. They will advocate using that technology whose patent expires first regardless of technical merit and advcate delaying DNS SEC until it can be implemented entirely with unpatented technology. I believe that DNS SEC is needed strongly enough that it should be implemented with all deliberate speed and that, while patent lifetime is certainly a factor to consider, it is but one factor among many including, but not limited to, space efficiency, computational efficiency, and previous standards decisions.   Received: from sol.tis.com by magellan.TIS.COM id aa05196; 25 Apr 94 23:02 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13574; Mon, 25 Apr 94 23:01:43 EDT Received: by relay.tis.com; id AA02111; Mon, 25 Apr 94 23:02:57 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma002106; Mon Apr 25 23:02:36 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14674; Mon, 25 Apr 94 19:51:01 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17463; Mon, 25 Apr 1994 22:52:44 -0400 Message-Id: <9404260252.AA17463@skidrow.lkg.dec.com> To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 21 Apr 94 10:46:22 EDT." <9404211446.AA17525@pkarger.tcc> Date: Mon, 25 Apr 94 22:52:44 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul From: "Paul A. Karger" To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories In-Reply-To: Your message of "Wed, 20 Apr 94 00:08:17 EDT." <9404200408.AA23362@skidrow.lkg.dec.com> >I'm sorry that you found my suggestion of supporting multiple >crypto algorithms so controversial or that you thought I was >"pounding on a point". I was only trying to make what I thought was >a mild and non-controversial suggestion that mandating a particular >algorithm is not necessarily the best approach, even for a public >directory service, such as DNS. If my messages came across otherwise, >then I apologize for causing a problem. Sorry I over-reacted. If you want to argue for the support of multiple crypto algorithms, feel free to do so. However, I don't see the point of your arguing that RSA may be broken and I don't see the point of your arguing that the DNS security extensions should have some way of changing to another algorithm if RSA is broken when I explicitly agreed with you on both points and no one was disputing these points and in fact they were also brought up and accepted at the DNS SEC WG meeting in Seattle. These points are a far cry from simultaneous support for multiple algorithms, algorithm negotiation, etc. >... > >I am not an advocate of the current export control laws in the US, >nor of the CLIPPER proposals. However, it is reality that not all >countries will accept the use of the same cryptographic algorithms >either in their own countries or for export to other countries. While >those attitudes are regrettable, they are also reality. Supporting >multiple algorithms can make life under some of these irrational >export and use rules easier. First of all, I'm not aware on any country that restricts the algorithms you can use in the country. You may have to give a copy of your code and keys to the government, but there is no other restriction. When there are export restrictions, they normally restrict all but weak crypto. While I have no problem with weak crypto if that's all you can do and you have appropriate caveats, I can't see any reason for the IETF to standardize on weak crypto for secure DNS. I just can't see any problem in any Internet connected country using strong crypto by writing it or getting it from a country without export restrictions of for free from one of the countries where export restrictions apply only to sales. >Some algorithms are subject to patent and licensing restrictions. >Supporting multiple algorithms can make it possible for selected >communities to choose not to pay license fees if they don't want to. >I don't personally consider this a major problem, but some members >of the Internet community get very upset at the thought of paying >royalties on the RSA patent. Supporting multiple algorithms might >make it easier to adopt RSA as the preferred algorithm, if those >who don't wish to pay royalties have a way to avoid them. The DNS is a global distributed database system. I really can't see all the open servers out there supporting N different signatures on everything. I suppose some compact community might want to use some different algorithm inside a firewall and have all their border DNS systems know both, or something like that. Such set ups tend to have all kinds of problems. And, unless they work with unpaid volunteers, its going to cost them a lot more to set this up and keep things straight in term of labor than anything they are going to save in royalties for the few years they still apply to some limited uses in the US only. > >... > >Cryptographic algorithms (other than one-time pads) do >get broken periodically. Allowing for replacing an algorithm that >proves too weak is a good thing. Here you are assering the same two things yet again. Guess I'll agree with it for the third time. > Allowing for replacing the replacement >algorithm is also a good thing, because the replacement might also >be broken. This implies that a single bit indicating old or new >algorithm is not sufficient. Instead, some kind of algorithm >version number is preferable. If one really thought that the probability was low enough of the algorithm being broken, then one escape bit would be fine. If that bit was ever turned on, then it could indicate the existence of a protocol version field or whatever. But there are enough fee bits to add such a field now, anyway, and I plan to do so. >Finally, negotiating crypto algorithms adds overhead to a communications >protocol. If we believe that the vast majority of users will in fact >use a single algorithm that we don't expect to be broken any time soon, >then algorithm negotiation should be designed to not add extra messages >in the case of the default algorithm. This can be achieved by the >client and server both assuming the default, unless one or the other >sends a special message requesting something else. It turns out to be extremely painful, if it is possible at all, to flag this sort of thing due to the contraints of the DNS protocol and the existing implementations. >... > > - Paul Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05312; 26 Apr 94 0:16 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14812; Tue, 26 Apr 94 00:16:06 EDT Received: by relay.tis.com; id AA02533; Tue, 26 Apr 94 00:17:16 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma002520; Tue Apr 26 00:15:17 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 13:08:34 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404260408.AA03998@necom830.cc.titech.ac.jp> Subject: Re: Authenticated NXDOMAIN response To: Matt Crawford Date: Tue, 26 Apr 94 13:08:32 JST Cc: dns-security@tis.com In-Reply-To: <9404251337.AA18747@munin.fnal.gov>; from "Matt Crawford" at Apr 25, 94 8:37 am X-Mailer: ELM [version 2.3 PL11] > The off-line process that signs a zone could know that XD records > must be signed individually. Yes. > The Eastlake & Kaufman draft does have > a zone file syntax for showing which RRs are covered by each SIG. That's for the authentication of NXRR, not NXDOMAIN. The Eastlake & Kaufman draft suggests to authenticate NXDOMAIN with hosts, not zone, key. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa07829; 26 Apr 94 8:47 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25479; Tue, 26 Apr 94 08:47:22 EDT Received: by relay.tis.com; id AA06125; Tue, 26 Apr 94 08:48:36 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma006116; Tue Apr 26 08:48:29 1994 Received: by ginger.lcs.mit.edu id AA02870; Tue, 26 Apr 94 08:47:42 -0400 Date: Tue, 26 Apr 94 08:47:42 -0400 From: Noel Chiappa Message-Id: <9404261247.AA02870@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: dns-security@tis.com, jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com >> Generic protocols also mean "non-interoperable". ... Like it or not, >> ... in order for this thing to work, the IETF is going to have to put a >> stake in the ground and say that everyone is going to use this *one* >> cryptographic algorithm. > I have no problem with picking one, as long as the hooks are there to use > something else ... let's make sure to keep "algorithm identifier field"! > ... You and I may decide to use some private encryption algorithm, and > nobody but us has to know. What I am talking about is specifically key distribution, and signatures for the DNS. ... And, specifically within this context, I will claim that we do need to pick one protocol, because like the internetwork packet format, an internet-wide key distribution and certification system is *the* glue to hold any cryptographic security system all together. Whoa. We just went from "one algorithm" (in your first clip) to "one protocol". I don't believe they are the same; the "algorithm identifier field" (along with key length, etc) would allow use of several signing algorithms within one protocol. Did I miss something? I agree that we need one protocol to do key distribution, and that is a pretty fundamental piece of glue (let's not argue about exactly *how* fundamental). However, I stick with my original claim that we should allow various algorithms. Sure, we should have one (or more, for export/patent/whatever reasons) base algorithm, so that all entries are signed in at least one way which everyone can verify. I don't see any reason not to allow pairwise use of other algorithms, though. If (as seems unlikely, but I admit it's possible) someone discovers a hole in the base algorithm, this would allow a (less painful) incremental, and interoperable, switch to a new algorithm. Noel   Received: from sol.tis.com by magellan.TIS.COM id aa08572; 26 Apr 94 9:40 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27965; Tue, 26 Apr 94 09:39:52 EDT Received: by relay.tis.com; id AA06750; Tue, 26 Apr 94 09:41:06 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma006742; Tue Apr 26 09:40:43 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA19694; Tue, 26 Apr 1994 09:34:21 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA05506; Tue, 26 Apr 94 09:27:55 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA28488; Tue, 26 Apr 94 09:31:34 EDT Message-Id: <9404261331.AA28488@pkarger.tcc> To: kaufman@zk3.dec.com Cc: dns-security@tis.com, pak0@gte.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: DNS security draft In-Reply-To: Your message of "Mon, 25 Apr 94 17:28:31 EDT." <9404252128.AA23917@abyss.zk3.dec.com> Date: Tue, 26 Apr 94 09:31:33 -0400 From: "Paul A. Karger" Charlie: My primary concern in advocating multiple algorithms is to handle the case when either RSA or MD5 or their successors get broken. There should be a graceful way to quickly and universally communicate the need to switch to a new algorithm and hopefully not affect user application binaries in any way. That is, the system managers should be able to install the new algorithms without asking users to change anything. Since not all system managers will upgrade at the same time, there will need to be some negotiation to continue to support the old algorithms during the changeover. However, since the old algorithms are being replaced due to security problems, there ought to be a way to warn the system managers and users of the need to upgrade. Given the need to support both old and new algorithms, and the need to potentially replace the new algorithms with still newer algorithms (if the replacements get broken), then there is a need to allow clients and servers to negotiate their choice of crypto algorithms. Given the need for negotiation, there is the possibility of supporting multiple algorithms for other reasons. I can think of two reasons (other than an algorithm being broken) that multiple algorithms might be wanted. 1) license restrictions There has certainly been a lot of heat over the choice of RSA, because some people object to paying royalties on the patents. While I don't personally object to paying royalties, support of multiple algorithms could allow those who do object to use something else at the expense of interoperability. 2) doctrinal requirements There are some potential users of DNS who may require use of their own algorithms for doctrinal reasons. For example, the DoD might wish to use NSA-supplied algorithms when classified material is involved. Other countries (eg: France) may have their own special requirements. My personal belief is that the license and doctrinal requirements are secondary to the recovery from a crypto break. If DNS only supported recovery from a crypto break, I would be happy. The others are merely "nice to haves" in my personal opinion. To respond to your specific questions: >What would it mean to develop an "algorithm-independent" security >protocol, as some have proposed? It might mean several things: > >1) It could mean we specify cryptographic algorithms in a separate >document from the one with elements that might be used with different >algorithms (as the PEM standards have done). We could do that, but I >believe there would be little benefit and a non-trivial cost in >readability unless someone wants to invest in actually specifying a >second set of algorithms. I don't see a need to this. RSA and MD5 would be the algorithms of choice. >2) It could mean we specify the crypto-algorithm independent aspects >of the protocol first and defer design of the algorithm-specific >parts. I think this would be a big mistake both because it would >delay production of something useful (a complete stack) and in the >absence of real-world constraints we could probably do a bad job on >the algorithm independent parts. I agree with you that this would be a bad idea, too. >3) It could mean we specify the crypto-algorithm independent aspects >of the protocol only and let individual implementations go there own >way on algorithm-specific parts since they (if they use public key >cryptography) are proprietary due to patents. I think this would be >a waste of time. People can do proprietary solutions without our >help; if we can't specify enough to guarantee that compliant solutions >interoperate, we might as well all go home. This is also a bad idea, as you point out. >4) It could mean we leave explicit hooks for future algorithms in the >current design. For example, instead of RSA resource records, we >could have PUBKEY resource records with an algorithm identifier at the >beginning of the field. This would mean that to add - say - DSS keys, >one would have to get a new value assigned for the algorithm >identifier field instead of getting a new resource record field type >assigned. I don't think it makes much difference in practice as to >which is more expandable. The currently proposed way saves a few >bytes. I will concede that perhaps the SIG record should be renamed >the RSASIG record if it isn't going to have such an identifier. This is precisely what I mean. There need to be explicit hooks for future algorithms. This probably means a registry of algorithms so that they can be assigned numbers and a way to negotiate which one is in use. The negotiation protocol should be implemented on the assumption that the overwhelming majority of uses will use the standard default algorithm, and that the standard default will change infrequently. Ideally, if you are using the standard default algorithm, there should be zero overhead for negotiation. Only if you use a non-standard algorithm, should you pay a performance penalty. The standard default should have a way of changing for the case of an algorithm break, but that should be a VERY rare event. I guess I should add that these are my personal opinions and do not represent the official opinion of GTE Laboratories, Inc.   Received: from sol.tis.com by magellan.TIS.COM id aa05810; 26 Apr 94 4:16 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18797; Tue, 26 Apr 94 04:16:23 EDT Received: by relay.tis.com; id AA04115; Tue, 26 Apr 94 04:17:37 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma004110; Tue Apr 26 04:16:52 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 17:10:45 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404260811.AA05591@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Matt Crawford Date: Tue, 26 Apr 94 17:10:42 JST Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404251341.AA18763@munin.fnal.gov>; from "Matt Crawford" at Apr 25, 94 8:41 am X-Mailer: ELM [version 2.3 PL11] > > Named.boot doesn't and won't contain any RRs, of course. > > > > Named.boot does contain raw IP addresses of name servers and will > > contain raw MD5 signature of zone keys. > > Then how do the DNS *clients* securely get that information? You should distinguish name servers and resolvers. Resolvers are tied to other resolvers or name servers, not to specific zones. So, the proper security for resolvers fanatically royal to the existing DNS architecture is authentication of hosts, not zones. It is OK to have zone keys for name servers especially because making NXDOMAIN response authenticated is now possible. Moreover, considering the proposed load balancing mechanism and its possible applicability for other problems, absence of primary server and, thus, its key is rather desirable. But, it is not necessary that resolvers know zone keys. > They > can be told the address of a server they should trust, but without > transaction authentication, that server could be spoofed. Correct. Anyway, if a host running an application is compromised, the application is compromised. Just like it, it is not so bad that if a host running a name server for an application is compromised, the application referring the name server is compromised. System administrators should protect name server or he may run extra name servers on hosts which needs a little more authentication. > I think you need a whole zone key in the resolv.conf file (or the > equivalent of it). Resolv.conf should have whole host keys or their MD5. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa05994; 26 Apr 94 5:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19349; Tue, 26 Apr 94 05:04:41 EDT Received: by relay.tis.com; id AA04475; Tue, 26 Apr 94 05:05:56 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma004467; Tue Apr 26 05:05:50 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 17:57:24 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404260857.AA06015@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: Theodore Ts'o Date: Tue, 26 Apr 94 17:57:23 JST Cc: "Terry, L., Davis, P.E., Boeing, Computer, Services, Bellevue, WA"@necom830.cc.titech.ac.jp, tld5032@commanche.ca.boeing.com, dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404251616.AA11885@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 25, 94 12:16 pm X-Mailer: ELM [version 2.3 PL11] > Don't get me wrong --- I think software patents and algorithm patents > are particularily evil, and Congress should wake up and ban the Patent > Office from issuing any more of them. From a purely political point of view, the better approach is to try to bankrupt RSA DSI by not paying to them. > But I also think we need to wake > up and face reality. The Internet needs public key cryptography --- > badly; and if making peace with RSADSI is what's required until the > patent runs out in a few more years, then we should do what is necessary > to do so. What's wrong with ElGamal? > Unfortunately, public key cryptography is a key technology, without > which, many things in cryptography and security architecture become > much harder. Public key makes management issue of secret data much easier. Other things won't be affected by it. Modularized secure DNS which enables both RSA, shared secret and KDC is easy to construct. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09664; 26 Apr 94 13:37 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13530; Tue, 26 Apr 94 13:37:09 EDT Received: by relay.tis.com; id AA09447; Tue, 26 Apr 94 13:38:23 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma009440; Tue Apr 26 13:38:07 1994 Received: by gw.home.vix.com id AA00453; Tue, 26 Apr 94 09:36:11 -0700 Date: Tue, 26 Apr 94 09:36:11 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) Organization: Vixie Enterprises Message-Id: References: <9404260237.AA17332@skidrow.lkg.dec.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: dee@skidrow.lkg.dec.com's message of 25 Apr 1994 20:24:00 -0700 just a short followup to donald's message: >Doesn't it make more sense to adopt the technically superior algorithm >which is completely unrestricted outside the US and will be >effectively free for the vast majority of US users? Is saving just >that small fraction of US users that will have to pay a small fee for >a few years worth going with an obviously inferior algorithm? i think RSA's license existing terms are exceptionally generous, and i also think that they deserve to be compensated for their efforts in creating the technology. i also think that the RSA technology is vastly superior to any alternative i know of. so i certainly won't debate you or anyone on any of those points. what concerns me is that when the IAB approves a protocol, it is actually more or less "legislating" its use. legislating the use of patented technology is, no matter how good the technology or how generous the terms, still a pretty dicey business. even if they are only paid a small amount per system sold with RSAREF-linked BIND, and a small amount by each network service provider who uses an RSAREF-linked BIND to sell name service to customers, that's still going to be a fair amount of money going to RSA. even if it were a token amount, we have to think long and hard about essentially _requiring_ that any real-world DNS user in the post-security world pay, directly or indirectly, royalties to some central authority. this is the first instance i know of where we're talking about requiring royalties at this level. and let me be clear as to what i mean by "requiring" the royalties; i'll use ethernet as a comparison. the RFC that describes the format of IP frames when encapsulated in Ethernet frames says _nothing_ about local area networks in general. if someone wanted to use IP on LANs and did not want to pay for Ethernet's royalties, they could choose some other LAN technology and just put their IP frames on _that_. the Ethernet/IP RFC says "if you want to use Ethernet, here's how you do it". the Secure DNS RFC will say "if you want to use Secure DNS, you MUST use RSA, you MUST pay for it, and by the way, here's how you do it." even PEM, which is perhaps a more similar case since it already involves RSA, is merely "if you want to do Secure Mail, ONE WAY TO DO IT is with PEM, which you must pay for, etc." the fact that "the vast majority of IP users" won't have to pay helps but it does not change the fundamental nature of the equation. this isn't deadly, it just requires some extra consideration. i'm on the hook for some action in this area and i should probably be working on _that_ rather than posting here. but i wanted to follow up on donald's point, however briefly. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa06140; 26 Apr 94 6:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20291; Tue, 26 Apr 94 06:12:08 EDT Received: by relay.tis.com; id AA04853; Tue, 26 Apr 94 06:13:23 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma004848; Tue Apr 26 06:12:44 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 19:05:20 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404261005.AA06287@necom830.cc.titech.ac.jp> Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) To: "Donald E. Eastlake 3rd" Date: Tue, 26 Apr 94 19:05:18 JST Cc: kent@bbn.com, dns-security@tis.com In-Reply-To: <9404260237.AA17332@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 25, 94 10:37 pm X-Mailer: ELM [version 2.3 PL11] > > Perhaps to the surprize of many, I agree with the general > >thrust of your statement, i.e., that PEM may not be a good precedent > >for adopting RSA for the DNS, but for different reasons. > > > >... > > > > For exmaple, ElGamal is an alternative signature algorithm > >which is not itself patented, but which is embraced by the fundamental > >Diffie-Hellman public key patent that expires in 1997 (I believe). > >ElGamal is not very efficient, but it is an alternative that has a > >shorter duration patent status relative to RSA. > > Looks to me like ElGamal would produce signatures that were twice as > big Wrong. Agaist the simple enumeration attack, ElGamal with a 512 bit prime which requires a 1024 bit signature is just as secure as RSA with two 512 bit primes which also requires a 1024 bit signature. So, it is generally believed (actual proof is as difficult as proving both RSA and Elgamal are broken, of course) that, for authentication, where signature on 128 bit MD5 is considered to be enough, ElGamal signature is as compact as that of RSA. The difference is that, to encrypt 512 bit of data, ElGamal needs 1024 bits, while RSA needs 512 bits only. That is, RSA is twice more compact than ElGamal for confidentiality. > and took at least a *hundred* and in some cases over a *thousand* > times more computation effort to verify than profiled RSA. That's true. But, in the security conscious enviroment where secure DNS is required, we need to compute a lot of on-line signature outside of DNS. Generation of RSA signature is almost as slow as generation of signature and verification of ElGamal. So, if ElGamal is unusably slow, RSA is also unusable, isn't it? Fortunately, the working set of the computation is quite small and completely included in on-chip cache. That is, signature computation speed is assured to become faster and faster as CPU speed increases. > > The DSA, a variant of ElGamal, is covered by a much more > Most of the world is outside of the US. Besides its poor performance, > would it really make sense to standardize for the Global DNS on > something like DSA with patent royalties in much of the rest of the > world until 2008+ ? I know nothing about DSA, but are there any reason to use it? It seems to me that ElGamal is good enough. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa14245; 26 Apr 94 16:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27633; Tue, 26 Apr 94 16:14:36 EDT Received: by relay.tis.com; id AA11289; Tue, 26 Apr 94 16:15:49 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma011280; Tue Apr 26 16:15:15 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA00717; Tue, 26 Apr 94 16:14:25 EDT Date: Tue, 26 Apr 94 16:14:25 EDT From: Theodore Ts'o Message-Id: <9404262014.AA00717@tsx-11.MIT.EDU> To: Paul A Vixie Cc: dns-security@tis.com In-Reply-To: Paul A Vixie's message of Tue, 26 Apr 94 09:36:11 -0700, Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Tue, 26 Apr 94 09:36:11 -0700 From: Paul A Vixie not want to pay for Ethernet's royalties, they could choose some other LAN technology and just put their IP frames on _that_. the Ethernet/IP RFC says "if you want to use Ethernet, here's how you do it". the Secure DNS RFC will say "if you want to use Secure DNS, you MUST use RSA, you MUST pay for it, and by the way, here's how you do it." You seem to be making the assumption that everyone will be forced to use Secure DNS. Let's project out 5 years. Clients that don't use secure DNS will still be able to do name resolution, although their requests might not be secure. At some point, it might be the case that authoritative name servers won't be trusted unless they're running Secure DNS. But this is a much smaller problem, since you generally need to be some sort of wizard to run a authoratative name server anyway, and often the network provider runs the authoratative nameserver for most of its smaller sites anyway. And, of course, any site who can pull RSAREF will be able to compile their own Secure DNS server for their authoratative name server. Also, RSA has in the past granted free use of its patent for the purposes of verifying signatures. If we can get a similar deal, then we'd be all set for the workstation market. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa14286; 26 Apr 94 16:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29894; Tue, 26 Apr 94 16:26:40 EDT Received: by relay.tis.com; id AA11436; Tue, 26 Apr 94 16:27:55 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma011429; Tue Apr 26 16:27:31 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA00886; Tue, 26 Apr 94 16:25:38 EDT Date: Tue, 26 Apr 94 16:25:38 EDT From: Theodore Ts'o Message-Id: <9404262025.AA00886@tsx-11.MIT.EDU> To: Masataka Ohta Cc: "Terry, L., Davis, P.E., Boeing, Computer, Services, Bellevue,\ WA"@necom830.cc.titech.ac.jp, tld5032@commanche.ca.boeing.com, dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com In-Reply-To: Masataka Ohta's message of Tue, 26 Apr 94 17:57:23 JST, <9404260857.AA06015@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Tue, 26 Apr 94 17:57:23 JST What's wrong with ElGamal? 1) It doesn't provide support for data hiding. RSA does. While this is not required for DNS per se, having support for encryption would allow us to leverage the DNS key hierarchy for many other things, including IP security. With RSA, the keys that are used for secure DNS can also be used to establish secure data exchange keys for encryption purposes. El Gamal does not provide this capability. 2) El Gamal is also subject to U.S. patents: From the "Answers to FREQUENTLY ASKED QUESTIONS About Today's Cryptography", published by RSA Data Security: In a recent case, for example, PKP brought suit against the TRW Corporation which was using public-key cryptography (the ElGamal system) without a license; TRW claimed it did not need to license. In June 1992 a settlement was reached in which TRW agreed to license to the patents. Either way, vendors will have to fork some amount of money over to RSA DSI. Public key makes management issue of secret data much easier. Other things won't be affected by it. Modularized secure DNS which enables both RSA, shared secret and KDC is easy to construct. It may be easy to construct; a shared secret system (like Kerberos) simply can't be maintained or administered at large scales, however. KDC's are primarily good for a single site, or a few sites. They don't work over the entire Internet, and that's the problem that we're trying to solve. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa14324; 26 Apr 94 16:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02247; Tue, 26 Apr 94 16:49:48 EDT Received: by relay.tis.com; id AA11737; Tue, 26 Apr 94 16:51:03 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma011729; Tue Apr 26 16:50:37 1994 Received: by gw.home.vix.com id AA06227; Tue, 26 Apr 94 13:49:54 -0700 Message-Id: <9404262049.AA06227@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Reply-To: paul@vix.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 26 Apr 1994 16:25:38 EDT." <9404262025.AA00886@tsx-11.MIT.EDU> Date: Tue, 26 Apr 1994 13:49:53 -0700 From: Paul A Vixie I have several requests. First, if you reply to a message on the list, edit the reply headers to remove all the individuals who are themselves probably on the list. Wide-area dupli- cate suppression doesn't work, and I don't like getting N+1 copies of each msg which is a distant descendent of some thread I've participated in. Second, please think very carefully about sending any message to more than one list. There is a huge overlap in the memberships, and charters, of SIPP, BigInternet, and dns-security. Sending to one and only one of these lists is probably enough for most topics. I'm making an exception for this message since it's meta-topical rather than topical. Third, well, #3 is topical so I'll make it into a separate message.   Received: from sol.tis.com by magellan.TIS.COM id aa14364; 26 Apr 94 17:09 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04227; Tue, 26 Apr 94 17:08:56 EDT Received: by relay.tis.com; id AA12053; Tue, 26 Apr 94 17:10:11 EDT Received: from adrastea.lcs.mit.edu(18.26.0.159) by relay via smap (V1.3mjr) id sma012043; Tue Apr 26 17:09:16 1994 Received: by adrastea.lcs.mit.edu; id AA23432; Tue, 26 Apr 1994 17:07:59 -0400 Date: Tue, 26 Apr 1994 17:07:59 -0400 From: Garrett Wollman Message-Id: <9404262107.AA23432@adrastea.lcs.mit.edu> To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Reply-To: wollman@lcs.mit.edu Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: <9404262025.AA00886@tsx-11.MIT.EDU> References: <9404260857.AA06015@necom830.cc.titech.ac.jp> <9404262025.AA00886@tsx-11.MIT.EDU> < Return-Path: Message-Id: <9404270328.AA09765@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: dns-security@tis.com, big-internet@munnari.oz.au Date: Wed, 27 Apr 94 12:28:35 JST In-Reply-To: <9404262025.AA00886@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 26, 94 4:25 pm X-Mailer: ELM [version 2.3 PL11] > What's wrong with ElGamal? > > 1) It doesn't provide support for data hiding. It does, though the algorithms for confidentiality and for authentication are different. > With RSA, the keys that are used for secure DNS can also be used to > establish secure data exchange keys for encryption purposes. Wrong. For encryption purposes, you need keys for hosts or users. Secure DNS is now being deeveloped so that a zone, not a host in general, will have a key. > El Gamal does not provide this capability. It does. Two ElGamal algorithms for confidentiality and for authentication share the same public key. > 2) El Gamal is also subject to U.S. patents: I know. But it will expire 1997, much earlier than 2000. > Public key makes management issue of secret data much easier. Other > things won't be affected by it. Modularized secure DNS which enables > both RSA, shared secret and KDC is easy to construct. > > It may be easy to construct; a shared secret system (like Kerberos) > simply can't be maintained or administered at large scales, however. > KDC's are primarily good for a single site, or a few sites. They don't > work over the entire Internet, and that's the problem that we're trying > to solve. I merely pointed out that we can construct modularized secure DNS without technical difficulty. I'm not particulary in favour of the idea to use KDC or something like that till 1997 and ElGamal later. But, when any public key mechanism is proven to be broken, as some of the people are afraid of, KDC with conventional security model or something like that could be a refuge till a new algorithm prevails. If any public key mechanism is proven to be broken, we are valunerable till alternative secure algorithm is developpeed and installed within a name server, which will take a considerable amount of time, much longer than rewriting secure DNS RFC with a new algorithm. So, unless alternate secure algorithm is installed in name servers IN ADVANCE, algorithm independence is not meaningful. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa16163; 27 Apr 94 8:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23637; Wed, 27 Apr 94 08:01:24 EDT Received: by relay.tis.com; id AA17106; Wed, 27 Apr 94 08:02:40 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma017101; Wed Apr 27 08:02:25 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA07199; Wed, 27 Apr 1994 14:06:07 +0200 Message-Id: <199404271206.AA07199@mitsou.inria.fr> To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 26 Apr 1994 16:25:38 EDT." <9404262025.AA00886@tsx-11.MIT.EDU> Date: Wed, 27 Apr 1994 14:06:06 +0200 From: Christian Huitema => From: Masataka Ohta => Date: Tue, 26 Apr 94 17:57:23 JST => => What's wrong with ElGamal? => => 1) It doesn't provide support for data hiding. RSA does. While this => is not required for DNS per se, having support for encryption would => allow us to leverage the DNS key hierarchy for many other things, => including IP security. Uh? El Gamal's public key is 1/2 of Diffie Hellmann, does indeed provide for encryption... Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa17099; 27 Apr 94 10:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29631; Wed, 27 Apr 94 10:32:16 EDT Received: by relay.tis.com; id AA18234; Wed, 27 Apr 94 10:33:33 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma018229; Wed Apr 27 10:32:42 1994 Received: by atc.boeing.com (5.57) id AA05808; Wed, 27 Apr 94 07:33:18 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA07161; Wed, 27 Apr 94 07:33:03 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25120; Wed, 27 Apr 1994 07:31:19 -0700 Message-Id: <9404271431.AA25120@commanche.ca.boeing.com> To: tytso@athena.mit.edu Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Date: Wed, 27 Apr 94 07:31:18 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Ted > .........Like it or > not, whether or not we have an algorithm identifier field or not, in > order for this thing to work, the IETF is going to have to put a stake > in the ground and say that everyone is going to use this *one* > cryptographic algorithm. > I see nothing wrong with a "default" algorithm if we can change it. I cannot see that capability in the draft as it appears to be tightly written around RSA. I think the capability to switch away from a default algorithm is critical. At the same time, this capability would probably also allow those of us who wish to (or are required to) use our own alternates (between consenting adults of course!) to do so. > It's the same problem as the one that's facing the IPNG decision > process. Sometimes, you just have to pick one, and picking anything > protocol is better than not picking a protocol at all. > In any engineering problem, risk assessments must be made; that is are the consequences of failure as weighed against the cost of alternative designs or delays balanced. In this case, I personally think not and certainly do not agree that "anything is better than nothing". Should at some future date the single chosen technology be broken, all you are left with is "false security" which is worse than "no security". > For all of the people who have been bitching and moaning --- if you > don't like the current proposal, then come up with something new! > Unfortunately, public key cryptography is a key technology, without > which, many things in cryptography and security architecture become > much harder. > A lot of us are thinking about alternatives and I don't think any of us want to see the work that Donald and Charles started not be carried to completion. I not so concerned about ease as I am long term durability. > Don't get me wrong --- I think software patents and algorithm patents > are particularily evil, and Congress should wake up and ban the Patent > Office from issuing any more of them. > Evil ??? Needs work, Definitely!!! > - Ted > Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Wednesday April 27,1994 07:29 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa18597; 27 Apr 94 11:36 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02668; Wed, 27 Apr 94 11:35:52 EDT Received: by relay.tis.com; id AA18862; Wed, 27 Apr 94 11:37:08 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma018852; Wed Apr 27 11:36:38 1994 Received: by atc.boeing.com (5.57) id AA12434; Wed, 27 Apr 94 08:35:59 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA08369; Wed, 27 Apr 94 08:35:44 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA22093; Wed, 27 Apr 1994 08:34:01 -0700 Message-Id: <9404271534.AA22093@commanche.ca.boeing.com> To: dee@skidrow.lkg.dec.com Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Mon, 25 Apr 94 13:14:53 D.) <9404251714.AA13136@skidrow.lkg.dec.com> Date: Wed, 27 Apr 94 08:34:01 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Donald > Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in > Redwood City, California. (Or have your lawyer call their lawyer.) > They will confirm that any company can use RSA internally, use PEM to > communicate with other companies, etc., all in a profit making > setting. The only thing RSA is still asking for royalties for is > people who want to sell software incorporating RSA or sell a service > where RSA is an essential part. > Given the option to discuss issues with lawyers (most of whom I can almost never understand) or to design in a way that I may be able to leave them out, I always opt to try to leave them out. Whether I'm selling aircraft, video services, or personal information devices, in the near future all will rely on incorporation of DNS into their core systems. You're saying that they won't want any royalties from my airplane, my home entertain system, or my home computer, all of which would utilize their technology via DNS? That's not quite how I understood their statements. > Whatever algoritm is chosen, the people who want to interoperate will > all have to speak it. Everyone knows you will need a method to roll > over to a new algorithm when / if that is necessary. > As I responded to "Ted Ts'o", I have no problem with a "default algorithm", but I see no way to incorporate any alternative algorithm into DNS or to "roll over to a new algorithm" as the draft is currently written. > So you want multiple algorithms so that those who want to interoperate > will have to speak all of them so that if *any* *one* *of* *them* > is broken, things will fall apart? Sounds like a great way to weaken > network security to me. > Point well taken! But in some cases, groups even countries may be required to NOT use the chosen technology but something else more "politically" acceptable. Governments (and large corporations, especially if they're into money) tend to be paranoid about crytography. I'm fairly sure that not all the world governments would allow comm systems utilizing this crytographic technology to be deployed within their borders. Remember our own country requires anyone selling good crytography to be hold a federal "armaments manufacturers" license and places their exports under even tighter restrictions than just selling missles or bombs. > (Of course there should also be a way for consenting adults to use > whatever algorithm they want, not that you could stop them anyway.) > That's what I am looking. I think it would also solve the "roll over" problem. > Donald > Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Wednesday April 27,1994 08:31 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa21417; 27 Apr 94 14:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15146; Wed, 27 Apr 94 14:38:22 EDT Received: by relay.tis.com; id AA20402; Wed, 27 Apr 94 14:39:39 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma020395; Wed Apr 27 14:39:09 1994 Received: by ginger.lcs.mit.edu id AA13825; Wed, 27 Apr 94 14:38:13 -0400 Date: Wed, 27 Apr 94 14:38:13 -0400 From: Noel Chiappa Message-Id: <9404271838.AA13825@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu I see nothing wrong with a "default" algorithm if we can change it. I cannot see that capability in the draft as it appears to be tightly written around RSA. ... Should at some future date the single chosen technology be broken, all you are left with is "false security" which is worse than "no security". For what it's worth, the paper today reports that group of researchers have factored a 129-digit number (of the kind used by RSA). 25 years down the line, when we all have 1M-CPU connection machines in our PDA's, we might want something better.... Noel   Received: from sol.tis.com by magellan.TIS.COM id aa21969; 27 Apr 94 16:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25845; Wed, 27 Apr 94 16:24:16 EDT Received: by relay.tis.com; id AA21341; Wed, 27 Apr 94 16:25:32 EDT Received: from tipper.oit.unc.edu(152.2.22.85) by relay via smap (V1.3mjr) id sma021336; Wed Apr 27 16:25:20 1994 Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA19960; Wed, 27 Apr 94 16:24:00 EDT Message-Id: <9404272024.AA19960@tipper.oit.unc.edu> To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 14:38:13 EDT." <9404271838.AA13825@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Apr 94 16:23:59 -0400 From: Simon E Spero Even with the new techniques, factorisation still gets exponentially harder as you add more digits. 129 digits is only 429 bits, so 512 bit keys are still pretty safe. By the way, it's interesting to note that the folks who did the factorisation donated the $100 prize money to the FSF. Maybe we can apply that to the problem of address space wasterels. If we set up a tax for every IP address allocated to an organisation that isn't pingable from (say) venera.isi.edu, and give all the proceeds to the FSF, we'd get a bunch of addresses back, a reduction in the number of firewalls, and a whole bunch of new free software which is one of the main wins of the net anyway.   Received: from sol.tis.com by magellan.TIS.COM id aa22429; 27 Apr 94 17:21 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01561; Wed, 27 Apr 94 17:20:47 EDT Received: by relay.tis.com; id AA21910; Wed, 27 Apr 94 17:22:03 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma021902; Wed Apr 27 17:21:11 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14319; Wed, 27 Apr 94 14:13:35 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA04728; Wed, 27 Apr 1994 17:15:20 -0400 Message-Id: <9404272115.AA04728@skidrow.lkg.dec.com> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 08:34:01 -0800." <9404271534.AA22093@commanche.ca.boeing.com> Date: Wed, 27 Apr 94 17:15:20 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" To: dee Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com In-Reply-To: (Your message of Mon, 25 Apr 94 13:14:53 D.) <9404251714.AA13136@skidrow.lkg. dec.com> > >Donald > >> Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in >> Redwood City, California. (Or have your lawyer call their lawyer.) >> They will confirm that any company can use RSA internally, use PEM to >> communicate with other companies, etc., all in a profit making >> setting. The only thing RSA is still asking for royalties for is >> people who want to sell software incorporating RSA or sell a service >> where RSA is an essential part. >> >Given the option to discuss issues with lawyers (most of whom I can >almost never understand) or to design in a way that I may be able to >leave them out, I always opt to try to leave them out. Whether I'm >selling aircraft, video services, or personal information devices, >in the near future all will rely on incorporation of DNS into their >core systems. You're saying that they won't want any royalties from >my airplane, my home entertain system, or my home computer, all of >which would utilize their technology via DNS? That's not quite how I >understood their statements. If you simply call RSA and ask for Kurt Stammberger you get a perfectly reasonable human being who doesn't sound like a lawyer although, for all I know, he may be one. Currently PKP says that all public key technologies are covered by patent in the United States so there is no technique you can use that is completely clear of encumberances. Yes, I'm saying that if you use RSAREF and you are not selling software incorporating it and not selling a service that requires it, RSA won't want any royalties. Most uses seem to fit this category. Even if you were an Internet service provider and offered DNS service for your customers, I don't think the current RSA policy would require any royalties unless you required them to sign up for your DNS service or assessed a separate charge for the DNS service. Certainly if you are a company, educational institution, non-profit org, etc., and just run you own DNS domain in the normal fashion but use secure DNS based on RSAREF, then you clearly don't owe any royalties. >> Whatever algoritm is chosen, the people who want to interoperate will >> all have to speak it. Everyone knows you will need a method to roll >> over to a new algorithm when / if that is necessary. >> >As I responded to "Ted Ts'o", I have no problem with a "default >algorithm", but I see no way to incorporate any alternative algorithm >into DNS or to "roll over to a new algorithm" as the draft is currently >written. I'll fix that. >> So you want multiple algorithms so that those who want to interoperate >> will have to speak all of them so that if *any* *one* *of* *them* >> is broken, things will fall apart? Sounds like a great way to weaken >> network security to me. >> >Point well taken! But in some cases, groups even countries may be >required to NOT use the chosen technology but something else more >"politically" acceptable. Governments (and large corporations, >especially if they're into money) tend to be paranoid about crytography. >I'm fairly sure that not all the world governments would allow comm >systems utilizing this crytographic technology to be deployed within >their borders. Remember our own country requires anyone selling good >crytography to be hold a federal "armaments manufacturers" license >and places their exports under even tighter restrictions than just >selling missles or bombs. I'm not aware of any country that would restrict the algorithms used privately. You may have to give copies of your hardware/software/keys to the government but after you do that, they don't care. >... >> Donald > | Terry L. Davis | Boeing Computer Services, Bellevue, WA | > | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | > | INTERNET EMAIL: tld5032@atc.boeing.com. | > --------------- Wednesday April 27,1994 08:31 AM PDT ------------- >== As always, the above cannot be construed as representing BOEING, == >== the thoughts, comments, and ideas contained herein are mine alone! == Donald   Received: from sol.tis.com by magellan.TIS.COM id aa22460; 27 Apr 94 17:28 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA01753; Wed, 27 Apr 94 17:28:25 EDT Message-Id: <9404272128.AA01753@tis.com> To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 14:38:13 EDT." <9404271838.AA13825@ginger.lcs.mit.edu> Date: Wed, 27 Apr 94 17:28:19 -0400 From: Stephen D Crocker > From: Noel Chiappa > To: big-internet@munnari.oz.au, dns-security@tis.com > cc: jnc@ginger.lcs.mit.edu > Date: Wed, 27 Apr 94 14:38:13 -0400 > Subject: Re: SIPP Routing Header & security & Re: DNS security draft > ... > For what it's worth, the paper today reports that group of > researchers have factored a 129-digit number (of the kind used by > RSA). 25 years down the line, when we all have 1M-CPU connection > machines in our PDA's, we might want something better.... > > Noel > This has been known for a few weeks. There's nothing worrisome, if that's the implicit question. 129 digits is 430 bits. Don't use RSA keys that short. 512 is the least anyone would use. 640, 768 and 1024 are more conservative key sizes that are in increasingly common use. These are all *much* harder to crack (factor) than 430 bits. Except for special exercises like the one reported, or organizations with exceptional resources like NSA, even cracking 430 bits is not within ordinary reach. On the other side of the coin, 512 is exportable, so that's considered unacceptable if you really want security. (Exportable for encryption. Any length is exportable for signature.) Steve   Received: from sol.tis.com by magellan.TIS.COM id aa28197; 28 Apr 94 14:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00213; Thu, 28 Apr 94 14:31:57 EDT Received: by relay.tis.com; id AA01639; Thu, 28 Apr 94 14:33:14 EDT Received: from netmail.microsoft.com(131.107.1.3) by relay via smap (V1.3mjr) id sma001627; Thu Apr 28 14:32:30 1994 Received: by netmail.microsoft.com (5.65/25-eef) id AA14150; Thu, 28 Apr 94 11:31:07 -0700 Message-Id: <9404281831.AA14150@netmail.microsoft.com> Received: by netmail using fxenixd 1.0 Thu, 28 Apr 94 11:31:06 PDT X-Msmail-Message-Id: B714071C X-Msmail-Conversation-Id: B714071C From: Paul Leach To: dee@skidrow.lkg.dec.com, sipp-request@sunroof2.eng.sun.com Date: Thu, 28 Apr 94 09:24:24 TZ Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: big-Internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com ---------- | From: "Terry L. Davis P.E., Boeing Computer Services, | Bellevue, WA" | To: | Cc: ; ; | | Subject: Re: SIPP Routing Header & security & Re: DNS security draft | Date: Wednesday, April 27, 1994 8:34AM | | > Whatever algoritm is chosen, the people who want to interoperate will | > all have to speak it. Everyone knows you will need a method to roll | > over to a new algorithm when / if that is necessary. | > | As I responded to "Ted Ts'o", I have no problem with a "default | algorithm", but I see no way to incorporate any alternative algorithm | into DNS or to "roll over to a new algorithm" as the draft is currently | written. | | > So you want multiple algorithms so that those who want to interoperate | > will have to speak all of them so that if *any* *one* *of* *them* | > is broken, things will fall apart? Sounds like a great way to weaken | > network security to me. This is true, but overlooks some context. If there are several algorithms, but if for any party with whom I might want to communicate there is exactly one that I must use, then breaking one algorithm only exposes the parties that use that algorithm. So, for example, the paranoid company referred to below might use one (allegedly stronger than the default) algorithm internally, but another with outside parties. The same principle applies to using differnet algorithms for different purposes. Thus, all EFT/EDIF mail could use one algorithm, and mail discussing acquisition of another company a second. Etc. | > | Point well taken! But in some cases, groups even countries may be | required to NOT use the chosen technology but something else more | "politically" acceptable. Governments (and large corporations, | especially if they're into money) tend to be paranoid about crytography. | I'm fairly sure that not all the world governments would allow comm | systems utilizing this crytographic technology to be deployed within | their borders. Remember our own country requires anyone selling good | crytography to be hold a federal "armaments manufacturers" license | and places their exports under even tighter restrictions than just | selling missles or bombs. Paul   Received: from sol.tis.com by magellan.TIS.COM id aa22932; 27 Apr 94 23:37 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10663; Wed, 27 Apr 94 23:37:08 EDT Received: by relay.tis.com; id AA24636; Wed, 27 Apr 94 23:38:26 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma024631; Wed Apr 27 23:38:04 1994 Received: by ginger.lcs.mit.edu id AA16374; Wed, 27 Apr 94 23:36:30 -0400 Date: Wed, 27 Apr 94 23:36:30 -0400 From: Noel Chiappa Message-Id: <9404280336.AA16374@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu > ...a group of researchers have factored a 129-digit number (of the kind > used by RSA). 25 years down the line, when we all have 1M-CPU connection > machines in our PDA's, we might want something better... There's nothing worrisome, if that's the implicit question. 129 digits is 430 bits. Don't use RSA keys that short. 512 is the least anyone would use. 640, 768 and 1024 are more conservative key sizes that are in increasingly common use. These are all *much* harder to crack (factor) than 430 bits. I am somewhat familiar with longer key-lengths and what that does to computationally intensive attacks. What I found illuminating (and failed to post, sorry) was that when the problem was first posed, when RSA was discovered in the late 70's, it was thought that it wouldn't be solved until "well into the next century". I think there might be a lesson there. I'm not saying I expect someone to find a magic fast factoring algorithm any time soon, or that anyone's likely to find a hole in RSA anytime soon. However, to do designs based on the assumption that RSA (even the longer key lengths you mention) will be good for all time is a bit unwise of us, (or perhaps even arrogant, as writers on technology disasters from the Titanic onward point out), don't you think? On the other side of the coin, 512 is exportable, so that's considered unacceptable if you really want security. (Exportable for encryption. Any length is exportable for signature.) Facinating. Let me make sure I get this straight. RSA for privacy with key lengths of less than 512 is OK'd for export, but not DES? Noel   Received: from sol.tis.com by magellan.TIS.COM id aa23554; 28 Apr 94 8:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21932; Thu, 28 Apr 94 08:31:40 EDT Received: by relay.tis.com; id AA27585; Thu, 28 Apr 94 08:32:58 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027580; Thu Apr 28 08:32:21 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05104; Thu, 28 Apr 94 05:28:30 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA08820; Thu, 28 Apr 1994 08:30:18 -0400 Message-Id: <9404281230.AA08820@skidrow.lkg.dec.com> To: Noel Chiappa Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 23:36:30 EDT." <9404280336.AA16374@ginger.lcs.mit.edu> Date: Thu, 28 Apr 94 08:30:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Noel Chiappa To: big-internet@munnari.oz.au, dns-security@tis.com > >... > On the other side of the coin, 512 is exportable, so that's considered > unacceptable if you really want security. (Exportable for encryption. > Any length is exportable for signature.) > >Facinating. Let me make sure I get this straight. RSA for privacy with key >lengths of less than 512 is OK'd for export, but not DES? Gives you some idea how hard NSA expects it to be to factor 512 bit numbers in the medium future, doesn't it. > Noel Donald   Received: from sol.tis.com by magellan.TIS.COM id aa26878; 28 Apr 94 11:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09029; Thu, 28 Apr 94 11:45:18 EDT Received: by relay.tis.com; id AA29530; Thu, 28 Apr 94 11:46:35 EDT Received: from unknown(137.65.4.1) by relay via smap (V1.3mjr) id sma029524; Thu Apr 28 11:46:33 1994 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04833; Thu, 28 Apr 94 09:51:00 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB14056; Thu, 28 Apr 94 08:44:27 PDT Date: Thu, 28 Apr 94 08:44:27 PDT Message-Id: <9404281544.AB14056@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Masataka Ohta From: Greg Minshall Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: dns-security@tis.com Masataka, >Secure DNS is now being deeveloped so that a zone, not a host in general, >will have a key. The Eastlake/Kaufmann scheme allows zones, hosts, even users, to have (public) keys. >I know. But it will expire 1997, much earlier than 2000. Three years == (approximately) three days, in my humble opinion, in this area. (Words of the form likely to come back and haunt one...) Greg   Received: from sol.tis.com by magellan.TIS.COM id aa27159; 28 Apr 94 12:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13236; Thu, 28 Apr 94 12:14:36 EDT Received: by relay.tis.com; id AA29930; Thu, 28 Apr 94 12:15:53 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma029920; Thu Apr 28 12:15:27 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10972; Thu, 28 Apr 94 12:06:08 EDT Date: Thu, 28 Apr 94 12:06:08 EDT From: Theodore Ts'o Message-Id: <9404281606.AA10972@tsx-11.MIT.EDU> To: Masataka Ohta Cc: dns-security@tis.com, big-internet@munnari.oz.au In-Reply-To: Masataka Ohta's message of Wed, 27 Apr 94 12:28:35 JST, <9404270328.AA09765@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Wed, 27 Apr 94 12:28:35 JST > What's wrong with ElGamal? > > 1) It doesn't provide support for data hiding. It does, though the algorithms for confidentiality and for authentication are different. You're right. I was confused; most of my knowledge of El Gamal comes from the DSS. > With RSA, the keys that are used for secure DNS can also be used to > establish secure data exchange keys for encryption purposes. Wrong. For encryption purposes, you need keys for hosts or users. Secure DNS is now being deeveloped so that a zone, not a host in general, will have a key. We can use the same RR for distributing the key for a zone to distribute the key for a host in general; that DNS information can be signed by zone key, which gives you the public key certification which you need. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa17271; 2 May 94 13:37 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04920; Mon, 2 May 94 13:36:44 EDT Received: by relay.tis.com; id AA11260; Mon, 2 May 94 13:38:06 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma011245; Mon May 2 13:37:17 1994 Received: by atc.boeing.com (5.57) id AA28916; Mon, 2 May 94 10:38:17 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA01274; Mon, 2 May 94 10:38:03 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25873; Mon, 2 May 1994 10:36:13 -0700 Message-Id: <9405021736.AA25873@commanche.ca.boeing.com> To: dee@skidrow.lkg.dec.com Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Wed, 27 Apr 94 17:15:20 D.) <9404272115.AA04728@skidrow.lkg.dec.com> Date: Mon, 02 May 94 10:36:13 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Donald Donald you responded: > >> Whatever algoritm is chosen, the people who want to interoperate will > >> all have to speak it. Everyone knows you will need a method to roll > >> over to a new algorithm when / if that is necessary. > >> > >As I responded to "Ted Ts'o", I have no problem with a "default > >algorithm", but I see no way to incorporate any alternative algorithm > >into DNS or to "roll over to a new algorithm" as the draft is currently > >written. > > I'll fix that. > Many thanks, that meets my concerns! Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Monday May 02,1994 10:35 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa15018; 5 May 94 13:29 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19521; Thu, 5 May 94 13:28:31 EDT Received: by relay.tis.com id AA06764; Thu, 5 May 94 13:29:07 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma006759; Thu May 5 13:28:56 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA18409; Thu, 5 May 94 10:24:58 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA03019; Thu, 5 May 1994 13:26:50 -0400 Message-Id: <9405051726.AA03019@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Sat, 23 Apr 94 00:08:31 +0200." <9404221508.AA20758@necom830.cc.titech.ac.jp> Date: Thu, 05 May 94 13:26:50 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Cc: dee, dns-security@tis.com In-Reply-To: <9404221355.AA20519@necom830.cc.titech.ac.jp>; from "Masataka Ohta" at Apr 22, 94 10:54 pm >A minor improvement. MD5 signature of the zone's public key is enough >for boot files and for referral information. > Masataka Ohta > >PS > >May we assume MD5 is unforgeable forever? I don't think so. That's why the original proposal was for the Secure Hash Algorithm which produces a 160 bit hash and when the Working Group decided to cut back to MD5, Charlie and I strengthened the hashes inside the SIG by making them change more often. If the US NSA thinks 160 bits are needed, I would hesitate to contradict them in such a narrow technical matter. By the way, you should note that the US NIST has recently announced that a flaw was found in SHA making it weaker than originally thought. The will be announcing a new hash function at some point. That it took NSA this long to find this flaw in SHA certainly implies there could be lurking problem in any of the MD* algorithms. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa25531; 7 May 94 14:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00488; Sat, 7 May 94 14:03:01 EDT Received: by relay.tis.com id AA00212; Sat, 7 May 94 14:03:40 EDT Received: from unknown(144.110.16.11) by relay via smap (V1.3mjr) id sma000200; Sat May 7 14:03:21 1994 Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA19429 (5.65c/IDA-1.4.4/DIT-1.3 for dns-security@tis.com); Sat, 7 May 1994 22:13:24 +1000 Message-Id: <199405071213.AA19429@shark.mel.dit.csiro.au> To: dns-security@tis.com Subject: Thoughts on DNS security draft: Multi-key domains Date: Sat, 07 May 1994 22:13:03 +1000 From: Bob Smart There seem to be two reasons why a zone or domain might want to have more than one key at a given point of time. 1. We are changing from an old key to a new one (perhaps bigger) and we want both to be valid for a while. 2. We want to have two keys which are administered separately and valid records will be signed by both. The simple way to handle this is to add an extra field for the RR saying how many signatures are necessary for validity. To take the most confusing case: a.b.c. IN RSA 1 xxx... (old key, still valid with one sig) IN RSA 2 yyy... (new key now valid but not alone) IN RSA 2 zzz... (other new key must be used with the yyy key for validity). Written signatures for organizations and for important functions within organizations frequently require multiple signatures and we should allow for this with digital signatures. For example we could then set it up so that the root zone is not dependant on the security of one person/organization/location. Bob Smart   Received: from sol.tis.com by magellan.TIS.COM id aa25537; 7 May 94 14:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00476; Sat, 7 May 94 14:02:01 EDT Received: by relay.tis.com id AA00203; Sat, 7 May 94 14:02:40 EDT Received: from unknown(144.110.16.11) by relay via smap (V1.3mjr) id sma000193; Sat May 7 14:01:41 1994 Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA19877 (5.65c/IDA-1.4.4/DIT-1.3 for dns-security@tis.com); Sat, 7 May 1994 23:12:28 +1000 Message-Id: <199405071312.AA19877@shark.mel.dit.csiro.au> To: dns-security@tis.com Subject: Thoughts on DNS security draft: new protocol? Date: Sat, 07 May 1994 23:12:10 +1000 From: Bob Smart The DNS security draft is a brilliant application of public key cryptography. However it is rather complex. I have the vague feeling that things would be a lot simpler if secure access to the DNS was a different protocol. The DNS and secure-DNS would return the same information. However there would be no SIG RRs. Secure-DNS would only work for the parts of the DNS that have keys and it would always return everything either signed or packed within a signature as in the current clever proposal. There is no problem deciding which protocol to use. For example if we want to query the NS that is responsible for xyz.com.au then we know whether we can use secure-DNS by whether the com.au domain has an RSA key for xyz.com.au. [It seems natural for parent zones to include the RSA RRs of subordinate domains since the parent domain has to sign those keys.] The secure-DNS protocol could have some new desirable features: 1. Use a reliable query-response protocol like Prospero's ARDP, or the proposed compacted TCP. 2. Have the ability to return a signed list of all the immediate sub-domains of a domain to allow a cached and secure NXDOMAIN. 3. Use expiration times instead of TTLs. The last implies a secure time service but we depend on that anyway. Bob Smart   Received: from sol.tis.com by magellan.TIS.COM id aa27368; 8 May 94 9:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16163; Sun, 8 May 94 09:17:31 EDT Received: by relay.tis.com id AA01924; Sun, 8 May 94 09:18:11 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma001922; Sun May 8 09:17:36 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 8 May 94 22:11:37 +0900 From: Masataka Ohta Return-Path: Message-Id: <9405081311.AA01464@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Sun, 8 May 94 22:11:35 JST Cc: dns-security@tis.com In-Reply-To: <9405051726.AA03019@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at May 5, 94 1:26 pm X-Mailer: ELM [version 2.3 PL11] >A minor improvement. MD5 signature of the zone's public key is enough >for boot files and for referral information. During the 10 days of vacation, I have reread RFC 103[45]. I now better understand DNS and noticed that we don't have to modify referral information. Doing so won't make DNS any more secure. It is quite natural that protection of non-authoritative data of a zone is not necessary. I have also find a difficulty of handling CNAME. Currently, it is not possible to have a node which has both CNAME and other RR type. But, the only natural way to make CNAME secure, it seems to me, is to add some signature information to the node of CNAME. So, I think we need a new OPCODE (RD=0 is useless) to suppress CNAME processing. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa27420; 8 May 94 9:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16349; Sun, 8 May 94 09:44:31 EDT Received: by relay.tis.com id AA01997; Sun, 8 May 94 09:45:12 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma001995; Sun May 8 09:45:04 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 8 May 94 22:39:20 +0900 From: Masataka Ohta Return-Path: Message-Id: <9405081339.AA01709@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: Greg Minshall Date: Sun, 8 May 94 22:39:18 JST Cc: dns-security@tis.com In-Reply-To: <9404281544.AB14056@WC.Novell.COM>; from "Greg Minshall" at Apr 28, 94 8:44 am X-Mailer: ELM [version 2.3 PL11] > >Secure DNS is now being deeveloped so that a zone, not a host in general, > >will have a key. > > The Eastlake/Kaufmann scheme allows zones, hosts, even users, to have > (public) keys. So? What Teodole said was: : With RSA, the keys that are used for secure DNS can also be used to : establish secure data exchange keys for encryption purposes. We are talking about actual key values, not the way to specify them. It is, of course, crazy to share a secret key of a zone by all the hosts in the zone. > >I know. But it will expire 1997, much earlier than 2000. > > Three years == (approximately) three days, in my humble opinion, in this > area. (Words of the form likely to come back and haunt one...) Three days is much shorter and, thus, better than three years, isn't it? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa00461; 9 May 94 9:05 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08089; Mon, 9 May 94 09:05:06 EDT Received: by relay.tis.com id AA04017; Mon, 9 May 94 09:05:48 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma004015; Mon May 9 09:05:43 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26012; Mon, 9 May 94 06:00:50 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23779; Mon, 9 May 1994 09:02:45 -0400 Message-Id: <9405091302.AA23779@skidrow.lkg.dec.com> To: Bob Smart Cc: dns-security@tis.com Subject: Re: Thoughts on DNS security draft: new protocol? Multi-key domains In-Reply-To: Your message of "Sat, 07 May 94 23:12:10 +1000." <199405071312.AA19877@shark.mel.dit.csiro.au> Date: Mon, 09 May 94 09:02:45 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Bob, From: Bob Smart To: dns-security@tis.com >The DNS security draft is a brilliant application of public >key cryptography. However it is rather complex. I'm beginning to feel that some of the complexity may not be necessary. Perhaps, as suggested by Ohta-san, being able to split a set of direct RR signets across multiple SIG RR's isn't important enough for the complexity it adds. But in Seattle, the working group wanted that left in until there is real operational experience, so I plan to leave it there for the time being. >I have the vague feeling that things would be a lot simpler >if secure access to the DNS was a different protocol. The >DNS and secure-DNS would return the same information. However >there would be no SIG RRs. The world is always much simpler if you can ignore the installed base. If you design a new protocol you are throwing away the enormous installed base of DNS servers. The basic features of the secure dns proposal permit it to be deployed with only minor modifications to primaries, so they can read in the new RR's. No change at all are needed in secondaries or caching servers. And only those resolvers and applications that want to be security aware need be modified. Second, if you are going to the upheaval of a new protocol, there are a *lot* of things you want to do, including greater flexibility and options, stuff related to larger UDP packets, incremental zone transfer, dynamic update, etc. (See draft-ietf-dns-ixfr-*.txt and my moderately recent message to the Namedroppers mailing list and other discussion there.) A new protocol framework to provide for this would be great but dns security is needed yesterday and I don't think it should wait for upgrading all servers that might serve up a secured zone. >Secure-DNS would only work for the parts of the DNS that >have keys and it would always return everything either signed >or packed within a signature as in the current clever proposal. > >There is no problem deciding which protocol to use. For example >if we want to query the NS that is responsible for xyz.com.au >then we know whether we can use secure-DNS by whether the com.au >domain has an RSA key for xyz.com.au. [It seems natural for >parent zones to include the RSA RRs of subordinate domains >since the parent domain has to sign those keys.] [In the next version of the draft, I plan to rename the RSA RR to be the KEY RR.] You can't actually tell if a zone is secure without looking at the mode bits in the KEY RR which is in it's superzone (or some local configuration information). That KEY RR could be missing or could say the inferior zone has no key or could say that it has a key and might optionally be using it or could say that it has a key and will always use it. Only in the last case do you know the zone is secure. But: What is this "the NS responsible for ...". Zones have multiple name servers plus sometimes unregistered secondaries. Knowing that a zone is secure in the current proposal has nothing to do with whether all of its servers are security aware and even its primary need only be minimally compliant. In some environments, a security aware resolver or application may not be able to get at any of the NS's for a zone and have to depend on local non-security aware caching servers, etc. How is that going to work unless all these are replaced with servers speaking your new protocol? >The secure-DNS protocol could have some new desirable features: > > 1. Use a reliable query-response protocol like Prospero's ARDP, > or the proposed compacted TCP. There is usually a *lot* of overhead associated with reliability. I don't know about ARDP or compacted TCP but just going to regular TCP *triples* the number of packets and is unacceptable to high volume DNS servers. The resources used at the servers, the additional delay in getting answer, etc., all speak strongly against using a reliable transport. > 2. Have the ability to return a signed list of all the immediate > sub-domains of a domain to allow a cached and secure NXDOMAIN. See following messages res NX... > 3. Use expiration times instead of TTLs. Yes, if you are going to a new protocol, you could drop TTLs and could provide the same facilities with times. >The last implies a secure time service but we depend on that >anyway. > >Bob Smart To: Bob Smart cc: dns-security@tis.com Subject: Re: Thoughts on DNS security draft: Multi-key domains In-reply-to: Your message of "Sat, 07 May 94 22:13:03 +1000." <199405071213.AA19429@shark.mel.dit.csiro.au> -------- From: Bob Smart To: dns-security@tis.com >There seem to be two reasons why a zone or domain might >want to have more than one key at a given point of time. > >1. We are changing from an old key to a new one (perhaps > bigger) and we want both to be valid for a while. > >2. We want to have two keys which are administered separately > and valid records will be signed by both. > >The simple way to handle this is to add an extra field for >the RR saying how many signatures are necessary for validity. >To take the most confusing case: > > a.b.c. IN RSA 1 xxx... (old key, still valid with one sig) > IN RSA 2 yyy... (new key now valid but not alone) > IN RSA 2 zzz... (other new key must be used with > the yyy key for validity). [In the next draft I plan to rename RSA RR to be KEY RR.] This is an interesting idea. And I don't think adding a byte for this to the KEY RR would cost that much. But it does add significant complexity to any security aware resolver. The DNS organization, with a single primary per zone, would seem somewhat philosophically opposed to this. I'm inclined to think the additional complexity would not be worth it. >Written signatures for organizations and for important functions >within organizations frequently require multiple signatures and >we should allow for this with digital signatures. For example we >could then set it up so that the root zone is not dependent on >the security of one person/organization/location. Well, I'm not sure that going to two signatures would help all that much. Who would the two signnatories for root be? And going for more than two will quickly lead to UDP packet overflow with medium size keys. Even two signatures can easily cause UDP overflow with big keys. >Bob Smart Donald   Received: from sol.tis.com by magellan.TIS.COM id aa00642; 9 May 94 11:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13514; Mon, 9 May 94 11:12:13 EDT Received: by relay.tis.com id AA04553; Mon, 9 May 94 11:12:55 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma004546; Mon May 9 11:12:24 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA24836; Mon, 9 May 1994 17:09:48 +0200 Message-Id: <199405091509.AA24836@mitsou.inria.fr> To: "Donald E. Eastlake 3rd (Beast)" Cc: Bob Smart , dns-security@tis.com Subject: Re: Thoughts on DNS security draft: new protocol? Multi-key domains In-Reply-To: Your message of "Mon, 09 May 1994 09:02:45 EDT." <9405091302.AA23779@skidrow.lkg.dec.com> Date: Mon, 09 May 1994 17:09:48 +0200 From: Christian Huitema Donald, It have waited quite a long time before mixing in this discussion. Please find enclosed my comments on your draft. The current draft places the signatures in a "SIG" record, which is stored under the entry itself in the "Internet" class. A SIG RR contains "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), some flags, and an RSA (Rivest, Shamir, and Adelman [RSA]) signature." The scheme used for associating the actual record with its signature is not excatly simple - using the term "convoluted" would not be excessive. The RSA encrypted data may contain: * either the "RR" itself (but then, how is it keyed?) * or a message digest of the resource record. One may note a small problem with this scheme: there is no way to get the exact SIG associated to a particular RR through the "normal" DNS access procedure. One will have to retrieve all SIGs, decode the RSA data, perform a pattern matching... not a very desirable procedure. This leads the DNS-SEC authors to design an "updated" or "security conscious" version of the DNS protocol, that use some internal magic to keep the association between data and signatures. I propose to use the "class" mechanism to overcome this problem. The normal insecure data will be store as usual as IN (Internet) class records. The corresponding signatures will be signed as parallel records in a new class, says INSECT (Internet security). A standard DNS query in class IN for a record type A will get all type A RRs; a standard DNS query in class INSECT for a record type A will get the signature of these records, as well as the record value in the "additional" section if that is necessary. The RSA/KEY record will remain in the IN domain. A corresponding signature will be placed in the SIG domain. The format of the signatures should be independant of the particular record type. In fact, one could very much use your current specification. I would just add a more precise definition of the hashing function, so that one could parameter one of the following: 1) Hash with MD5 2) Hash with something else 3) Don't hash, the data are passed in the clear as a succession of RVALUEs Plus also an ordering of the RR values, e.g. by ascending binary order. That way you will keep your possibility of not sending the clear text if "RSA" is used in conjunction with "don't hash". But you will also always guarantee that all RR are signed with exactly one signature. If we are space conscious, we may want to make the signer's ID optional in the SIG. Maybe define a "potential signer" RR that has a 32 bits ID + a name, and only repeat the 32 bits ID in the message. Or provide a default encoding for "the entry itself", "the zone owner"... Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa01585; 9 May 94 14:57 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13741; Mon, 9 May 94 14:57:34 EDT Received: by relay.tis.com id AA06190; Mon, 9 May 94 14:58:16 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma006186; Mon May 9 14:57:29 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20099; Mon, 9 May 94 11:51:39 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA06054; Mon, 9 May 1994 14:53:35 -0400 Message-Id: <9405091853.AA06054@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of "Fri, 22 Apr 94 21:44:55 +0200." <9404221245.AA20257@necom830.cc.titech.ac.jp> Date: Mon, 09 May 94 14:53:35 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Ohta-san, Charlie and I talked a little be about this sort of thing but at the time it seemed a bit too complicated and it didn't seem worth it to block this particular denial of service attack when there were various other denial of service problems that you couldn't fix. But I've been thinking about this more, prompted by your message. There are a variety of ways you could add authenticated NX information to secure DNS. Taking the current dns security proposal as the most lax of these (no NX name info), you could go all the way to one that comletely mapped just what combinations of name and type did or didn't exist. However to be very stringent would be more complicated and tend to block some types of dynamic update. Still it would be very nice to be able to authoritatively know in, for example, the .com domain, that some name definitely existed or didn't exist. Thinking about all this also lead me to the conclusion that a little more is necessary to do right by wildcard RRs. Anyway, right after this message, I'll post a separate message with my current thoughts on NX & wildcard. From: Masataka Ohta To: dns-security@tis.com X-Mailer: ELM [version 2.3 PL11] >If a list of all the names in a zone is available, authenticated NXDOMAIN >is easy. But it is unrealistic to extract such lengthy information. > >So, how is the following idea to make NXDOMAIN response authenticated? > >Have the following new RR type: XD (eXisting Domains) > > XD ... > >where is the neggative cache period, , ... are >all the domain names within the zone (including the toplevel name of child >zones) which is located between and with some dictionary >order. covers the data of the record (not all the XD records) >signed by the zone's key. > >Then, to authenticate that some domain does not exist, an XD (not >necessarily all the XDs) containing the queried domain between >and should be added in the additional section. I don't like having these RRs all dangle out of the zone name or that that individual XD RRs could be huge. >As there should be a lot of XD, the additional section should almost >always be truncated, even if the query is by TCP. > >For example, if "com." zone contains only the following three domains >beginning with "b": > > bar.com. > bizzare.com. > buzz.com. > >XD for them will be > >com. XD 3600 b.com. c.com. bar.com. bizzare.com. buzz.com. > >Then, a query for "best.com." will fail with authentication. > >To authenticate "foo.bar.com." does not exist, it is further necessary >to confirm NS for "bar.com" does not exist. > > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa01587; 9 May 94 14:57 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13740; Mon, 9 May 94 14:57:34 EDT Received: by relay.tis.com id AA06191; Mon, 9 May 94 14:58:15 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma006187; Mon May 9 14:57:38 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20241; Mon, 9 May 94 11:53:47 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA06141; Mon, 9 May 1994 14:55:43 -0400 Message-Id: <9405091855.AA06141@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Thought on non-existant and wildcarded names Date: Mon, 09 May 94 14:55:42 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp This is what I came up with and am thinking of merging into the next draft: INTERNET-DRAFT DNS Protocol Security Extensions Domain Name Protocol Security Extensions W. Special Handling of Wildcard Matches and Non-existence DNS security provides the means for establishing integrity and data origin authenticity. However, this applies only to actual RRs in a secured zone. There are two places where would be insufficient without some additional steps. The first case is securely indicating the absence of data. The other is the that of wildcard RRs. Wildcard RRs have node names whose first label is an asterisk ("*"). These act as instructions for synthesizing RRs not actually present. Since there are an enormous number of possible DNS names, it is impossible to create and sign separate existence RRs for all possible wildcard matches or denial RRs for all possible queries for non-existent data. These are handled securely as described below. The following example zone is used in this section: FOO. IN SOA QQ.FOO. admin.QQ.FOO. ( 60 ; serial 7200 ; refresh 600 ; retry 1000000 ; expire 60 ; minimum ) NS QQ NS X.BAR MX 10 A1 MX 99 QQ A1 A 192.0.2.252 A 192.245.52.250 MX 10 A1 MX 99 QQ X.BAR A 192.0.2.253 A 192.245.52.249 MX 10 X.BAR MX 80 Y.Z.BAR Y.Z.BAR A 192.245.52.248 MX 10 Y.Z.BAR MX 80 Z.BAR Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions *.BAR MX 10 Y.Z.BAR MX 80 X.BAR QQ A 192.0.2.254 MX 10 QQ MX 50 A1 W.1 Wildcard RR Matches The Domain Name System contains a provision for RRs that match any name below a point in the name tree unless a more specific name matches. (See section 4.3.3 in RFC 1034.) For example, in zone FOO, there is an RRs named *.BAR.FOO and also more specifiec RRs with names X.BAR.FOO and Y.Z.BAR.FOO. The wildcard RRs with name *.BAR.FOO can be though of as instructions for synthesizing RRs with matching names and the same class, type, TTL, and RDATA, when a matching query arrives. If a type MX query is made to zone FOO as above for Z.BAR.FOO, it will match the wildcard RR and not any of the more specific RRs. So a response will be made with the queried name (Z.BAR.FOO) substituted for the wildcard name (*.BAR.FOO). On the other hand, a query for X.BAR.FOO or Z.BAR.FOO or anything below them will ignore the wildcard and either respond with the specific RR or a non-existent name response. Queries for xx.FOO, where xx is any label but BAR, will be unaffected by the wildcard. A wildcard is frequently used for such purposes as causing mail to a large class of name to be sent to a particular set of mail gateways by using wildcard MX RRs. Wildcard RRs are signed by SIG RRs with the same wildcard name and the signature is based on the wildcard name. To make it possible to verify the signature, the SIG RR has a LABELS field which gives the number of actual labels in its name, above the wildcard *, if there is one, not counting the null label for root. If the actual number of labels present in the RR name equals the LABELS field, then no wildcard is involved. If the actual number of labels present is larger, then an * can be temporarily substituted for the synthesized part of the name to verify the signature. If a wildcard RR has been supressed because it appears inside a SIG on a request for a security aware resolver to a security aware server, the resolver has to do the wildcard expansion. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions W.2 Non-existent Types When a secure query is made for a name and class that exist is a zone, but for an RR type that does not exist, there needs to be a secure way to know that the type does not exist. This can be determined by retrieving and examining all the SIG RRs. All types will be indicated within the SIGs and the partial RR set signets in the SIGs can be used to assure that a complete set of SIGs has been retrieved. Thus a query from a security aware resolver for a name that exists for some RR in a zone but not as the owner of any RR of the requested type should be answered by a security aware server with the usual error but with all the SIGs for that name as additional information. W.3 Nonexistent Names The nonexistence of a name in a zone is indicates by the NX resource RR for a name interval containing the nonexistent name. An NX RR is returned in the additional information section, along with the error, if the client is security aware. NX RRs can also be returned if an explicit query is made for the NX type. The existence of NX records means that any query for any name to a security aware server serving a secure zone should result in an reply containing at least one signed RR. W.3.1 The NX Resource Record The NX resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a domain (or that any specific names in that interval are masked by a wildcard). The owner name of the NX RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NX RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions There is a slight problem with the last NX in a zone as it wants to have an owner name which is the last existing name is sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NX. There are additional complexities due to interaction with wildcards as explained below. The NX RRs for a zone can be automatically calculated and added to the zone by the same recommended off-line process that signs the zone. The NX RRs TTL should not exceed the zone minimum TTL. The type number for the NX RR is xxx. W.3.2 NX RDATA format The RDATA for an NX RR consists simply of a domain name. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ W.3.3 Interaction of NX RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NX record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NX RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NX for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NX is returned as additional information in connection with a query for a non-existent name. If there could be any wildcard RRs in a zone and thus wildcard NXs, care must be taken in interpreting the results of explicit NX retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions in the internal. The server can just falsely return the wildcard match instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NX RR whose owner name and RDATA are both the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. It would be possible to make a more complex NX feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature very difficult. See Section xxx. Below is the sample zone given above with NX RRs added. FOO. IN SOA QQ.FOO. admin.QQ.FOO. ( 60 ; serial 7200 ; refresh 600 ; retry 1000000 ; expire 60 ; minimum ) NS QQ NS X.BAR MX 10 A1 MX 99 QQ NX A1 A1 A 192.0.2.252 A 192.245.52.250 MX 10 A1 MX 99 QQ NX BAR X.BAR A 192.0.2.253 A 192.245.52.249 MX 10 X.BAR MX 80 Y.Z.BAR ; no NX, covered by *.BAR Y.Z.BAR A 192.245.52.248 MX 10 Y.Z.BAR MX 80 Z.BAR ; no NX, covered by *.BAR *.BAR MX 10 Y.Z.BAR MX 80 X.BAR NX QQ QQ A 192.0.2.254 MX 10 QQ MX 50 A1 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions NX FOO. W.3.4 Blocking NX Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NX associated with the zone name. Using the RDATA field from that RR, it can query for the next NX RR. By repeating this, it can walk through all the NXs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NX walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals. If it is desired to block NX walking, the recommended method is to add a zone wide wildcard of the KEY type which asserts the nonexistence of any keys. This will cause there to be only one NX RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non- existence of names that NX RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching that wildcard and can thus hide all the real data and delegations with more specific names in the zone. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6]   Received: from sol.tis.com by magellan.TIS.COM id aa01808; 9 May 94 15:44 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18593; Mon, 9 May 94 15:44:38 EDT Received: by relay.tis.com id AA06717; Mon, 9 May 94 15:45:20 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma006715; Mon May 9 15:44:24 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HC50KOA72O001DYE@FNAL.FNAL.GOV>; Mon, 9 May 1994 14:44:06 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA03684; Mon, 9 May 94 14:43:15 CDT Date: Mon, 09 May 1994 14:43:15 -0500 From: Matt Crawford Subject: Re: Thoughts on DNS security draft: new protocol? Multi-key domains In-Reply-To: Your message of Mon, 09 May 94 17:09:48 +0100. <199405091509.AA24836@mitsou.inria.fr> To: dns-security@tis.com Message-Id: <9405091943.AA03684@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Christian Huitema says: > I propose to use the "class" mechanism to overcome this problem. The > normal insecure data will be store as usual as IN (Internet) class > records. The corresponding signatures will be signed as parallel records > in a new class, says INSECT (Internet security). The fact that different classes are delegated independently has some interesting implications. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa02587; 9 May 94 18:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02087; Mon, 9 May 94 18:30:52 EDT Received: by relay.tis.com id AA08201; Mon, 9 May 94 18:31:35 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma008197; Mon May 9 18:31:22 1994 Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA24794; Mon, 9 May 1994 18:31:11 -0400 Received: from localhost by alpha.zk3.dec.com; (5.65/1.1.8.2/05May94-1225PM) id AA01213; Mon, 9 May 1994 18:31:10 -0400 Message-Id: <9405092231.AA01213@alpha.zk3.dec.com> To: smart@mel.dit.csiro.au Cc: dns-security@tis.com, kaufman@zk3.dec.com Subject: Re: Thoughts on DNS security draft: Multi-key domains Date: Mon, 09 May 94 18:31:09 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >2. We want to have two keys which are administered separately > and valid records will be signed by both. > >The simple way to handle this is to add an extra field for >the RR saying how many signatures are necessary for validity. >To take the most confusing case: Generally, I'm concerned that this proposal costs code in all resolvers for a scenario that is extremely unlikely. But the proposal led me to think of a hack that I couldn't resist sharing. [And I confess I could have the cryptographic details wrong and if so I'm sure someone out there will embarrass me]. RSA is generally used with two keys: a public key and a private key. Each key consists of an exponent and a (shared) modulus. If you can factor the modulus, you can compute one exponent from the other. Otherwise you can't. It would be possible to do RSA using three keys: two private keys and a public key. The operation of the private keys (in either order) would reverse the operation of the public key, so both private keys would be needed to compute signatures and both would be needed to decrypt data. [You just need to find d, d', and e such that d*d'*e = 1 mod((p-1)*(q-1)).] This means that you might be able to implement the "dual controls" you want above with no changes to the DNS syntax at all! (Which I'll confess is the reason it appeals to me). The public key operates no differently than any other RSA public key. I believe it could even be extended to handle "this key or these two or these three may sign", though I'd want to review the literature before promising that feat. The only real problem is that there is an exposure at key generation time where d and d' will be known by a single entity. This information could exist only for a short time in a controlled environment and destroyed. It also means that the signing operation could not be as fast, but performance is not likely to be crucial in an environment this paranoid. --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa03126; 10 May 94 4:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09214; Tue, 10 May 94 04:38:14 EDT Received: by relay.tis.com id AA09719; Tue, 10 May 94 04:38:57 EDT Received: from unknown(131.112.4.4) by relay via smap (V1.3mjr) id sma009717; Tue May 10 04:38:38 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 10 May 94 17:31:22 +0900 From: Masataka Ohta Return-Path: Message-Id: <9405100831.AA08326@necom830.cc.titech.ac.jp> Subject: Re: Thought on non-existant and wildcarded names To: "Donald E. Eastlake 3rd" Date: Tue, 10 May 94 17:31:20 JST Cc: dns-security@tis.com In-Reply-To: <9405091855.AA06141@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at May 9, 94 2:55 pm X-Mailer: ELM [version 2.3 PL11] > This is what I came up with and am thinking of merging into the next draft: > W. Special Handling of Wildcard Matches and Non-existence Handling of wildcards are surely an issue to be protected against denial of service attack. > W.3 Nonexistent Names > > The nonexistence of a name in a zone is indicates by the NX resource RR > for a name interval containing the nonexistent name. Unlike EXD, your scheme with NX is not appropriate for referral. > The existence of one or more wildcard RRs covering a name interval makes > it possible for a malicious server to hide any more specificly named RRs > in the internal. The server can just falsely return the wildcard match > instead of the more specificly named RRs. If there is a zone wide > wildcard, there will be only one NX RR whose owner name and RDATA are > both the zone name. In this case a server could conceal the existence > of any more specific RRs in the zone. It would be possible to make a > more complex NX feature, taking into account the types of RRs that did > not exist in a name interval, and the like, which would eliminate this > possibility. I'm afraid you don't understand scope rules of wildcards. It has nothing to do with RR types. To securely claim that aaa.xxx.yyy.zzz.com. matches a wildcard "*.com", it is necessary and sufficient to securely prove that the zone does not contain nodes: zzz.com. yyy.zzz.com. xxx.yyy.zzz.com. aaa.xxx.yyy.zzz.com. > But it would be more complex and would be so constraining > as to make any future dynamic update feature very difficult. See > Section xxx. It has nothing to do with dynamic update. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa04912; 10 May 94 13:23 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01879; Tue, 10 May 94 13:23:41 EDT Received: by relay.tis.com id AA11763; Tue, 10 May 94 13:24:24 EDT Message-Id: <9405101724.AA11763@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma011760; Tue May 10 13:24:02 1994 To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of Mon, 25 Apr 94 16:00:11 -0400. <9404252000.AA28202@ginger.lcs.mit.edu> Date: Tue, 10 May 94 13:22:07 -0400 From: Steve Kent Noel, I thought of another motivation for requiring the dns-security mechanisms algorithm independent. The DoD makes extensive use of TCP/IP and it is a market into which many vendors probably want to be able to continue to sell. However, the crypto algorithms used in DoD networks are often different from those employed in the open Internet. It behooves us to adopt security standards that are algorithm independent whenever we would like the DoD to be able to use the same protocols but with different crypto algorithms. In circumstances where the DoD enclaves are isolated from the open Internet, there is no need for commonality of algorithm, but commonality of protocol still allows for DoD use of COTS products. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05102; 10 May 94 14:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08146; Tue, 10 May 94 14:48:49 EDT Received: by relay.tis.com id AA12552; Tue, 10 May 94 14:49:33 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma012542; Tue May 10 14:49:12 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25368; Tue, 10 May 94 11:41:55 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25410; Tue, 10 May 1994 14:43:51 -0400 Message-Id: <9405101843.AA25410@skidrow.lkg.dec.com> To: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 10 May 94 13:22:07 EDT." <9405101723.AA21814@Sun.COM> Date: Tue, 10 May 94 14:43:51 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, As I have said, the next version of the dnssec-secext draft will have provisions for algorithms versions. From: Steve Kent To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM In-Reply-To: Your message of Mon, 25 Apr 94 16:00:11 -0400. <9404252000.AA28202@ginger.lcs.mit.edu> Sender: sipp-request@sunroof.Eng.Sun.COM >Noel, > > I thought of another motivation for requiring the dns-security >mechanisms algorithm independent. The DoD makes extensive use of >TCP/IP and it is a market into which many vendors probably want to be >able to continue to sell. However, the crypto algorithms used in >DoD networks are often different from those employed in the open >Internet. It behooves us to adopt security standards that are >algorithm independent whenever we would like the DoD to be able to use >the same protocols but with different crypto algorithms. In The DoD spectre has already been rasied by others. Personally, I really don't care whether the DoD can use the same protocols with different crypto algorithms. The success of the Internet is based on good engineering for the Internet environment, rather than trying for bureaucratic correctness. When Internet standards have followed such outside non-technical forces, such as the adoption of ASN.1 for SNMP, it has been regretted. A clear provision for at least rolling over to future algorithm sets in needed in dns-security because it is good engineering. And once you have an algorithm version field, its trivial to provide a systematic way for private algorithms to be identified. The details of the construction of SIG RRs and their use in authentiction are part of the algorithm set, not part of the protocol. >circumstances where the DoD enclaves are isolated from the open >Internet, there is no need for commonality of algorithm, but >commonality of protocol still allows for DoD use of COTS products. You can't use COTS products with different algorithms unless you add your (for the DoD probably classified secret) algorithms. If you consider proper algorithms to be (1) taking one piece of data and a key and calculating a SIG for it and (2) taking one piece of data, a key, and a SIG and saying if that SIG authenticates the data, then the current protocol is algorithm dependent. However, if you consider an algorithm to be (1) taking a set of data elements and a key and calculating one or more SIGs and (2) taking one or more data elements, a key, and one or more SIGs and saying if those SIG(s) authentic that data, then the current protocol is totally algorithm independent. (Yes, there are some simplicifcations in my descriptions of both points of view, for brevity, such as only considering the minimally compliant server, but I could construct a parallel set of complete descriptions which would demonstrate the same point.) >Steve Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05270; 10 May 94 16:41 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16824; Tue, 10 May 94 16:40:58 EDT Received: by relay.tis.com id AA13450; Tue, 10 May 94 16:41:41 EDT Message-Id: <9405102041.AA13450@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma013443; Tue May 10 16:40:52 1994 To: "Donald E. Eastlake 3rd (Beast)" Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of Tue, 10 May 94 14:43:51 -0400. <9405101843.AA25410@skidrow.lkg.dec.com> Date: Tue, 10 May 94 16:34:10 -0400 From: Steve Kent Donald, I'm glad to hear that the next version of the proposal will carry algortihm identifiers, and I hope it will be algorithm independent too. In the case of signatures, algorithm independence would require that we not rely on the reversability of RSA signatures, i.e., the ability to revover the signed data from the signature value. A generic signature validation mechanism begins by (locally) computing the hash on the (purportedly) signed data. That input, the public key and any algorithm parameters of the signer, plus the signature value itself is input to a signature verification routine. The routine then outputs true or false, i.e., the signature is valid or invalid. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa24145; 7 Jun 94 8:54 EDT Received: by relay.tis.com id AA11146; Tue, 7 Jun 94 08:51:45 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma011136; Tue Jun 7 08:50:46 1994 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29584; Tue, 7 Jun 94 08:54:40 EDT Received: by relay.tis.com id AA11133; Tue, 7 Jun 94 08:50:44 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma011124; Tue Jun 7 08:49:49 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA17575; Tue, 7 Jun 94 05:45:22 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21968; Tue, 7 Jun 1994 08:47:40 -0400 Message-Id: <9406071247.AA21968@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) Date: Tue, 07 Jun 94 08:47:40 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Steve Kent To: "Donald E. Eastlake 3rd (Beast)" Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM In-Reply-To: Your message of Tue, 10 May 94 14:43:51 -0400. <9405101843.AA25410@skidrow.lkg.dec.com> Sender: sipp-request@sunroof.Eng.Sun.COM >Donald, > > I'm glad to hear that the next version of the proposal will >carry algortihm identifiers, and I hope it will be algorithm >independent too. In the case of signatures, algorithm independence >would require that we not rely on the reversability of RSA signatures, >i.e., the ability to recover the signed data from the signature value. >A generic signature validation mechanism begins by (locally) computing >the hash on the (purportedly) signed data. That input, the public key >and any algorithm parameters of the signer, plus the signature value >itself is input to a signature verification routine. The routine then >outputs true or false, i.e., the signature is valid or invalid. After much though, I have decided that I agree that it should be possible to use non-reversible signature schemes and the next draft will explain how. But I don't see any reason to throw away the factor or two or more space efficiency made possible by exploiting the invertibility of RSA signatures. I reject your insistance that the piece of the algorithmic ensemble which changes with the algorithm version must be limited to the small part having the input/output characteristics you describe. >Steve Donald From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: kent@bbn.com, dns-security@tis.com In-Reply-To: <9404260237.AA17332@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 25, 94 10: 37 pm >> > For exmaple, ElGamal is an alternative signature algorithm >> >which is not itself patented, but which is embraced by the fundamental >> >Diffie-Hellman public key patent that expires in 1997 (I believe). >> >ElGamal is not very efficient, but it is an alternative that has a >> >shorter duration patent status relative to RSA. >> >> Looks to me like ElGamal would produce signatures that were twice as >> big > >Wrong. > >Agaist the simple enumeration attack, ElGamal with a 512 bit prime which >requires a 1024 bit signature is just as secure as RSA with two 512 bit >primes which also requires a 1024 bit signature. My point was that you can only sign something half as big with ElGamal. I.E., about 512 bits as opposed to 1024 in this case >> and took at least a *hundred* and in some cases over a *thousand* >> times more computation effort to verify than profiled RSA. > >That's true. But, in the security conscious enviroment where secure >DNS is required, we need to compute a lot of on-line signature outside >of DNS. Generation of RSA signature is almost as slow as generation >of signature and verification of ElGamal. > >So, if ElGamal is unusably slow, RSA is also unusable, isn't it? No at all. The point is that with DNS there will be zillions of signature *verifications*. With RSA you can control whether signing or verification is more computation intensive. With El Gamal you are stuck with expensive verification. With a small bounded public exponent RSA, the cost of verification goes up only with the square of the modulus size. (The cost of signing goes up with the cube and the cost of key generation goes up with the fourth power.) With El Gamal, verification will go up with the third power of the key (not the third power of the key length!). This is a huge difference. >Fortunately, the working set of the computation is quite small and >completely included in on-chip cache. That is, signature computation >speed is assured to become faster and faster as CPU speed increases. Yes, but by the time CPU speed has increased enough to overcome such large multiple-orders-of-magnitude speed differences, the patent will have expired anyway so the whole point of going to El Gamal goes away. >... > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24711; 7 Jun 94 10:46 EDT Received: by relay.tis.com id AA12606; Tue, 7 Jun 94 10:43:23 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma012599; Tue Jun 7 10:42:24 1994 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06643; Tue, 7 Jun 94 10:46:21 EDT Received: by relay.tis.com id AA12596; Tue, 7 Jun 94 10:42:23 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3) id sma012576; Tue Jun 7 10:41:46 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Jun 94 23:38:47 +0859 From: Masataka Ohta Return-Path: Message-Id: <9406071439.AA16645@necom830.cc.titech.ac.jp> Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) To: "Donald E. Eastlake 3rd" Date: Tue, 7 Jun 94 23:38:45 JST Cc: dns-security@tis.com In-Reply-To: <9406071247.AA21968@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Jun 7, 94 8:47 am X-Mailer: ELM [version 2.3 PL11] > >> Looks to me like ElGamal would produce signatures that were twice as > >> big > >Wrong. > My point was that you can only sign something half as big with ElGamal. > I.E., about 512 bits as opposed to 1024 in this case Yes, your point was valid when you were insisting to have reversible sign on raw data with RSA. When signing a single MD5 signature, ElGamal is as compact as RSA. > >So, if ElGamal is unusably slow, RSA is also unusable, isn't it? > > No at all. The point is that with DNS there will be zillions of > signature *verifications*. Your point is well taken. My point is that, in the age when DNS needs zillions of signature verifications, systems outside of DNS should need zillions of signature generations. > With RSA you can control whether signing > or verification is more computation intensive. With El Gamal you are > stuck with expensive verification. True. > With a small bounded public exponent RSA, the cost of verification > goes up only with the square of the modulus size. (The cost of > signing goes up with the cube and the cost of key generation goes up > with the fourth power.) OK. Without Strassen-Shoenhage, computation of the exponential for signature generation takes the third power of the modulus' length (= the signature's length). > With El Gamal, verification will go up with > the third power of the key (not the third power of the key length!). What? My understanding is that: ElGamal verification consists of three exponentials, one multiplication and one comparison with some prime modulus. Computation of the exponentials takes the third power of the prime's length (= half the signature's length). So, how can you say that the time complexity is of the third power of the key? > This is a huge difference. If it were "the third power of the key" or even "square root of the key", I agree. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa21125; 12 Jun 94 12:36 EDT Received: by relay.tis.com id AA02974; Sun, 12 Jun 94 12:30:17 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma002959; Sun Jun 12 12:29:21 1994 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10583; Sun, 12 Jun 94 12:36:20 EDT Received: by relay.tis.com id AA02954; Sun, 12 Jun 94 12:29:16 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma002942; Sun Jun 12 12:28:49 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 13 Jun 94 01:29:13 +0900 From: Masataka Ohta Return-Path: Message-Id: <9406121629.AA10641@necom830.cc.titech.ac.jp> Subject: Another Draft To: dns-security@tis.com Date: Mon, 13 Jun 94 1:29:11 JST X-Mailer: ELM [version 2.3 PL11] The draft below is on another framework of secure DNS, which is designed to be, as I promised, perfectly royal to the existing DNS architecture. For example, referral mechanism is no different from the current one. It is algorithm independent. It is simple, that is, contains no flag bits. It contains suggestion on how dynamic update and secure DNS should interact. Any comments? Masataka Ohta ------------------------------------------------------------------------ DNS Protocol Extension for Security 1. Introduction The purpose of the secure DNS protocol extension is to make data from DNS authenticated. In general, security has two aspects, authentication to make data unforgable and confidentiality to make data secret. As the fundamental role of DNS is to make its database available all around the world, no confidentiality is considered in this document. IQUERY, an optional feature of DNS, is inherently insecure, and not considered in this document. This document is written with the assumption that readers thoroughly understand the existing DNS described in RFC 1034 and RFC 1035. On the other hand, little knowledge on cryptography is assumed. To make DNS secure, two cryptographic mechanisms: digesting and signature, are combined. Digesting is the mechanism to compute a short digest of a byte stream. The mechanism should be complex enough so that, given a digest value of some byte stream, it should be practically impossible to forge a different byte stream which has the same digest value. The other is the mechanism to give signature to a byte stream with some secret information. The mechanism should be complex enough so that, given a signature value of some data and the original data itself, it should be practically impossible to guess the secret information. The signature can be verified by sharing secret information between related parties or by using private/public key technology. This document does not specify the actual mechanisms to generate digests and signatures. As long as the above two basic authentication mechanisms are reliable, secure DNS is designed to be reliable against all forms of attacks save the denial of service attacks of the most basic form, which is least harmful. That is, the secure DNS may report a temporal failure against some form of denial of service attacks. But all the answers other than the temporal failure is reliable to the extent that the basic authentication mechanisms up to the root or other locally reliable zones are reliable. For example, if a resolver can communicate with no name servers because of some attack such as unplugging of cables, the only thing the resolver can do is to report the temporal failure, which is one of the most basic form of a denial of service attack. On the other hand, secure DNS can securely report negative answers that a node does not exists or that an RR type does not exist for a given node. Authentication is provided zone wise. A secure zone is a zone whose June 13, 1994 [Page 1] - 2 - authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. For the maximum security, both the secret information and the signature generation mechanism of a zone should be kept off-line. In this case, even if on-line name servers of the zone is compromised, security on the DNS information of the zone is not compromised. In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. Though the secure DNS can be a authenticated source of information to establish secure communication between hosts, it is out of the scope of this document and a separate document should be provided. A security aware name server is a name server which can perform authenticated communication between security aware name servers and resolvers in a way specified in this document. A security aware resolver is a resolver which can retrieve authenticated DNS data in secure zones. A security aware resolver is configured with a list of security aware name servers which is considered to be reliable. The resolver also has information to make authenticated communication with the reliable name servers, whose actual mechanism should be identical or parallel to secure IP and is not discussed in this document. The protocol in this document is carefully designed so that existing name servers can cooperate with security aware resolvers and name servers. 2. Changes to the Existing Mechanism Important changes to the existing DNS architecture described in RFC 1034 and RFC 1035 are: A new OPCODE, NCQUERY, is added to retrieve authentication information of a node containing CNAME. As authentication information on a node of CNAME is added as other records of the node, it is necessary to have an opcode to suppress CNAME processing. As a side effect, it is now possible to have a zone which consists of a single CNAME node, which also have SOA and NS June 13, 1994 [Page 2] - 3 - records. [Note: Though it is possible to add new query types which matches CNAME and other RRs in the node, it is not so clean. Moreover, as authentication data is usually large, it may cause UDP packetsize overflow]. SD (Security Desired) bit is added to DNS packets for query. Though a name server is free to ignore the bit, the secure resolvers expects their reliable name servers return secure answer. The bit may also affect additional section processing. SA (Security Assured) bit is added to DNS packets for answer, which means that a name server who answers the question assures that all the data in the answer section is secure. MINTTL fields of SOA RRs no longer mean the actual minimal TTLs nor negative caching periods. They, instead, mean default TTLs. 3. New Data Types New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG and ZL are added to secure zones. Actual RR type names or values for the data and their syntax may vary according to specific authentication algorithm. Detailed explanation, including the actual RR type values for new data types, are not given in this document. Square bracketed notation "[RR]" is used to designate a instance of a new data type "RR". In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. June 13, 1994 [Page 3] - 4 - is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with (original TTL). When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. Still, it is necessary to have [RRD] of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. NSIG (Node SIGnature) Signature on RRD computed using secret information of the zone, added to secure nodes. [NSIG] RRs have the following syntax: [NSIG] where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or KERBEROS), is the time when the signature is computed. is the number of seconds the signature will be valid after . and are 32 bit quantities. is of variable length. Throughout the document, time is a 32 bit quantity, unless otherwise specified. Absolute time is counted by the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and wraps around after 2^32 seconds (about 136 years). As the 32 bit time value circulates, zone's secret information should be changed at least once per 50 years. Otherwise, stale data signed 136 years ago may be distributed with a valid signature. June 13, 1994 [Page 4] - 5 - When computing ; , and of [RRD] are serialized with the byte order used in DNS packets and the resulting byte stream is signed by the zone's signature mechanism(s). No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. ZA (Zone Authenticator) Data added to a secure zone to specify how to verify NSIGs of nodes within the zone. [ZA] RRs have the following syntax: [ZA] where [ZA] is the RR name of ZA, is the time from when the is used. is 32 bit absolute time. is of variable length. The actual content of varies by the authentication algorithm. It may be a public key of the zone or IP addresses of authentication centers of the zone which maintains secret information of related parties. field is useful to smoothly change zone's secret information. Usually, a zone has only one record of [ZA] type. But, a zone may have two such records when zone's secret information is being changed. Otherwise, authentication of RRs signed before the change fails with a new . If multiple [ZA]s exist during the transition, field of NSIG is compared to the fields in [ZA]s to select the [ZA] actually used for the signature. Older [ZA] should disappear after all the signature signed with it is assured to have expired. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. June 13, 1994 [Page 5] - 6 - ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . , and are the same as that of [NSIG] except that the signature covers the sequence of , where is the field of [RRD] of [ZA] a signed zone. In general, only a who is a parent or ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s according to their local security policy. For the root zone or locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. ZL (Zone List) data used to list all the nodes in a zone with small authentication granulity. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. ZL will have the following syntax. [ZL] ... where [ZL] is the RR name of ZL data, is the number of seconds appropriate for negative caching, is the number of domains covered by the record. The record contains all the domain names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) and before sorted with dictionary order. and is merely a separator and should not be interpreted that such a node exists unless explicitly listed as . Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last. Within labels, first bytes are compared first. Thus, the name of the June 13, 1994 [Page 6] - 7 - zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as , it is considered to be ordered after all the other names in the domain. For example, [ZL] 0 represents a zone consisting of only a single node. and are two byte integers. , , , ..., have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). , and are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of ... contained in the [ZL] record itself. 4. Name Server Operation Changes to the operation of name servers is minimal. A primary name server of a zone has access to signature mechanisms of the zone and derives authenticated data from them. A secondary name server is configured with IP addresses of other name servers from which zone information is transferred. It also have digest of ZA to authenticate zone transfers. So, if the primary server is compromised, secondary servers can detect it and reject bogus zone transfers and can continue operation with older information. The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the following description: The actual algorithm used by the secure name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: 0. If SD bit is not set, use the original algorithm in RFC June 13, 1994 [Page 7] - 8 - 1034. Otherwise, set SA bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available secure zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node contains a CNAME, and QTYPE doesn't match CNAME and OPCODE is not NCQUERY, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put authenticated addresses available from authoritative data or the cache. If they are unavailable, use glue RRs, if they exists. Go to step 4. c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response. Put at least one RR of ZL data containing the name being looked for in the additional June 13, 1994 [Page 8] - 9 - section. If there are a lot of ZL data, truncation is expected. Exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label unless the query type is of [RRD]. Go to step 6. 4. Start matching down in the cache. If authenticated QNAME is found in the cache, copy all authenticated RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. 5. Using the local resolver or a copy of its algorithm (see resolver section of this document) answer the query and set or reset SA bit appropriately. Store the results, including any intermediate CNAMEs, in the answer section of the response. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. For secure zone transfer, new query types [SXFR] are added. The actual name and value of [SXFER] depends on the authentication mechanism used. It is assumed that each secondary server is statically configured with digest of ZA of a zone it serves. A secure zone transfer is a byte stream with the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone data | |s | | |t | | |e +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ June 13, 1994 [Page 9] - 10 - The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the signature of the transferred zone. Unlike AXFER, [SXFER] uses four bytes for zone data length to transfer large zones such as "com.". 5. Resolver 5.1 Client-Resolver Interface Client programs tells security requirements to the resolver. The requirement includes whether they need security or not and which digesting or signature mechanism they consider reliable. 5.2. Data Structures The resolver algorithm in the next subsection assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: SNAME the domain name we are searching for. STYPE the QTYPE of the search request. SCLASS the QCLASS of the search request. SLIST a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, [ZA] and [ZSIG] of the zone if the zone is secure, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. SBELT a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The resolver thinks those name June 13, 1994 [Page 10] - 11 - servers reliable. The configuration file also contains information, such as shared secret or digest of public key, for authenticated communication to the reliable name servers. The match count will be -1 to indicate that no labels are known to match. CACHE A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. The cache also contains information whether the RR is considered to be authenticated by the resolver. In the CACHE, authenticated RR has precedence over unauthenticated RR. 5.3 Resolver Algorithm The four step algorithm in the section "5.3.3. Algorithm" of RFC 1034 must be replaced with the following: The top level algorithm has four steps: 1. See if the answer is in local secure information, and if so return it to the client. 2. Find the best servers to ask. 3. Send them queries with SD bit set until one returns a response. 4. Analyze the response, either: a. if the response answers the question or contains a name error, try to authenticate it, cache the data and other authentication information as well as returning the answer back to the client. b. if the response contains a better delegation to other servers, try to retrieve and authenticate ZSIG and ZA of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. June 13, 1994 [Page 11] - 12 - c. if the response shows a CNAME and that is not the answer itself, try to authenticate the CNAME, cache the CNAME and other authentication information, change the SNAME to the canonical name in the CNAME RR and go to step 1. d. if the response shows a servers failure, an authentication failure or other bizarre contents, delete the server from the SLIST and go back to step 3. Authentication by resolvers are done as follows: 1. If the answer is obtained from one of the trusted name servers through authenticated communication channel and SA bit is set, or if the answer is in the authoritative data of the name server co-located with the resolver, no authentication is necessary. 2. For NSIG or ZSIG, no authentication check is necessary, though authentication failure with cached NSIG or ZSIG should invalidate the cached information. 3. To authenticate RRD, use NSIG and authenticated ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate ZA, use RRD of ZA and ZSIG. 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. 7. if the response is a name error, that is, the queried node does not exist, confirm it by authenticating ZL data in the additional section of the response. 8. if the response is a data not found error, that is, the query does not match any RR type of the node, retrieve all the authenticated RRD type records of the node and confirm that they don't contain RR types which matches the query. Authentication chains between zones have the following structure: June 13, 1994 [Page 12] - 13 - digest ZA of well known signer zone------>digest value statically | configured in name | servers | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<----------RRD of ZA Figure 1. Authentication Chains of Zone Data Authentication chains within a zone have the following structure: ZA of the Node's Zone | | | signature NSIG<---------RRD of RR type RRD ^ |digest | RRD of RR type ^ |digest | RR with RR type other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5. Secure Time and Secure DNS DNS is designed to be highly fault tolerant. That is, if a secondary server can't communicate with other servers, the secondary server can behave as authoritative until SOA period is reached. Thus, June 13, 1994 [Page 13] - 14 - until a resolver securely knows that period has passed, a name server may give old but authenticated answer to a query whose node does not exist. Thus, period should be minimized. Moreover, clocks of signers and resolvers should be accurate enough. It is recommended that signers clock should have maximum allowable error of /20. When resolvers caching information, it should be confirmed that cached period is shorter than and *19/20 minus the expected maximum error of the resolvers' clocks fractions rounded down. Due to clock skew, a resolver may receive a dated in the future. The data should be relied if the error is below /10 plus the expected maximum error of the resolvers' clocks fractions rounded down. 6. Secure DNS and Additional Section Processing To authenticate DNS reply on a certain node, a lot of information about the node is necessary. Such information may be provided in the additional section. On the other hand, though the existing DNS suggests to add various information in the additional section, data on nodes which is not queried needs, such as additional As for MX, are not so useful if they can't be authenticated. Thus, for secure DNS, it is recommended to add additional information with the following preference as long as the addition won't make the reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. the node of the added information is same as the nodes of the query. other additional information. 7. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting June 13, 1994 [Page 14] - 15 - a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] Ranges of 256 RR type values are reserved by IANA for the actual values of [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] as follows: [RRD] X [NSIG] X+256 [ZA] X+512 [ZSIG] X+768 [ZL] X+1024 [SXFR] X+1280 where X is between Y and Y+255 (Y is to be determined by IANA). [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X forms a single set of specification. Even if two specifications share the same digesting mechanism, it has different [RRD] values. June 13, 1994 [Page 15]   Received: from sol.tis.com by magellan.TIS.COM id aa12404; 13 Jul 94 13:16 EDT Received: from quern.epilogue.com(128.224.1.136) by relay via smap (V1.3) id sma006515; Wed Jul 13 13:14:30 1994 Received: from sra.worf.epilogue.com with DMSP Date: 13 Jul 1994 12:13:48 -0500 From: Rob Austein Sender: sra@worf.epilogue.com To: dns-security@tis.com Subject: Re: Another Draft Repository: quern.epilogue.com Originating-Client: worf.epilogue.com Message-Id: <9407131315.aa22954@quern.epilogue.com> Ok, I read Ohta-san's draft. On the whole, I liked it, the mechanism is more in keeping with "traditional DNS" than Donald and Charlie's (no offense, guys), and it doesn't have the dependency on RSA that seems to worry so many people. The section on the ZL RR type(s) needs some work. I *think* I get it after having read it four times, but I'm still not sure.... In several places the draft refers to "dictionary order". Does this mean case-insensitive lexiographic order, or case-sensitive lexiographic order, or what? Since DNS name lookups have this weird property of preserving but ignoring case of alphabetic characters, the draft needs to be more explicit about how alphabetic case is handled. I can see two possibilties: 1) We continue the DNS model of preserved-but-ignored case. I think this means we chose to live with some spurious authentication failures due to case differences. 2) We pick a canonical case (upper or lower, I don't care) and do all digesting in canonical case. Last, I would like to hear feedback from other members of the DNSSEC WG. Is Ohta-san's proposal a good idea? Is it flawed in some obvious way that I've missed due to insufficient coffee? Is everybody just tired of this subject? --Rob Austein   Received: from sol.tis.com by magellan.TIS.COM id aa20046; 14 Jul 94 10:31 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma015828; Thu Jul 14 10:12:33 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 14 Jul 94 23:06:10 +0900 From: Masataka Ohta Return-Path: Message-Id: <9407141406.AA18047@necom830.cc.titech.ac.jp> Subject: Re: Another Draft To: Rob Austein Date: Thu, 14 Jul 94 23:06:09 JST Cc: dns-security@tis.com In-Reply-To: <9407131315.aa22954@quern.epilogue.com>; from "Rob Austein" at Jul 13, 94 12:13 pm X-Mailer: ELM [version 2.3 PL11] > The section on the ZL RR type(s) needs some work. I *think* I get it > after having read it four times, but I'm still not sure.... OK, I'll try. > Since DNS name lookups have this weird property of preserving but > ignoring case of alphabetic characters, the draft needs to be more > explicit about how alphabetic case is handled. I can see two > possibilties: > 1) We continue the DNS model of preserved-but-ignored case. I > think this means we chose to live with some spurious > authentication failures due to case differences. Good point. So, we should make all domain names have the canonical case. > 2) We pick a canonical case (upper or lower, I don't care) and do > all digesting in canonical case. Or, we may change the DNS model to preserved-and-sensitive, which needs three non-overlapping stages for the smooth conversion: a) make all primaries produce canonical case answer b) make all nameservers, resolvers and hostname comparison routines preserve-and-sensitive c) make all primaries preserve case that I don't think it's worth doing (unless we want to support non-ASCII characters, where there is no proper case insensitivity definable). Considering that 2) is identical to a), 2) should be the way to go at least for the time being. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09434; 20 Jul 94 8:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma019888; Wed Jul 20 08:51:09 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Jul 94 21:45:46 +0859 From: Masataka Ohta Return-Path: Message-Id: <9407201246.AA17508@necom830.cc.titech.ac.jp> Subject: Re: Another Draft (revised) To: dns-security@tis.com Date: Wed, 20 Jul 94 21:45:44 JST X-Mailer: ELM [version 2.3 PL11] According to Rob's suggeestion, I have revised my proposal. Important changes are: Canonical case> Added explanation on ZL Standard upper limit of one week on Any comments? Masataka Ohta ------------------------------------------------------------------------ DNS Protocol Extension for Security 1. Introduction The purpose of the secure DNS protocol extension is to make data from DNS authenticated. In general, security has two aspects, authentication to make data unforgable and confidentiality to make data secret. As the fundamental role of DNS is to make its database available all around the world, no confidentiality is considered in this document. IQUERY, an optional feature of DNS, is inherently insecure, and not considered in this document. This document is written with the assumption that readers thoroughly understand the existing DNS described in RFC 1034 and RFC 1035. On the other hand, little knowledge on cryptography is assumed. To make DNS secure, two cryptographic mechanisms: digesting and signature, are combined. Digesting is the mechanism to compute a short digest of a byte stream. The mechanism should be complex enough so that, given a digest value of some byte stream, it should be practically impossible to forge a different byte stream which has the same digest value. The other is the mechanism to give signature to a byte stream with some secret information. The mechanism should be complex enough so that, given a signature value of some data and the original data itself, it should be practically impossible to guess the secret information. The signature can be verified by sharing secret information between related parties or by using private/public key technology. This document does not specify the actual mechanisms to generate digests and signatures. As long as the above two basic authentication mechanisms are reliable, secure DNS is designed to be reliable against all forms of attacks save the denial of service attacks of the most basic form, which is least harmful. That is, the secure DNS may report a temporal failure against some form of denial of service attacks. But all the answers other than the temporal failure is reliable to the extent that the basic authentication mechanisms up to the root or other locally reliable zones are reliable. For example, if a resolver can communicate with no name servers because of some attack such as unplugging of cables, the only thing the resolver can do is to report the temporal failure, which is one of the most basic form of a denial of service attack. On the other hand, secure DNS can securely report negative answers that a node does not exists or that an RR type does not exist for a given node. Authentication is provided zone wise. A secure zone is a zone whose July 20, 1994 [Page 1] - 2 - authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. For the maximum security, both the secret information and the signature generation mechanism of a zone should be kept off-line. In this case, even if on-line name servers of the zone is compromised, security on the DNS information of the zone is not compromised. In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. Though the secure DNS can be a authenticated source of information to establish secure communication between hosts, it is out of the scope of this document and a separate document should be provided. A security aware name server is a name server which can perform authenticated communication between security aware name servers and resolvers in a way specified in this document. A security aware resolver is a resolver which can retrieve authenticated DNS data in secure zones. A security aware resolver is configured with a list of security aware name servers which is considered to be reliable. The actual mechanism for the communication between a security aware resolver and relied name server should be identical or parallel to secure IP and its detail is not discussed in this document. The problem is that security aware resolver can not rely on secure DNS. So, if secure IP relies on secure DNS, the security aware resolver should use statically configured information, instead. The protocol in this document is carefully designed so that existing name servers can cooperate with security aware resolvers and name servers. 2. Changes to the Existing Mechanism Important changes to the existing DNS architecture described in RFC 1034 and RFC 1035 are: A new OPCODE, NCQUERY, is added to retrieve authentication information of a node containing CNAME. As authentication information on a node of CNAME is added as other records of the July 20, 1994 [Page 2] - 3 - node, it is necessary to have an opcode to suppress CNAME processing. As a side effect, it is now possible to have a zone which consists of a single CNAME node, which also have SOA and NS records. [Note: Though it is possible to add new query types which matches CNAME and other RRs in the node, it is not so clean. Moreover, as authentication data is usually large, it may cause UDP packetsize overflow]. SD (Security Desired) bit is added to DNS packets for query. Though a name server is free to ignore the bit, the secure resolvers expects their reliable name servers return secure answer. The bit may also affect additional section processing. SA (Security Assured) bit is added to DNS packets for answer, which means that a name server who answers the question assures that all the data in the answer section is secure. MINTTL fields of SOA RRs no longer mean the actual minimal TTLs nor negative caching periods. They, instead, mean default TTLs. Cases are canonicalized to use only upper case characters. Lower case characters are converted to upper case in primary servers. The canonicalization is necessary to compute a consistent signature or digest value. 3. New Data Types New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG and ZL are added to secure zones. Actual RR type names or values for the data and their syntax may vary according to specific authentication algorithm. Detailed explanation, including the actual RR type values for new data types, are not given in this document. Square bracketed notation "[RR]" is used to designate a instance of a new data type "RR". In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted July 20, 1994 [Page 3] - 4 - throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with (original TTL). When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. Still, it is necessary to have [RRD] of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. NSIG (Node SIGnature) Signature on RRD computed using secret information of the zone, added to secure nodes. [NSIG] RRs have the following syntax: [NSIG] where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or KERBEROS), is the time when the signature is computed. is the number of seconds the signature will be valid after . and are 32 bit quantities. is of July 20, 1994 [Page 4] - 5 - variable length. Throughout the document, time is a 32 bit quantity, unless otherwise specified. Absolute time is counted by the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and wraps around after 2^32 seconds (about 136 years). As the 32 bit time value circulates, zone's secret information should be changed at least once per 50 years. Otherwise, stale data signed 136 years ago may be distributed with a valid signature. When computing ; , and of [RRD] are serialized with the byte order used in DNS packets and the resulting byte stream is signed by the zone's signature mechanism(s). No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. ZA (Zone Authenticator) Data added to a secure zone to specify how to verify NSIGs of nodes within the zone. [ZA] RRs have the following syntax: [ZA] where [ZA] is the RR name of ZA, is the time from when the is used. is 32 bit absolute time. is of variable length. The actual content of varies by the authentication algorithm. It may be a public key of the zone or IP addresses of authentication centers of the zone which maintains secret information of related parties. field is useful to smoothly change zone's secret information. Usually, a zone has only one record of [ZA] type. But, a zone may have two such records when zone's secret information is being changed. Otherwise, authentication of RRs signed before the change fails with a new . If multiple [ZA]s exist during the transition, field of July 20, 1994 [Page 5] - 6 - NSIG is compared to the fields in [ZA]s to select the [ZA] actually used for the signature. Older [ZA] should disappear after all the signature signed with it is assured to have expired. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . , and are the same as that of [NSIG] except that the signature covers the sequence of , where is the field of [RRD] of [ZA] a signed zone. In general, only a who is a parent or ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s according to their local security policy. For the root zone or locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) July 20, 1994 [Page 6] - 7 - needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". ZL will have the following syntax. [ZL] ... where [ZL] is the RR name of ZL data, is the number of seconds appropriate for negative caching, is the number of domains covered by the record. The record contains all the domain names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) and before sorted with dictionary order. and is merely a separator and should not be interpreted that such a node exists unless explicitly listed as . Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last, which makes domain name compression work quite well. Within labels, first bytes are compared first. Thus, the name of the zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as , it is considered to be ordered after all the other names in the domain. For example, [ZL] 0 represents a zone consisting of only a single node. and are two byte integers. , , , ..., have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). , and are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of ... contained in the [ZL] record itself. 4. Name Server Operation Changes to the operation of name servers is minimal. A primary name server of a zone has access to signature mechanisms of the zone and derives authenticated data from them. A secondary name server is configured with IP addresses of other name servers from which zone information is transferred. It also have digest of ZA to authenticate zone transfers. So, if the primary server is compromised, secondary servers can detect it and reject bogus zone transfers and can continue operation with older information. The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the following description: The actual algorithm used by the secure name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: 0. If SD bit is not set, use the original algorithm in RFC 1034. Otherwise, set SA bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available secure zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node contains a CNAME, and QTYPE doesn't match CNAME and OPCODE is not NCQUERY, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, July 20, 1994 [Page 8] - 9 - and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put authenticated addresses available from authoritative data or the cache. If they are unavailable, use glue RRs, if they exists. Go to step 4. c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label unless the query type is of [RRD]. Go to step 6. 4. Start matching down in the cache. If authenticated QNAME is found in the cache, copy all authenticated RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. 5. Using the local resolver or a copy of its algorithm (see resolver section of this document) answer the query and set or reset SA bit appropriately. Store the results, including any intermediate CNAMEs, in the answer section of the response. July 20, 1994 [Page 9] - 10 - 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. For secure zone transfer, new query types [SXFR] are added. The actual name and value of [SXFER] depends on the authentication mechanism used. It is assumed that each secondary server is statically configured with digest of ZA of a zone it serves. A secure zone transfer is a byte stream with the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone data | |s | | |t | | |e +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the signature of the transferred zone. Unlike AXFER, [SXFER] uses four bytes for zone data length to transfer large zones such as "com.". 5. Resolver 5.1 Client-Resolver Interface Client programs tells security requirements to the resolver. The requirement includes whether they need security or not and which digesting or signature mechanism they consider reliable. 5.2. Data Structures The resolver algorithm in the next subsection assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: SNAME the domain name we are searching for. July 20, 1994 [Page 10] - 11 - STYPE the QTYPE of the search request. SCLASS the QCLASS of the search request. SLIST a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, [ZA] and [ZSIG] of the zone if the zone is secure, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. SBELT a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The resolver thinks those name servers reliable. The configuration file also contains information, such as shared secret or digest of public key, for authenticated communication to the reliable name servers. The match count will be -1 to indicate that no labels are known to match. CACHE A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. The cache also contains information whether the RR is considered to be authenticated by the resolver. In the CACHE, authenticated RR has precedence over unauthenticated RR. 5.3 Resolver Algorithm July 20, 1994 [Page 11] - 12 - The four step algorithm in the section "5.3.3. Algorithm" of RFC 1034 must be replaced with the following: The top level algorithm has four steps: 1. See if the answer is in local secure information, and if so return it to the client. 2. Find the best servers to ask. 3. Send them queries with SD bit set until one returns a response. 4. Analyze the response, either: a. if the response answers the question or contains a name error, try to authenticate it, cache the data and other authentication information as well as returning the answer back to the client. b. if the response contains a better delegation to other servers, try to retrieve and authenticate ZSIG and ZA of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. c. if the response shows a CNAME and that is not the answer itself, try to authenticate the CNAME, cache the CNAME and other authentication information, change the SNAME to the canonical name in the CNAME RR and go to step 1. d. if the response shows a servers failure, an authentication failure or other bizarre contents, delete the server from the SLIST and go back to step 3. Authentication by resolvers are done as follows: 1. If the answer is obtained from one of the trusted name servers through authenticated communication channel and SA bit is set, or if the answer is in the authoritative data of the name server co-located with the resolver, no authentication is necessary. 2. For NSIG or ZSIG, no authentication check is necessary, though authentication failure with cached NSIG or ZSIG should invalidate the cached information. July 20, 1994 [Page 12] - 13 - 3. To authenticate RRD, use NSIG and authenticated ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate ZA, use RRD of ZA and ZSIG. 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. 7. if the response is a name error, that is, a node which matches query does not exist, confirm it by authenticating ZL data in the additional section of the response. For example, to authenticate that data matching "a.b.c.d." dose not exist in a zone "c.d.", it should be confirmed that nodes "a.b.c.d." and "*.b.c.d" do not exist but "b.c.d." does exist. Depending on the zone's structure (whether "b.c.d." exists or not), the same thing may be confirmed by the fact that nodes "a.b.c.d.", "*.b.c.d", "b.c.d" and "*.c.d" do not exist. 8. if the response is a data not found error, that is, the query does not match any RR type of the node, retrieve all the authenticated RRD type records of the node and confirm that they don't contain RR types which matches the query. Authentication chains between zones have the following structure: digest ZA of well known signer zone------>digest value statically | configured in name | servers | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<---------RRD of ZA of signer zone | | July 20, 1994 [Page 13] - 14 - | signature ZSIG<----------RRD of ZA Figure 1. Authentication Chains of Zone Data Authentication chains within a zone have the following structure: ZA of the Node's Zone | | | signature NSIG<---------RRD of RR type RRD ^ |digest | RRD of RR type ^ |digest | RR with RR type other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5. Secure Time and Secure DNS DNS is designed to be highly fault tolerant. That is, if a secondary server can't communicate with other servers, the secondary server can behave as authoritative until SOA period is reached. Thus, until a resolver securely knows that period has passed, a name server may give old but authenticated answer to a query whose node does not exist. Thus, period should be minimized. Moreover, clocks of signers and resolvers should be accurate enough. It is recommended that signers clock should have maximum allowable error of /20. When resolvers caching information, it should be confirmed that cached period is shorter than and *19/20 fractions rounded down minus the expected maximum error of the resolvers' clocks. Due to clock skew, a resolver may receive a dated in the future. The data should be relied if the error is below /10 July 20, 1994 [Page 14] - 15 - fractions rounded down plus the expected maximum error of the resolver's clocks. To have an Internet wide upper bound on the life time of stale data, longer than a week should be shortened to a week. 6. Secure DNS and Additional Section Processing To authenticate DNS reply on a certain node, a lot of information about the node is necessary. Such information may be provided in the additional section. On the other hand, though the existing DNS suggests to add various information in the additional section, data on nodes which is not queried needs, such as additional As for MX, are not so useful if they can't be authenticated. Thus, for secure DNS, it is recommended to add additional information with the following preference as long as the addition won't make the reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. the node of the added information is same as the nodes of the query. other additional information. 7. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] Ranges of 256 RR type values are reserved by IANA for the actual values of [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] as follows: [RRD] X [NSIG] X+256 [ZA] X+512 July 20, 1994 [Page 15] - 16 - [ZSIG] X+768 [ZL] X+1024 [SXFR] X+1280 where X is between Y and Y+255 (Y is to be determined by IANA). [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X form a single set of specification. Even if two specifications share the same digesting mechanism, it has different [RRD] values. July 20, 1994 [Page 16]   Received: from sol.tis.com by magellan.TIS.COM id aa27348; 21 Jul 94 16:31 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma002513; Thu Jul 21 16:29:19 1994 Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA08788; Thu, 21 Jul 94 16:31:02 EDT Message-Id: <9407212031.AA08788@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: Agenda for Toronto IETF Date: Thu, 21 Jul 1994 16:31:08 -0400 From: James M Galvin The DNS Security Working Group has a meeting scheduled for Wednesday, July 27, 1994, at 9:30am. There are at least 4 items on the agenda: o report on implementation by Jim Galvin o presentation by Masataka Ohta on his proposal and how it differs from Eastlake/Kaufman (I invited this presentation) o comments from Donald Eastlake/Charlie Kaufman (I haven't asked you guys yet about this but I figured you should have an opportunity to comment on presentations thus far if you want it) o identifying the proposal to follow through with from this point With respect to the fourth item, our Charter says that we will submit a proposal for security enhancements after this meeting. This proposal is subject to review until the next IETF in November at which time we'll submit it to the IESG. Since we now have two proposals on the table we need to discuss them with the objective of choosing one of or merging them into one proposal. Should the working group decide that neither is satisfactory, we'll need to be prepared to defend that position and have a specific and precise statement of exactly what we need in the next proposal. See you in Toronto, Jim Chair of the DNS Security Working Group   Received: from sol.tis.com by magellan.TIS.COM id aa04538; 25 Jul 94 16:56 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma028813; Mon Jul 25 16:55:49 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA08433; Mon, 25 Jul 94 13:42:08 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA18776; Mon, 25 Jul 1994 16:45:01 -0400 Message-Id: <9407252045.AA18776@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: Charlie Kaufman Subject: draft-ietf-dnssec-as-map-00.txt Date: Mon, 25 Jul 94 16:45:01 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp INTERNET-DRAFT Mapping A.S. Number into the DNS 25 July 1994 Expires 26 January 1995 Mapping Autonomous Systems Number into the Domain Name System ------- ---------- ------- ------ ---- --- ------ ---- ------ Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnssec-as-map-00.txt, is intended to be become an informational RFC. [Or should it be standards track if it is a significant part of routing security?] Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list [is there also a router [WG?] mailing list is should be sent to?] or to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Abstract One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see draft-ietf-dnssec- secext-*.txt) to the Domain Name System will enable it to be used for convenient public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Acknowledgements The significant contributions of the following persons to this draft are gratefully acknowledged: Ran Atkinson. Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................4 2. Autonomous System Number Mapping........................5 3. Meaning of RRs..........................................6 4. Security Considerations.................................7 References.................................................7 Author's Address...........................................8 Expiration and File Name...................................8 Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 1. Introduction There are a number of elements that will be required to secure routing in the Internet. One of these is a way that independently operated top level routing domains be able to authenticate messages to each other. Sharing a private symmetric key between each pair of such domains is impractical. The Automonous System numbering scheme provides for 2**16 such domains which implies approximately 2**31 pairs, an impractical number of keys to securely generate, install, and periodically replace. The solution is to use public key technology whereby each domain has a private key it can use to sign messages. Other domains that know the corresponding public key can then authenticate these messages. Such authenticated messages can be used to set up and replace efficient symmetric keys on an as needed basis. But how do the domains securely obtain the Autonimous System number to public key mapping? Extensions currently being developed for the Domain Name System will enable it to be conveniently used for authenticated public key distribution (see draft-ietf-dnssec-secext-*.txt). All that is required is a mapping of Autonimous System numbers into domain names, which is provided by this draft. It should be noted that the public keys retrieved from DNS will likely be used mostly to authenticate only initial set up messages. Autonimous Systems that need to converse with any frequency will probably negotiate more efficient session keys. Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 2. Autonomous System Number Mapping Autonomous System (A.S.) numbers are 16 bit quantities. The A.S. number is mapped into a domain name as follows: (1) write the A.S. as a four digit hex number (with leading zeros if necessary), (2) reverse these digits and separated them with dots, and (3) append ".in-as.arpa" to them. Thus the domain name correspond to Autonomos System 69, which is 0045 hex, is 5.4.0.0.in-as.arpa. All of *.in-as.arpa could be handled as one zone or parts of it carved out as subzones as administrative convenience dictates. [I choose .arpa as that seems to follow the in-addr model and A.S. numbers originated in the IPv4 world. This could be .int or .# or whatever.] [I choose hex digits to provide a slightly finer subdivision than the traditional decimally represented bytes. If there is really lots of CIDR like sub-allocation of power of two groups of A.S. numbers and having to sometimes have multiple designations and zones for what should logically be a single zone is considered too ugly, you could go to all "1" and "0" labels are write it as the reversed binary. But didn't seem worth it to me. Even if its a bit ugly, few people will ever see it.] Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 3. Meaning of RRs There are no enforceable restrictions on what resource records can be stored under *.in-as.arpa names; however, the following guidance is given for some RR types (the KEY RR is given first, then the rest in alphabetic order). KEY: This type of resource record associates a public key with the Autonomous System (A.S.) designated by its name. Such a public key can be used to authenticate communications with or between A.S.s. The existence of KEY RRs in the reason for mapping A.S. names into the DNS. Under DNS security the KEY RR can be used to store any type of digital key. A: DO NOT place type A RRs at A.S. nodes. A.S. domain names are reserved for Autonomous Systems only and should NEVER be used for a host or any type of end entity other than an Autonomous System. CNAME: This type of RR is an alias pointing to another domain name. An A.S. could have a CNAME pointing to a different A.S. but this is not likely to be very useful as A.S. RRs will normally be looked up when the A.S. number is actually encountered in use. MX: There is no designated use for an MX RR for an A.S. name. It could point to a host that would accept mail related to that A.S. NS: The presence of NS records under an A.S. name mean that it has been carved out as a subzone. This gives the A.S. complete control over the zone refresh parameters and control over the creation of inferior names. No special meaning is currently assigned to such inferior names so, although this is not advised, they could be used for hosts or whatever. RP: A Responsible Person RR should appear under each A.S. name telling you who you should contact in the case of problems with that A.S. TXT: Text RRs can be used for comments, postal address, or similar notes under an A.S. name. Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 4. Security Considerations The entirety of this document concerns a means to map Internet Autonomous System numbers into the Domain Name System (DNS) so that secure DNS can be used to provide secure distribution of Autonomous System's public keys. References [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Author's Address 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 Expiration and File Name This draft expires 26 January 1995 Its file name is draft-ietf-dnssec-as-map-00.txt. Donald E. Eastlake 3rd [Page 8]   Received: from sol.tis.com by magellan.TIS.COM id aa04569; 25 Jul 94 17:07 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma029000; Mon Jul 25 17:06:54 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA08947; Mon, 25 Jul 94 13:53:40 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA18988; Mon, 25 Jul 1994 16:56:34 -0400 Message-Id: <9407252056.AA18988@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: Charlie Kaufman Subject: draft-ietf-dnssec-secext-02.txt Date: Mon, 25 Jul 94 16:56:34 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Hello: I guess this is better late than not at all. I don't plan to actually send this to Internet-drafts until after IETF so feedback can be incorporated. I will not be attending but Charlie Kaufman will. Donald INTERNET-DRAFT DNS Protocol Security Extensions 25 July 1994 Expires 26 January 1995 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Donald E. Eastlake 3rd & Charles W. Kaufman Status of This Document This draft, file name draft-ietf-dnssec-secext-02.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, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions Abstract The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or data origin authentication. Extensions to the DNS are described in detail that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware secondary or caching servers. (A explanatory overview of the proposed extensions appears in draft- ietf-dnssec-over-*.txt.) The extensions also provide for the storage of authenticated keys in the DNS for DNS use and to support a general public key distribution service. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Acknowledgements The significant contributions of the following persons (in alphabetic order) to this draft are gratefully acknowledged: James M. Galvin, Masataka Ohta, Jeff Schiller. [This list is probably incomplete. Anyone else who feels they should be included should contact the authors.] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Brief Overview of the Extensions.......................6 2.1 Key Distribution.......................................6 2.2 Data Origin Authentication.............................6 2.2.1 Security Provided...................................7 2.2.2 The SIG Resource Record..............................7 2.2.3 The NXD Resource Record..............................8 2.2.4 Signers Other Than The Zone..........................8 2.2.5 Special Problems With Time-to-Live...................8 2.2.6 Improved Performance Mode............................9 2.3 DNS Transaction Authentication.........................9 3. The Security Desired & Security Available Bits.........11 4. The KEY Resource Record................................12 4.1 KEY RDATA format......................................12 4.2 Object Types and DNS Names and Keys...................13 4.3 The KEY RR Flag Octets................................13 4.4 KEY RRs in the Construction of Responses..............15 4.5 File Representation of KEY RRs........................15 5. The SIG Resource Record................................17 5.1 SIG RDATA Format......................................17 5.1.1 SIG Flag Bits.......................................18 5.1.2 Signature Format....................................19 5.1.3 Signet Format.......................................20 5.1.3.1 Direct Resource Record Signets....................21 5.1.3.2 Direct Glue Record Signet.........................22 5.1.3.3 Hashed Resource Record(s) Signet..................23 5.1.3.4 Partial RR Set Flag Signet........................24 5.1.3.5 Partial SIG Set Flag Signet.......................24 5.1.3.6 AXFR Signets......................................25 5.1.3.7 Message Hashed Signets............................25 5.1.3.8 Reserved Signet Prefixes..........................26 5.2 SIG RRs in the Construction of Responses..............26 5.3 Processing Responses with SIG RRs.....................27 5.4 File Representation of SIG RRs........................28 5.4.1 Size of Data........................................28 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 5.4.2 Resource Record Numbering...........................29 5.4.3 SIG RR Scope........................................29 5.4.4 RRs Supressed by a SIG RR...........................30 6. Non-exitent Names and Types............................31 6.1 Nonexistent Names.....................................31 6.1.1 The NXD Resource Record.............................31 6.1.2 NXD RDATA format....................................32 6.1.3 Interaction of NXD RRs and Wildcard RRs.............32 6.1.4 Blocking NXD Pseudo-Zone Transfers..................33 6.2 Non-existent Types....................................33 7. How to Resolve Securely................................35 7.1 Boot File Format......................................35 7.2 Chaining Through Zones................................36 7.3 Secure Time...........................................37 8. Operational Considerations.............................38 8.1 Key Size Considerations...............................38 8.2 Key Storage...........................................39 8.3 Key Generation........................................39 8.4 Key Lifetimes.........................................39 8.5 Key Revocation........................................40 8.6 Root..................................................41 9. Conformance............................................42 9.1 Server Conformance....................................42 9.2 Resolver Conformance..................................42 10. Security Considerations...............................43 References................................................43 Authors Addresses.........................................44 Expiration and File Name..................................44 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions 1. Introduction This draft provides detailed descriptions of the DNS protocol extensions to support security and key distribution. A broad overview of these extensions is provided in draft-ietf- dnssec-over-*.txt. This draft assumes that the reader is familiar with that overview and with the Domain Name System particularly as described in RFCs 1034 and 1035. The requirements and goals of DNS security are described in the overview document. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions 2. Brief Overview of the Extensions The DNS protocol extensions provide three distinct services: key distribution as described in section 2.1 below, data origin authentication as described in section 2.2 below, and transaction authentication, described in section 2.3 below. 2.1 Key Distribution The resource records are defined to associate a variety keys with DNS names. This permits the DNS to be used as a general public key distribution mechanism in support of data origin authentication and transaction authentication DNS services as well as other security services such as IP level security. The syntax of a KEY resource record is described in Section 4. It includes the name of the entity the key is associated with (usually but not always the KEY RR owner name), an algorithm identifier, a number of flags indicating the type of entity the key is associated with or asserting that there is no key associated with that entity, and the actual public key parameters. 2.2 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 the signature resource types (and, as a practical matter, the key resource type needed for key distribution). An additional domain name non-exitence resource is added to extend authentication to negative responses. This service can 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 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions 2.2.1 Security Provided Security is provided by associating with resource records in the DNS a cryptographically generated digital signature. Commonly, there will be a single private key that signs for an entire zone. If a security aware resolver reliably learns the public 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. 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 server will not affect the degree of assurance that a resolver has that the data is genuine. 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 a 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.2.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), some flags, the cryptographic algorithm in use, and the actual signature. Every name in a zone supporting signed data will have associated with it one or more SIG resource records - as many as required with the algorithm(s) in use to sign all of the authenticated 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions requested RRs - 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.2.3 The NXD Resource Record The above security mechanism provides only a way to sign existing RRs in a zone. Data origin authentication is not obviously provided for the non-existence of a domain name in a zone. This gap is filled by the NXD RR which authenticatably asserts a range of non-existent names in a zone. The owner of the NXD RR is the start of such a ranger and its RDATA is the end of the range; however, there are additional complexities due to wildcards. Section 6 below covers the NXD RR. 2.2.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 to authenticate/update its own record. The public key of the entity must be present in the DNS and be appropriately signed but the other RRs may be signed with the entity's key. The other is for support of transaction authentication as described in 2.3 below. 2.2.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 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, 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions 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.2.6 Improved Performance Mode 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 SIG 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 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. 2.3 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for message headers. If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response is from the query it sent and that these messages have not been diddled in transit. This is accomplished by adding a SIG resource record to end of the reply which digitally signs the message by the server and includes a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions hash code of the query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be precalculated. Thus it will be necessary to keep the private 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 transaction 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 origin authentication service requires the implementation of essentially all the mechanisms needed for a rudamentary message authentication service. Thus a simple transaction authentication service based on mechanisms already required by DNS security is included as a strictly optional part of these extensions. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions 3. 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 RSA 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 fully supports this security protocol. [It is not clear that the above will really work due to DNS implementations which blindly include header bits in forwarded queries.] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions 4. The KEY Resource Record The KEY RR is used to document a key that is associated with a DNS name. It will be a public key as only public keys are stored in the DNS. This can be the public key of a zone owner, of a host or other end entity, or a user. A KEY 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 of each type associated with a name. The type number for the KEY RR is 25. 4.1 KEY RDATA format The RDATA for a KEY RR consists of an object name, flags (which include an algorithm identifier, and the parameters needed for that algorithm's public keys. For the RSA algirthm, that is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- object name +---------------+ / | flags1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags2 | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The object name, and the flags octets are described in Sections 4.2 and 4.3 below. The flags must be examined before any following data as they control its the format and even whether there is any following data. The public key exponent and modulus length fields show apply only if the RSA algorithm is in use and a key is present. The public key exponent is an unsigned 24 bit integer. The public key modulus field is a multiprecision unsigned integer. The "modulus length" is an unsigned octet which is the actual modulus length minus 64. This limits keys to a maximum of 255+64 or 319 octets and a minimum of 64 octets. Although moduluses of less than 512 significant bits are not recommended, they can be represented by using leading zeros. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions 4.2 Object Types and DNS Names and Keys The public key in a KEY RR belongs to the object named in the object name field. Frequently this will also be the owner name of the KEY RR. But they will be different in the case of the key or keys stored under a zone's name for the zone's superzone or keys that are stored for cross certification. The DNS object name may refer to up to three things. 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 . Thus, there are flags in the KEY RR to indicate with which of these roles the object name and public key are associated as described below. It is possible to use the same key for these different things with the same name but this is discouraged. In addition, there are three control bits, the "no key" bit, the "mandatory" bit, and the "signatory" bit, as described in 4.3 below. 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 IP autonomous system numbers have been mapped into the in-as.arpa domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in the world have been mapped into the tpc.int domain [...]. This is preferable to having the same name possibly be an autonomous system number, telephone number, and/or host as well as a zone and a user. 4.3 The KEY RR Flag Octets In the "flags1" field: Bit 0 is the "no key" bit. If this bit is on, there is no key information other flag1 bits can be ignored. Bits 1-3 are reserved and must be zero. If any is found to be non-zero, the KEY RR must be ignored. Bits 4 to 7 are the algorithm version number parallel to the same field for the SIG resource. The RSA algorithm described in this draft is version zero. Version numbers 1 through 14 are available for assignment should sufficient reason arise. However, the designation of a new version could have a major impact on the interoperability of the global DNS systems and requires an IETF standards action. Version 15 is reserved for private use and will never be assigned a specific algorithm. For version 15, the combined "public exponent", "modulus length" and "modulus" area shown above will actually begin with an Object Identifier (OID) indicating the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. In the "flags2" field: Bits 0 is the "mandatory" bit. Keys may be associated with zones 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 operate without the availability of IP-security. The mandatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. validly sign RRs of the same name. If the owner name is a wildcard, then RRs with any name which is in the wildcard's scope can be signed including NS and corresponding KEY RRs to carve out a subzone. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The mandatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bits 2-4 are reserved and must be zero. If they are found non- zero, they should be ignored and the KEY RR used as indicated by the other flags. Bit 5 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 DNS data origin authentication public key. 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 parts of the DNS tree, be some other type of entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt]. This is the public key used in connection with the optional transaction authentication service defined in this draft. It could also be used in an IP-security protocol where authentication of a host was desired. This type of key might also 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions owner name is that used for the responsible individual mailbox 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 through an KEY 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. 4.4 KEY RRs in the Construction of Responses A request for KEY RRs does not cause any special additional information processing except, of course, for SIG RRs if security is requested and available. Security aware DNS servers will include KEY RRs as additional information in responses where security is requested under appropriate conditions as follows: On the retrieval of NS RRs, the zone key KEY RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the KEY RR(s) have lower priority than type A glue RRs. On retrieval of type A RRs, the end entity KEY RR(s) for the host named will be included. On inclusion of A RRs as additional information, their KEY RRs will also be included but with lower priority than the relevant A RRs. On any retrieval with security requested and available from a zone, revoked KEYs in that zone that fit with their revoking SIG will be included as additional information with low priority. 4.5 File Representation of KEY RRs KEY RRs may appear as lines in a zone data file. The object name appears first. Each flag field is then represented as an unsigned integer; however, if the "no key" flag is on in the first field, nothing appears after the second flag byte. If the algorithm specified is the RSA algoithm, then the exponent and modulus appear. The public key exponent is an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 319 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions 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. If an algorithm from 1 through 14 is specified, the public key parameters required by that algorithm are given. If the algorithm specified is number 15, then an OID appears followed by whatever is requiired for the private algorithm. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions 5. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure DNS. As such it is the heart of the security provided. The SIG RR unforgably binds one or more other RRs to a time and the signer's fully qualified domain name using cryptographic techniques and the signer's private key. The signer is usually the owner of the zone from which the RR originated. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | flags | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sig length | signature | +---------------+ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is 24. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is usually the zone which contained the RR(s) 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 17] 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 "key footprint" is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. In cases where multiple keys may be applicable, it can be used to efficiently pick the right one in most cases. The "flags" octet is as described in Section 5.1.1 below and includes an algorithm version field. The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null lable for root and not counting any initial "*" for a wildcard. If, on retrieval, the RR appears to have a longer name, the resolver can tell it is the result of wildcard substitution. The maximum number of labels possible in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expaned to 255 labels. The "sig length" field is an unsigned 8 bit count of the number of octets in the signature field minus 64. The structured of the "signature" field depends on the algorithm chosen and is described below. 5.1.1 SIG Flag Bits Bit 0 (the most significant bit) a zero means the SIG RR asserts the validity of the RRs it signs from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the RRs as above. Bits 1 to 3 are reserved and must be zero. If a SIG RR is retrieved with these bits non-zero by a resolver that does not understand them, the SIG RR should be discarded. Bits 4 to 7 are the algorithm version number. The RSA algorithm described in this draft is version zero. Version numbers 1 through 14 are available for assignment should sufficient reason arise to allocate them. However, the designation of a new version could have a major impact on the interoperability of the global DNS systems and requires an IETF standards action. Version 15 is reserved for private use and will never be assigned a specific algorithm. For Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions version 15, the combined "sig length" and "signature" area shown above will actually begin with an Object Identified (OID) indicating the private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. 5.1.2 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, key footprint, flags, and expiration time of the RR to one or more RRs being authenticated. To accomplish this, a set of one or more "signet" sequences is constructed to cover the RRs being signed. A "self hash" field is then calculated covering the owner, signer, etc., as listed above. The structure of signets is described in section 5.1.3 below. The hash algorithm(s) used and the maximum signet sequence size depend on the algorithm identier and the key being used. Each signet sequence and self hash is then coverted in to a SIG RR. For any non-invertible signature algorithms, a hash of the signet sequence and self hash will be calculated, then a signature of that hash will be formed and the signature prepended to the signet sequence. For any invertible algorithsm, such as the RSA algorith described in detail in this draft, the signet sequence and self hash are directly signed and the result is the signature portion of the SIG RR. In that case, there is no need for the signet sequence to be present in plain text. For the RSA algorithm, the signature is 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 16 octet hash using the MD5 [RFC1351] of the SIG RR name, class, signer name, original TTL, time signed, expiration time, key footprint, and flags. "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 not less than 512 bits and not more than 2552 bits. 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions The above specifications are similar to PKCS #1 [PKCS1] except that, under most circumstances, one additional octet of data is 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.3 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: direct, hashed, and flag. 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 supressed from the reply message if the SD bit is on in the query and the server is security aware. A hashed signet consists of the prefix octet, some additional data, and a 16 octet hash of the data covered. For the RSA algorith, MD5 is used as the hash algorithm. Since hash algorithms are 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. [The following text assumes the possibility of having multiple direct signets of the same type split over more than one signet sequnece (ie, SIG RR). This complexity has been retained because at the DNS SEC meeting at the Seattle IETF, the consensus was to retain it until operational experience had been gained. The authors of this draft feel that this possibility should be dropped and that multiple direct signets of the same type should be restricted to a single signet sequence (ie, SIG RR) thus eliminating the partial RR set flag signet.] 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 in binary are as follows: 0000000* Illegal 0LLLLLLL Direct Resource Record - type & rdata Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions 10****** (reserved) 110***** (reserved) 1110**** (reserved) 11110NHT Hashed RR(s) - N, type, T, & hash 11111000 Partial SIG Set Flag 11111001 Partial RR Set Flag 11111010 Hashed query message (see Sec. 5.2) 11111011 Hashed response message (see Sec. 5.2) 11111100 Direct Glue Record - name & rdata 11111101 (reserved) 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 illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.3.1 Direct Resource Record Signets This signet is an actual RR but with some fields supressed. 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 and the LLLLLLL field is their length. This can be done because, 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.3.2 and 5.1.3.3 below). Finally, the signet data length in the prefix octet can be used to calculate the RDSIZE. 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 supressed from the answer if given to a security aware resolver. Note that up to three class IN type A RRs can be directly included as Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions signets in fewer octets than a single hashed signet. This sort of data compression is particularly valuable with the current limitation on DNS UDP reply size. Note that any names in the RDATA area of this type of signet can not be abbreviated by pointers outside of the SIG RR. That is because the RR and its signets are frozen at the time the signature is encrypted under the signer's private key and this frozen SIG RR may then be used in a variety of DNS messages. The RDATA area may, however, have names abbreviated by references to earlier names within the SIG RR including RRS reconstructed from the signet sequence. The direct representation of RRs makes maximum use of the space available in SIG RRs and the supression of hte signet sequence outside of invertible signatures, such as the RSA digital signatures described, results in further space savings. The direct representation also avoids the computational effort of calculating a hash code. Because the original RR's 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. After the prefix (not counted) and type (2 octets), this allows 126 octets of RDATA. All RRs need not be included within a signature using this direct 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 octets 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.3.2 Direct Glue Record Signet Glue records must be handled a little differently. These are type A records with a name which isn't in the zone being handled. 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 the type is not included as it must be type A. 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 octets long which would not fit inside a SIG RR signature field. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions 5.1.3.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 16 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, then appending the self-hash field from the SIG under construcation and applying the hash algorithm. 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. The self-hash is included to force the hash code to change every time the zone is signed as the self-hash includes the time signed. This gives an adversary less time to search for a false hash match which could enable them to forge apparently authentic data. 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 type A recores 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 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 octets long, the hash of the full name with the self-hash field appended, using the hash algorithm, 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions the prefix octet followed by the type, then the TTL, then the hash code. This is the standard order for these fields in an RR. 5.1.3.4 Partial RR Set Flag Signet [See square bracketed note above about the proposed elimination of this flag signet.] Verification of a hashed RR signet against the RRs 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 F8 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 octet (i.e., 1 of 1) in the SIG RR containing direct signets for all RRs of a particular varient. For example, an signet of F8000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. 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.3.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 F9 is followed by an unsigned octet which is one less than the total number of SIG RRs associated with the name and a second unsigned octet which varies from zero through the value of the first octet. It is permissible, but unnecessary, to include a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions partial SIG set flag signet prefix followed by two zero octets (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.3.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.3.3 and the self-hash of the SIG under construction appended. 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 or user key rather than a zone key (see Section 4.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. 5.1.3.7 Message Hashed Signets The response message signet consists of the FA (hex) prefix followed by the hash of the entire response message before the SIG, including the header. The query message signet consists of the FB (hex) prefix followed by the hash of the entire query that produced this response, including the query's header. Verification of the transaction authentication SIG, which is signed by the server host key, not the zone key, and the response and query message signets within it by the requesting resolver show that the query and response were not tampered with in transit, that the response corresponds to the intended query. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions 5.1.3.8 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 authenticate 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, its automatic inclusion MUST be in the answer section. If it covers an RR that would appear in the authority section and does not cover any answer section RR, its automatic inclusion MUST be 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 the full authenticated RR will be included inside the SIG RR. In such cases, the DNS server SHOULD send only the SIG and supress 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 SHOULD send the unauthenticated RR notwithstanding the set SD bit in Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions the query header. The resolver can always do another query to get the SIG. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section. Such SIG RRs are signed by the DNS server originating the response. The transaction authentication SIG contains a response message hashed signet and a query message hashed signet. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. To save space, the name should be root (a single zero octet) and the class and TTL fields can be zero. [There may be a problem with SIG and NXD RR's associated with domain names that are CNAMEs. The DNS RFCs prohibit other types of RRs appearing with a CNAME RR. If a server is no security aware, then an attempt to retrieve a SIG RR to authenticate a CNAME RR or an NXD to authenticate the non-exitence of a name could result in a non- security aware server doing CNAME processing and not returning the SIG or NXD asscoiated with the CNAME's owner name. The solution to this problem would be to define a new Class, INSEC, which would be used for SIG and NXD RRs that sign IN Class RRs only. Then a security aware resolver talking to a non-security aware server would simply use that class when retrieving SIGs for authentication. It is not clear that this is needed for KEY RRs but similar SIG/NXD holding classes might be needed for any other DNS classes in use such as the HS class.] 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. If the message or 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. The contents of the one or more direct, hashed, or flag signets present should be examined. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions 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 hashed response and query message signets covering the preceding data in the response and the query that produced the response. These may be checked and the message rejected if the checks fails. But even it the check succeeds, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. 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 suspicion. The probability that an RSA 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**120). 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 transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) 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 and flags fields appears as unsigned integers. The "labels" field does not appear in the file representation as it can be calculated from the owner name. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be up to 319 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 Resource Record Numbering A SIG RR stored in a zone file covers and in some cases supresses 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 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. [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 including 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 supresses as explained in the section below. The SIG RR itself need not be numbered unless it needs to be referred to. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions For example [examples] 5.4.4 RRs Supressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should be supressed when the SIG RR appears in a security aware 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 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 supressed RRs are numbered. An RR that is supressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.3. [example] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions 6. Non-exitent Names and Types The SIG RR mechanism described in section 5 above provides strong authentication of RRs that exist in a zone. But is it not immediately clear how to authenticatably deny the existence of a name in a zone or deny the existence of a particular type of RR for an existing name. How to securely acomplish these denials is described below. 6.1 Nonexistent Names The nonexistence of a name in a zone is indicates by the NXD RR for a name interval containing the nonexistent name. An NXD RR is returned in the additional information section, along with the error, if the client is security aware. NXD RRs can also be returned if an explicit query is made for the NXD type. The existence of a complete set of NXD records in a zone means that any query for any name to a security aware server serving the zone should result in an reply containing at least one signed RR. 6.1.1 The NXD Resource Record The NXD resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a domain. The owner name of the NXD RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NXD RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. There is a slight problem with the last NXD in a zone as it wants to have an owner name which is the last existing name is sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions RDATA of the last NXD. There are additional complexities due to interaction with wildcards as explained below. The NXD RRs for a zone can be automatically calculated and added to the zone by the same recommended off-line process that signs the zone. The NXD RRs TTL should not exceed the zone minimum TTL. The type number for the NXD RR is xxx. 6.1.2 NXD RDATA format The RDATA for an NXD RR consists simply of a domain name. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.3 Interaction of NXD RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NXD record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NX RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NXD for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NXD is returned as additional information in connection with a security aware query for a non- existent name. If there could be any wildcard RRs in a zone and thus wildcard NXDs, care must be taken in interpreting the results of explicit NXD retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs in the internal. The server can just falsely return the wildcard match instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NXD RR whose owner name and RDATA are both the zone name. In this case a server could Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions conceal the existence of any more specific RRs in the zone. It would be possible to make a more complex NXD feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature that could create new names very difficult (see Section 4.2). 6.1.4 Blocking NXD Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NXD associated with the zone name. Using the RDATA field from that RR, it can query for the next NXD RR. By repeating this, it can walk through all the NXDs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NXD walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals except by tedious trial and error. If it is desired to block NXD walking, the recommended method is to add a zone wide wildcard of the KEY type which asserts the nonexistence of any keys. This will cause there to be only one NXD RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non-existence of names that NXD RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching that wildcard and can thus hide all the real data and delegations with more specific names in the zone. 6.2 Non-existent Types When a secure query is made for a name and class that exist is a zone, but for an RR type that does not exist, there needs to be a secure way to know that the type does not exist. This can be determined by retrieving and examining all the SIG RRs. All types will be indicated within the SIGs and the partial SIG set signets in the SIGs can be used to assure that a complete set of SIGs has been retrieved. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions Thus a query from a security aware resolver for a name that exists for some RR in a zone but not as the owner of any RR of the requested type should be answered by a security aware server with the usual error but with all the SIGs for that name as additional information. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions 7. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS zone 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 algorithm [exponent modulus] for a zone public key or hostkey f.q.d.n algorithm [exponent modulus] for a host public key. f.q.d.n is the domain name of the zone or host. Algorithm is the algorithm in use where zero is the RSA algorithm and 15 indicates a private algorithm. The material after the algorithm is algorithm dependent and, for private algorithms, starts with the algorithm's identifying OID. For the RSA algirithm, it is the public key exponent as a decimal number between 3 and 16777215, and the modulus in hex. 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions 7.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have a key. 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 one starts below root. A secure sub-zone is generally indicated by a KEY RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. 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. 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 presence of an authenticated KEY RR for the non-secure zone with a no key flag or the presence of a KEY RR without the mandatory bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. 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 within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. The existence of cross certifications adds further policy questions. Assume we have a zone B.A and a zone Y.X. Many possibilities exist for a secure resolver configured with the B.A key to get to Y.X. If all the zones along the way are secure, it could climb to root and then descend the other side, a total of three hops. If the B.A administrator had installed a cross certified key for Y.X in the B.A zone, using that would be a shorter and presumably more secure way to find Y.X's key which would be immune to the non-security or even compromise of the servers for A or root or X. But what if some less trusted subzone of B.A, say C.B.A installed a cross certified key for Y.X? If there is a conflict, should the be prefered to a hierarhcially dervied key obtained by climbing to root and descending? This is a matter of resolver policy. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions 7.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions. A variety of time synchronization protocols exist including the Network Time Protocol (NTP, RFC1305). If such protocols are used, they should be used securely so that time can not be spoofed. Otherwise, for example, a host could get its clock turned back and might then believe old RRs ("A" records for example) which were valid but no longer are. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations This section discusses a variety of considerations in secure operation of DNS using these proposed protocol extensions. 8.1 Key Size Considerations There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of a key size should be made by the zone administrator depending on their local conditions. For most schemes, larger keys are more secure but slower. Verification (the most common operation) for the RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the square of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus increases the verification time by a factor of 4 but vastly increases the work factor of breaking the key. [RSA FAQ] The recommended minimum RSA algorithm modulus size, 640 bits, 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.) Using the RSA algorithm, this protocol packs information inside an RSA signature, so larger moduluses may increase the efficiency of use of space with SIG RRs. There is a 22 octet 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 (currently 512 bytes). With RSA and 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 octets for other signets. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 38] INTERNET-DRAFT DNS Protocol Security Extensions Zones may wish to adopt policies on the size of keys stored within them such that the KEY RRs for these keys will fit within a zone signed RSA algorithm SIG for efficiency or to meet other objectives. 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 physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding NXD and SIG RRs. Then the augmented file can be transferred, perhaps by sneaker-net, to the networked zone primary server machine. 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 an unsecured network mediated communication. Non-zone private keys, such as host keys, may have to be kept on line to be used for real-time purposes such a IP secure session set-up. 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-*.txt. It is strongly recommended that key generation also occur off-line, perhaps on the machine used to sign zones (see Section 8.2). 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 maximum lifetime for zone keys that Donald E. Eastlake 3rd & Charles W. Kaufman [Page 39] INTERNET-DRAFT DNS Protocol Security Extensions are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended maximum 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 or more often. In some cases, a host key lifetime of a little over a day may be reasonable. 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, KEYs, 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. 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 at random as much as will fit. 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. 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 in a SIG can be revoked for just the later part of that lifetime by setting appropriate times in the revocation SIG RR. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 40] INTERNET-DRAFT DNS Protocol Security Extensions 8.6 Root The root zone key is self-signed. It should also be noted that in DNS the root is a zone unto itself. Thus the root zone key should only be see signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Implementations MAY reject as bogus any purported root signature of records with a name more than one level below root. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 41] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance Several levels of server and resolver conformance are defined. 9.1 Server Conformance Security aware servers MUST respond normally to requests that do not have the Security Desired bit set. Three levels of server conformance are defined as follows: Zilch server compliance is (1) the ability to ignore the Security Requested bit in queries, (2) ability to store and retrieve (incluidng zone transfer) SIG, KEY, and NXD RRs, and (3 clearing the Security Available bit in responses. It is believed that almost all current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG, KEY, and NXD RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXD RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to handle the Security Desired bit in inquiries, automatically including SIG, KEY, and NXD RRs in responses as appropriate, as well as meeting the minimal compliance except that only item 2 of zilch criteria should be met. In addition, fully compliant servers MUST turn on the Security Available bit in responses. 9.2 Resolver Conformance Two levels of resolver compliance are defined: A Zilch compliance resolver ignores the Security Available bit in responses, does not set the Security Desired bit in queries, and can handle SIG, KEY, and NXD RRs when they are explicitly requested. It is believed that current resolvers are Zilch compliant. A fully compliant resolver sets the Security Desired bit in its queries, maintains appropriate infomration in its local chaches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, and performs additional queries as necessary to obtain KEY, SIG, or NXD RRs from non-security aware servers. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 42] INTERNET-DRAFT DNS Protocol Security Extensions 10. Security Considerations This document concerns technical details of extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distibution, and optional transaction security. If should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host; however, this does not stop someone for substituting an unauthorized host at that address. Any reasonably complete security system will require the protection of many other facets of the Internet. 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 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 43] 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 26 Janury 1995. Its file name is draft-ietf-dnssec-secext-02.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 44]   Received: from sol.tis.com by magellan.TIS.COM id aa00437; 2 Aug 94 11:33 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma005575; Tue Aug 2 11:33:35 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA17925; Tue, 2 Aug 94 11:32:49 EDT Message-Id: <9408021532.AA17925@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: draft DNS Security WG minutes Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa1" Date: Tue, 02 Aug 1994 11:32:50 -0400 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <457.775841548.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <457.775841548.3@tis.com> These minutes will be submitted to the Secretariat by close of business on wednesday, August 3, EDT. Please review and comment as quickly as possible. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <457.775841548.4@tis.com> Content-Description: DNS Security WG Minutes DNS Security WG Meeting Minutes July 1994 Toronto Recorded by Jim Galvin, Chair The DNS Security Working Group met on Wednesday morning for a 2.5 hours meeting. Masataka Ohta had previously submitted an alternative to the Donald Eastlake and Charlie Kaufman proposal. The majority of this meeting was dedicated to discussing the differences between the two proposals. The meeting began with Jim Galvin presenting a very brief summary of his implementation experience with the Eastlake/Kaufman proposal. No cryptography was implemented; in the interests of simplicity and expediency, values were exclusive-ored instead. Also, only the direct resource records were prototyped. Two results were reported: it is possible to implement the proposal and the proposal includes more options than are needed. Jim observed that one of the principal motivations for many of the options in the Eastlake/Kaufman proposal was the perception that the 512 byte limit for DNS messages was too small. However, he asserted that this limit was in fact not an issue, for two reasons that would be explained later. As a result, he had a proposal for how to proceed but preferred to yield the floor to the Kaufman and Ohta for a discussion of their lists of issues. The remainder of the meeting was dedicated to Kaufman and Ohta each presenting a list of questions and comments about each others' proposals. There was a great deal of vigorous and animated discussion about the issues. Careful time management allowed a complete presentation of all the issues, with some discussion for each, although no conclusions were reached. Since both Ohta and Kaufman agreed to distribute their lists to the electronic mailing lists for continued discussion and resolution, the details are not presented here. The meeting closed with Jim proposing that Eastlake/Kaufman reduce their proposal to including only the hashed resource record, for two reasons. First, there is the assertion that the 512 byte limit would be sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit to 1500 bytes, which is sufficient to support security as currently proposed. TIS will implement the proposed DNS security enhancements with this new version of DNS. Jim will followup with Eastlake and Kaufman about reducing their proposal, identified as Eastlake/Kaufman-lite. The Chair agreed to propose criteria that could be used to evaluate the two proposals --- Eastlake/Kaufman-lite and Ohta --- to aid the working group in selecting one to submit to the standards track. Consensus and a single proposal will be obtained on the mailing list prior to the next IETF; this group expects to meet in San Jose. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/signature Content-ID: <457.775841548.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,sS+KRT4WqB8xxC0q+KS4GIy6ROLXtb5i6C8OQZCN3Gn4jCp7uZta= YR3lzgivJlSt1dPHcrXEC7bn1raibwV+FoV5ogz/NOyZjGHhv2WW7y5/y/JFRDYydxo+qmlm2a= 8W ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa00660; 2 Aug 94 12:04 EDT Received: from brazos.is.rice.edu(128.42.42.2) by relay via smap (V1.3) id sma006141; Tue Aug 2 12:04:48 1994 Received: by brazos.is.rice.edu (AA06842); Tue, 2 Aug 94 11:04:31 CDT From: William Manning Message-Id: <9408021604.AA06842@brazos.is.rice.edu> Subject: Re: draft DNS Security WG minutes To: galvin@tis.com Date: Tue, 2 Aug 1994 11:04:30 -0500 (CDT) Cc: dns-security@tis.com In-Reply-To: <9408021532.AA17925@tis.com> from "James M Galvin" at Aug 2, 94 11:32:50 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 495 sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit to 1500 bytes, which is sufficient to support A followin DNS mtg touched briefly on this topic. I understand the implementation will actually have some slop in determining message size. If this actuall works out this way, I would not state a catagorical 1500 byte size. (I am ready for a new keyboard!) -- Regards, Bill Manning   Received: from sol.tis.com by magellan.TIS.COM id aa00821; 2 Aug 94 12:49 EDT Received: from rip.psg.com(147.28.0.39) by relay via smap (V1.3) id sma006805; Tue Aug 2 12:50:03 1994 Received: by rip.psg.com (Smail3.1.28.1 #7) id m0qVN2C-000308C; Tue, 2 Aug 94 09:49 PDT Message-Id: Date: Tue, 2 Aug 94 09:49 PDT From: Randy Bush To: James M Galvin Cc: dns-security@tis.com Subject: draft DNS Security WG minutes References: <9408021532.AA17925@tis.com> > First, there is the assertion that the 512 byte limit would be sufficient > about 80-90% of the time. I never did understand how an 10-20% failure rate was ok, but that's likely my problem. > However, even without this assertion, Version 2 of DNS will shortly be > proposed that will increase the message size limit to 1500 bytes, which is > sufficient to support security as currently proposed. From the DNSIND draft minutes of Tuesday the 26th: o If MTU discovery had been done, we would use that. So we can't The current plan is to let the client specify the max packet and let the server decide use as much as it can. What to do when not enough room? Round robin punt? Input from and coordination between DNSSEC and DNSIND on this might be interesting. randy   Received: from sol.tis.com by magellan.TIS.COM id aa00853; 2 Aug 94 12:57 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma006932; Tue Aug 2 12:57:27 1994 Received: by gw.home.vix.com id AA08311; Tue, 2 Aug 94 09:57:12 -0700 Date: Tue, 2 Aug 94 09:57:12 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: <9408021532.AA17925@tis.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: galvin@tis.com's message of 2 Aug 1994 09:13:53 -0700 As long as we're on the subject, I'd like to repeat in public a discussion Jim and I had with respect to DNS V2 and security. Jim's right -- V2 will permit larger responses. 1500 is just an example; it'll be up to each resolver to choose its receive buffer size and there will be a field in the request packet that tells the server how large that buffer is. 1500 will just be the value the server will maximize against unless it has a Discovered Path MTU that's larger. 1500 is also going to be the minimum recommended value, though 512 will remain the minimum legal value. So what Jim said in the minutes is all true, but the truth as always is more complex. But there's more. I've been on record as being against the use of our last two flag bits as SA and SD. Jim and I worked out an interesting scheme whereby neither bit is needed, which is too bad since V2 will have more flag bits and will define unused ones to MBZ (rather than UDF). I'm sure we'll need those flag bits eventually, but for now I proposed to Jim that he use multiple queries (QCOUNT==2) to ask simultaneously for an RRset and the SIG RRset for that (class,type,name). This begs the question as to how we'll specify the (type) portion of the SIG tuple -- we may have to get 'em all, or we may have to legislate that if the second query is for SIG, it is for the RR type of the first query. (Actually I'd hate that -- better to return 'em all.) For V1 prototyping, Jim (or any prototype implementor) could just use two separate queries. Using separate queries makes us pretty sure that the responses will each fit in V1's 512 byte limit, too. (For context -- I suggested to Jim that the RRdata field of any SIG should include the (type) portion of the signed (name,class,type) tuple.) That takes care of the size problem (TCP fallback on TC will still work when I'm wrong, which will hopefully not be a large percentage of the time) and the need for SD and SA bits. If we can then also take care of my concerns about RSA's patent, I'll have no further objections to the minimal-EK proposal being honed by Jim Galvin. I think the fundamental ideas are sound and I'm anxious to see it done. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa01050; 2 Aug 94 13:43 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma007918; Tue Aug 2 13:43:56 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA10135; Tue, 2 Aug 94 13:43:10 EDT Message-Id: <9408021743.AA10135@tis.com> Reply-To: James M Galvin To: William Manning Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: 's message of Tue, 02 Aug 1994 11:04:30 CDT. <9408021604.AA06842@brazos.is.rice.edu> Date: Tue, 02 Aug 1994 13:43:10 -0400 From: James M Galvin sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit to 1500 bytes, which is sufficient to support I've changed the wording as follows: However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa01130; 2 Aug 94 13:58 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma008224; Tue Aug 2 13:58:45 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA14192; Tue, 2 Aug 94 13:57:58 EDT Message-Id: <9408021757.AA14192@tis.com> Reply-To: James M Galvin To: Randy Bush Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Randy Bush's message of Tue, 02 Aug 1994 09:49:00 PDT. Date: Tue, 02 Aug 1994 13:57:59 -0400 From: James M Galvin > First, there is the assertion that the 512 byte limit would be > sufficient about 80-90% of the time. I never did understand how an 10-20% failure rate was ok, but that's likely my problem. Not really. I frankly don't believe the failure rate is all that high. I believe my estimate to be conservative on the measure of success. The short form of the analysis is as follows: If a 1024 bit key is used, then 128 bytes are needed for the signature (plus a few bytes for "encoding"). Assume that dns names are 30 bytes on average. This number is derived from averaging the size of email addresses on the 6 email lists I maintain. (Note, I said address, not just the host part.) If the query is for IP addresses, how likely is it that the (type, class, name) in the question and 3 IP addresses in the answer are going to exceed 384 octets. if the query is for MX records, how likely is it that the (type, class, name) in the question and 3 MX names in the answer are going to exceed 384 octets. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa01255; 2 Aug 94 14:19 EDT Received: from rip.psg.com(147.28.0.39) by relay via smap (V1.3) id sma008768; Tue Aug 2 14:20:29 1994 Received: by rip.psg.com (Smail3.1.28.1 #7) id m0qVORi-000308C; Tue, 2 Aug 94 11:20 PDT Message-Id: Date: Tue, 2 Aug 94 11:20 PDT From: Randy Bush To: James M Galvin Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes References: <9408021757.AA14192@tis.com> > I never did understand how an 10-20% failure rate was ok, but > that's likely my problem. > > Not really. I frankly don't believe the failure rate is all that high. > I believe my estimate to be conservative on the measure of success. I think I understand the analysis. What I do not understand is how we can find failures acceptable, whether they are 20% or 2%. So I am assuming that there is something I do not understand in the basic operational requirements which makes this ok. Not to worry. I am sure I will sort it out as I keep lurking. randy   Received: from sol.tis.com by magellan.TIS.COM id aa01327; 2 Aug 94 14:29 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma009094; Tue Aug 2 14:30:04 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA25016; Tue, 2 Aug 94 14:29:17 EDT Message-Id: <9408021829.AA25016@tis.com> Reply-To: James M Galvin To: Randy Bush Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: 's message of Tue, 02 Aug 1994 11:20:00 PDT. Date: Tue, 02 Aug 1994 14:29:20 -0400 From: James M Galvin > I never did understand how an 10-20% failure rate was ok, but > that's likely my problem. > > Not really. I frankly don't believe the failure rate is all > that high. I believe my estimate to be conservative on the > measure of success. I think I understand the analysis. What I do not understand is how we can find failures acceptable, whether they are 20% or 2%. So I am assuming that there is something I do not understand in the basic operational requirements which makes this ok. Not to worry. I am sure I will sort it out as I keep lurking. What should happen is the server returns a response that is marked as truncated. A "smart" client will then re-query but use TCP instead of UDP. By failure, what I mean is the fallback onto TCP, thus increasing the overhead and time to get a response. Failure is not meant to imply that no response is available, except when servers and clients are not "well-behaved". Jim   Received: from sol.tis.com by magellan.TIS.COM id aa01508; 2 Aug 94 14:49 EDT Received: from hp.com(15.255.152.4) by relay via smap (V1.3) id sma009615; Tue Aug 2 14:49:32 1994 Received: from hpindbg.cup.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA07598; Tue, 2 Aug 1994 11:49:15 -0700 Received: by hpindsh.cup.hp.com (1.37.109.11.2/15.5+IOS 3.20+cup+OMrelay) id AA224613360; Tue, 2 Aug 1994 11:49:20 -0700 From: Art Harkin Message-Id: <9408021149.ZM22459@hpindbg.cup.hp.com> Date: Tue, 2 Aug 1994 11:49:19 -0700 In-Reply-To: Randy Bush "Re: draft DNS Security WG minutes" (Aug 2, 11:20am) References: <9408021757.AA14192@tis.com> X-Mailer: Z-Mail (2.1.5 20sep93) To: Randy Bush Subject: Re: draft DNS Security WG minutes Cc: dns-security@tis.com On Aug 2, 11:20am, Randy Bush wrote: > I think I understand the analysis. What I do not understand is how we can > find failures acceptable, whether they are 20% or 2%. So I am assuming that > there is something I do not understand in the basic operational requirements > which makes this ok. Not to worry. I am sure I will sort it out as I keep > lurking. > > randy >-- End of excerpt from Randy Bush I think the success rate is 100% when TCP fallback is considered, but less for first time success when UDP is used. I think the concern is to to minimize the need to fallback to TCP... is this correct? -art -- ------------------------------------------------------------------------------ A r t H a r k i n Hewlett-Packard Company Information Networks Division E-Mail: ash@cup.hp.com 19420 Homestead Road MS 43LN, Phone: (408) 447-3755 Cupertino, CA 95014 USA ------------------------------------------------------------------------------   Received: from sol.tis.com by magellan.TIS.COM id aa01778; 2 Aug 94 15:11 EDT Message-Id: <9408021912.AA10180@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma010175; Tue Aug 2 15:12:16 1994 To: James M Galvin Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 02 Aug 94 13:57:59 -0400. <9408021757.AA14192@tis.com> Date: Tue, 02 Aug 94 15:11:58 -0400 From: Steve Kent Jim, I think your analysis on size of returned records is good, but I still would feel better if we had histogram data from DNS servers showing the numer of responses of each length. We need to collect this data from servers at various tiers in the hierarchy, i.e., at the root, at top level domains like COM and EDU and some non-US domains (Germany is an obvious candidate given the long names in that language), and from several organizational tier domains (e.g., good size companies, government organizations, and universities). That data would provide the best support for this discussion, if it isn't made moot by DNS v2. On a separate topic, let me suggest that we still ought to be looking at a truly algorithm independent spec. Making specific provisions for packing bits in the case of RSA use may very well lead to ONLY RSA-compatible code in servers and clients, if there is a belief that RSA will be the signature algorithm of choice. If the protocl didn't allow one to try to economize on space, the resulting protocol and software could be much easier to switch over to different signature algorithms. I think a hybrid scheme, with Ohta's simplier structure for signing records and storing keys, but with the E-K approach to forward, reverse and cross-certificates (with carefully specified rules on allowed certification paths to avoid the problems Ohta and other were concerend about), would be a clean design that avoids algorithm dependence, is easier to explain to people, and has fewer opportunities for errors due to inclusion of lots of special cases for representations, etc. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa01910; 2 Aug 94 15:39 EDT Received: from rodan.uu.net(153.39.128.10) by relay via smap (V1.3) id sma010747; Tue Aug 2 15:39:33 1994 Received: by rodan.UU.NET id QQxbgg20654; Tue, 2 Aug 1994 15:34:17 -0400 Message-Id: To: Art Harkin Cc: Randy Bush , dns-security@tis.com From: "Louis A. Mamakos" Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of "Tue, 02 Aug 1994 11:49:19 PDT." <9408021149.ZM22459@hpindbg.cup.hp.com> Date: Tue, 02 Aug 1994 15:34:16 -0400 Sender: louie@uunet.uu.net > I think the success rate is 100% when TCP fallback is considered, but > less for first time success when UDP is used. I think the concern is to > to minimize the need to fallback to TCP... is this correct? Clever resolvers can notice that the truncation occured *after* the answer section (such as in the additional records section) and choose to not retry the query using TCP. This can further reduce the effective "failure" rate. Louis A. Mamakos louie@alter.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001   Received: from sol.tis.com by magellan.TIS.COM id aa02320; 2 Aug 94 16:20 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma011471; Tue Aug 2 16:20:23 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA23869; Tue, 2 Aug 94 16:19:37 EDT Message-Id: <9408022019.AA23869@tis.com> Reply-To: James M Galvin To: Steve Kent Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Steve Kent's message of Tue, 02 Aug 1994 15:11:58 EDT. <9408021912.AA10180@relay.tis.com> Date: Tue, 02 Aug 1994 16:19:39 -0400 From: James M Galvin On a separate topic, let me suggest that we still ought to be looking at a truly algorithm independent spec. Although I have not had a chance to review it carefully, the draft distributed to this mailing list last week is algorithm independent. This point is somewhat obscure in some places but that is fixable. If the protocl didn't allow one to try to economize on space, the resulting protocol and software could be much easier to switch over to different signature algorithms. The E-K-lite proposal does not include the space economizing options. This is not obvious since the "lite" proposal has not actually put forth in "print" but it should be forthcoming soon. I agree, in principle, with everything else you said. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa02373; 2 Aug 94 16:29 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3) id sma011643; Tue Aug 2 16:29:29 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 2 Aug 1994 13:28:52 -0700 Message-Id: <199408022028.AA05306@zephyr.isi.edu> To: Steve Kent Cc: James M Galvin , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 02 Aug 1994 15:11:58 -0400. <9408021912.AA10180@relay.tis.com> Date: Tue, 02 Aug 94 13:25:05 PDT From: Paul Mockapetris Two suggestions: The DNS group should seek the wisdom of the IPng types with regard to larger MTUs, and is probably pretty safe bumping existing IP size up to ethernet. We should probably not invent a MTU mechanism that is DNS specific other than to say "if your MTU is less then X, use TCP". Measurements of the current servers are interesting, but IPng will chage the stats pretty violently, and in the more balzanized world which may be coming with the demise of the NSFnet, we may need more redundancy, rather than less. So holding the line probably isn't an option regrardless. Even if as Charlie sez, "we went to great lengths to keep packets short". paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa02655; 2 Aug 94 16:57 EDT Message-Id: <9408022058.AA12344@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma012340; Tue Aug 2 16:58:14 1994 To: James M Galvin Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 02 Aug 94 16:19:39 -0400. <9408022019.AA23869@tis.com> Date: Tue, 02 Aug 94 16:53:20 -0400 From: Steve Kent Jim, Thanks for the clarification. When I spoke with Charlie last week I thought he indicated that the latest version still had an option for sending signed data, in lieu of sending the data and the signature. That's the sort of non-algorithm independence I was concerend about, but if that is gone, I fell much better. One might also ask if signing the data, rather than a hash of the data, is worth the extra complexity it introduces, so long as both the data and the hash will be sent anyway in an purely algorithm independent design. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa02579; 2 Aug 94 16:54 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3) id sma012260; Tue Aug 2 16:55:14 1994 Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01575; Tue, 2 Aug 1994 16:55:11 -0400 Received: from localhost by alpha.zk3.dec.com; (5.65/1.1.8.2/26May94-1024AM) id AA21666; Tue, 2 Aug 1994 16:55:19 -0400 Message-Id: <9408022055.AA21666@alpha.zk3.dec.com> To: galvin@tis.com Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes Date: Tue, 02 Aug 94 16:55:18 -0400 From: kaufman@zk3.dec.com X-Mts: smtp These are important issues to discuss. On the time critical issue of the minutes, I think the draft minutes are a fair statement of what happened at the meeting if one carefully reads the "XXX asserted". There might be a more forceful statement that no consensus was reached on any of the controversial statements (including whether hacks to keep responses as small as possible are necessary) and that discussion would continue on the list. As it already has. --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa02978; 2 Aug 94 21:04 EDT Received: from munnari.oz.au(128.250.1.21) by relay via smap (V1.3) id sma015120; Tue Aug 2 21:04:42 1994 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17858; Wed, 3 Aug 1994 10:41:45 +1000 (from kre@munnari.OZ.AU) To: pvm@isi.edu Cc: Steve Kent , James M Galvin , dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of "Tue, 02 Aug 1994 13:25:05 PDT." <199408022028.AA05306@zephyr.isi.edu> Date: Wed, 03 Aug 1994 10:41:41 +1000 Message-Id: <29730.775874501@munnari.OZ.AU> From: Robert Elz Date: Tue, 02 Aug 94 13:25:05 PDT From: Paul Mockapetris Message-ID: <199408022028.AA05306@zephyr.isi.edu> The DNS group should seek the wisdom of the IPng types with regard to larger MTUs, and is probably pretty safe bumping existing IP size up to ethernet. I'm not sure that there is a lot of wisdom to impart - the issue is not decided. There is a camp arguing for a 1500 minumum mtu, with other link levels being required to internally fragment and re-assemble, and a camp arguing that minimum mtu should be left more or less as now (which is 80 bytes incidentally, not 512 or 536 or 576 or something - the larger number is the minimum "max packet size receivable" and has nothing whatever to do with mtus). Since this doesn't affect the protocol at all, there is no real pressure to come to a decision on this anytime soon. I believe it would be entirely reasonable to require that hosts that want to participate in either DNSv2 or secure DNS (which probably implies the former) have resolver buffers of at least 1500 bytes to handle replies that big. This requires nothing of MTUs in IPv4 (though obviously larger ones avoid fragmentation) nor much of IP6, other than that the servers can discover the MTU so as to know when to send fragments. Certainly sending frags isn't a great thing to do if it can be avoided, but nor is it total disaster. With IP6, as the sender has to know if fragmentation is going to happen, it can always opt to send a TC response, and require a TCP connection for a complete answer. We should probably not invent a MTU mechanism that is DNS specific other than to say "if your MTU is less then X, use TCP". This is reasonable, provided the sender is going to know the MTU - for this kind of query the sender's packet is small, so that's not going to elicit an MTU exceeded ICMP message. Its not clear to me that on a random query sent to a random nameserver the sender has any mechanism to know its MTU, or ever could have, unless we were to adopt a convention that required queries to be sent imbedded in packets that are the same size as the max reply packet we wish to receive (so pad a query to 1500 bytes if a reply up to 1500 was requested). This doesn't seem great to me. I suspect that we're going to need better kernel interfaces, so an ICMP returned will get back to datagram sending applications, along with DNS servers holding responses for a short while (few seconds) after sending them so an ICMP ("frag required") response can be matched with the packet that caused it and some sensible action taken (a TC response, or resend with the frag header). All this is quite a way away from the way things operate now. kre   Received: from sol.tis.com by magellan.TIS.COM id aa03675; 3 Aug 94 5:27 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma019403; Wed Aug 3 05:27:49 1994 Received: by gw.home.vix.com id AA29087; Wed, 3 Aug 94 02:27:33 -0700 Date: Wed, 3 Aug 94 02:27:33 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: Nntp-Posting-Host: office.home.vix.com In-Reply-To: louie@uunet.uu.net's message of 2 Aug 1994 13:30:46 -0700 >Clever resolvers can notice that the truncation occured *after* the answer >section (such as in the additional records section) and choose to not retry >the query using TCP. This can further reduce the effective "failure" rate. That's all true. And in light of it I'd like to point out that BIND is not "clever" by this definition. Yet. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa03239; 3 Aug 94 1:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma016531; Wed Aug 3 00:04:48 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Aug 94 12:57:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408030357.AA15304@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: galvin@tis.com Date: Wed, 3 Aug 94 12:57:41 JST Cc: dns-security@tis.com In-Reply-To: <9408021532.AA17925@tis.com>; from "James M Galvin" at Aug 2, 94 11:32 am X-Mailer: ELM [version 2.3 PL11] > The meeting began with Jim Galvin presenting a very brief summary of his > implementation experience with the Eastlake/Kaufman proposal. No > cryptography was implemented; in the interests of simplicity and > expediency, values were exclusive-ored instead. Also, only the direct > resource records were prototyped. Two results were reported: it is > possible to implement the proposal and the proposal includes more > options than are needed. "it is possible to implement the proposal"? Well, yes, as long as it is self consistent. But that is not what we expected with your implementation effort. Considering that, when I asked you about the partial RR problem of the Eastlake/Kaufman proposal, you didn't understand what "partial RR" means and, at first, we can't even communicate. So, from your effort, you can't say anything more than: it is possible to implement the basic cryptographic frame work of the proposals But, I wrote another draft not because I think the basic cryptographic framework is broken. > The Chair agreed to propose criteria that could be used to evaluate the > two proposals --- Eastlake/Kaufman-lite and Ohta --- One basic difference was and still is simplicity. And you propose to simplify Eastlake/Kaufman a little. And you can continue to do so every time a serious defect of Eastlake/Kaufman proposal is recognized by you. But, what is the point in doing so, as my much simpler proposal is already here? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa03185; 3 Aug 94 0:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma016592; Wed Aug 3 00:17:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Aug 94 13:04:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408030404.AA15356@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Randy Bush Date: Wed, 3 Aug 94 13:04:41 JST Cc: galvin@tis.com, dns-security@tis.com In-Reply-To: ; from "Randy Bush" at Aug 2, 94 11:20 am X-Mailer: ELM [version 2.3 PL11] > > I never did understand how an 10-20% failure rate was ok, but > > that's likely my problem. > > > > Not really. I frankly don't believe the failure rate is all that high. > > I believe my estimate to be conservative on the measure of success. > > I think I understand the analysis. What I do not understand is how we can > find failures acceptable, whether they are 20% or 2%. It seems to me that clear concensus of the DNS SEC meeting among the DNS experts is that 20% or 2% is a problem. But, it does not matter so much, if packet size of 1500 is available without pain. It all depends on how DNS v2 will be. So, what we need for further discussion on the issue is a rather stable and concrete proposal of DNS v2. Without it, only Vixie can say something which can not be a discussion. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa03126; 3 Aug 94 0:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma016701; Wed Aug 3 00:24:00 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Aug 94 13:15:29 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408030415.AA15431@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Wed, 3 Aug 94 13:15:27 JST Cc: galvin@tis.com, dns-security@tis.com In-Reply-To: <9408021912.AA10180@relay.tis.com>; from "Steve Kent" at Aug 2, 94 3:11 pm X-Mailer: ELM [version 2.3 PL11] > I think a hybrid scheme, with Ohta's simplier structure for > signing records and storing keys, but with the E-K approach to > forward, reverse and cross-certificates (with carefully specified > rules on allowed certification paths to avoid the problems Ohta and > other were concerend about), Beside simplicity, the authentication chain should be the most important difference between two proposals. But, why do you think we need "forward, reverse and cross-certificates"? "titech.ac.jp" and "bbn.com" can cross-certificate each other by configuring each name servers as secondary of the other. Childs of each zone may also do so or may use "forwarder" mechanism. The mechanism is safe, even if the root zone is compromized. So, why do we need "forward, reverse and cross-certificates" mechanism which is not existing-DNS-friendly? secondary   Received: from sol.tis.com by magellan.TIS.COM id aa04022; 3 Aug 94 10:36 EDT Message-Id: <9408031437.AA22269@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma022254; Wed Aug 3 10:36:45 1994 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 94 13:15:27 +0200. <9408030415.AA15431@necom830.cc.titech.ac.jp> Date: Wed, 03 Aug 94 10:33:37 -0400 From: Steve Kent I am generally a supporter of top-down certification, as anyone familiar with PEM will attest. I also suggested that we can ask the managers of the DNS root and top level domains to see if they will be quick to sign the records that they have responsibility for, rather than assuming that it will be hard to get these folks to "sign up" for this service. However, I've seen a lot of email traffic suggesting that the top level domains representing countries do exhibit widely varying levels of service, so it may be the case that these domains will not be uniformly quick to support this technology. That argues for allowing one-hop cross-certification, to enable domains to bridge the gaps that may be arise. Also, I agree with Charlie's argument that such cross-certificates are helpful during start up. I'm less persuaded by the argument Steve Bellovin put forth, about companies needing to trust only one another in this scheme, because if cross-certification were common place, rather than the exception, I think the system would be quite unmanageable. I've found many folks who believe that, in general, the higher tier domains are well run and are thus more likely to do a good job of managing this certification process. Many argue that lower tier domains are often poorly managed today, which leads one to question how trusting them to manage the added burden of cross-certificates will make the system more secure! Nonetheless, if the one-hop rule for cross-certification is rigorously enforced in the client software, then cross-certification seems like a reasonable tact. Because the DNS certification hierarchy does not have a PCA tier like the PEM system, and because there is an existing root, some of the reasons that cross-certification is banned in RFC 1422 don't really apply here. (Conversely, the lack of PCAs also argues that the certificates that result from this system will not be appropriate for non-repudiation purposes.) As for the reverse certificates, there are two major arguments in favor of this construct. One argument in favor of forward certificates is that they facillitate use of cross-certificates. The other is that they facilitate switching over to a new root key. The later argument is based on the observation that when such a changeover is required, it is easier to effect if the change need be propogated to only the top level domains, i.e., the ones immediately inferior to the root. In general, when a new key pair is employed anywhere in the system, the affected node must resign data for all of the immediately inferior nodes, and these nodes must each resign their reverse certificates. (Any cross-certificates associated with the affected node also must be reissued.) At any node other than the root, this entails more work than in a system that has only forward certificates. However, in a system with only forward certificates, every node must have the root public key and the distribution of such a new key is obviously a big task. The concern about the logistics of this changeover motivate the use of reverse certificates, as they avoid the need for every node to acquire the root key directly. If one can propose a specific changeover strategy that does not entail the use of reverse certificates, that would help. Use of reverse certificates doubles the storage requirements for certificates in the servers and, in the absence of caching, it generally doubles the certification path length. If caching is used, then the validation burden is lessened, but cache storage requirements grow considerably as well. Moreover, folks are talking about relatively short lifetimes for the certificates, to compensate for the lack of other timeliness safeguards in the DNS interactions. So, caching of certificates may not be as big a win here as in other contexts. Nonetheless, a concrete proposal for root key changeover, that does not require reverse certificates, would help. Personally, I don't think the root key will need to be changed very often, if the root makes use of appropriate security technology and procedures. I am familiar with an existing system that adopts a top-down approach, has over 350,000 leaf nodes, and which supports periodic root key changeover. It does the changeover incrementally, with the old and new keys being valid for an overlapped interval, allowing time for all the leaves to get the new key, which is distributed under the old key. In this system, the leafs are all directly under the root (a very shallow hierarchy) and thus all the leaves must get new certificates as well, a rather major re-distribution activity since the nominal lifettime for the leaf keys is one year. Such a changeover has been effected once already for the system, over the course of several years of operation. So, it can be done, but the details need to be worked out for each specific system. However, for those who feel that cross-certificates are essential, for whatever reason, even solving the root key changeover problem will not do away with the reverse certificate requirement. In that light, it may not be worth the effort to design a root key changeover procedure. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05036; 3 Aug 94 13:30 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma025217; Wed Aug 3 13:30:56 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA23999; Wed, 3 Aug 94 13:30:05 EDT Message-Id: <9408031730.AA23999@tis.com> Reply-To: James M Galvin To: kaufman@zk3.dec.com Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: kaufman@zk3.dec.com's message of Tue, 02 Aug 1994 16:55:18 EDT. <9408022055.AA21666@alpha.zk3.dec.com> Date: Wed, 03 Aug 1994 13:30:12 -0400 From: James M Galvin There might be a more forceful statement that no consensus was reached on any of the controversial statements (including whether hacks to keep responses as small as possible are necessary) and that discussion would continue on the list. I've added the following statement to the last paragraph of the minutes: Since consensus was not possible within the timeframe allotted for the working group meeting, further discussion of the relative merits of each proposal will continue on the mailing list. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa05227; 3 Aug 94 14:37 EDT Received: from mordor.stanford.edu(36.53.0.155) by relay via smap (V1.3) id sma026467; Wed Aug 3 14:38:06 1994 Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA25381; Wed, 3 Aug 1994 11:37:13 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Aug 1994 11:37:18 -0700 To: Steve Kent From: Dave Crocker Subject: Re: draft DNS Security WG minutes Cc: Masataka Ohta , dns-security@tis.com > Many argue that lower tier >domains are often poorly managed today, which leads one to question >how trusting them to manage the added burden of cross-certificates >will make the system more secure! Unfortunately, this is a fair concern. On the other hand, such folk are also going to be required to manage telent, ftp, and other access to/for their organization well-enough. So the result will be that their DNS records will be (only) as good as their administration. On the other hand, I don't see how a multi-level inheritence model improves on the flakiness of a site. At best, it maintain it. At worst, it adds more opportunities for flakiness (though probably less likely, as you observe.) ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA)   Received: from sol.tis.com by magellan.TIS.COM id aa05278; 3 Aug 94 14:52 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma026815; Wed Aug 3 14:53:11 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA28694; Wed, 3 Aug 94 14:52:22 EDT Message-Id: <9408031852.AA28694@tis.com> Reply-To: James M Galvin To: minutes@cnri.reston.va.us Cc: dns-security@tis.com Subject: DNS Security Working Group Minutes Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa1" Date: Wed, 03 Aug 1994 14:52:28 -0400 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <4466.775939930.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4466.775939930.3@tis.com> Please find enclosed below the minutes of the DNS Security Working Group July 1994 (Toronto) Meeting for inclusion in the proceedings. Jim Galvin Chair ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4466.775939930.4@tis.com> Content-Description: DNSSEC WG minutes DNS Security WG Meeting Minutes July 1994 Toronto Recorded by Jim Galvin, Chair The DNS Security Working Group met on Wednesday morning for a 2.5 hours meeting. Masataka Ohta had previously submitted an alternative to the Donald Eastlake and Charlie Kaufman proposal. The majority of this meeting was dedicated to discussing the differences between the two proposals. The meeting began with Jim Galvin presenting a very brief summary of his implementation experience with the Eastlake/Kaufman proposal. No cryptography was implemented; in the interests of simplicity and expediency, values were exclusive-ored instead. Also, only the direct resource records were prototyped. Two results were reported: it is possible to implement the proposal and the proposal includes more options than are needed. Jim observed that one of the principal motivations for many of the options in the Eastlake/Kaufman proposal was the perception that the 512 byte limit for DNS messages was too small. However, he asserted that this limit was in fact not an issue, for two reasons that would be explained later. As a result, he had a proposal for how to proceed but preferred to yield the floor to the Kaufman and Ohta for a discussion of their lists of issues. The remainder of the meeting was dedicated to Kaufman and Ohta each presenting a list of questions and comments about each others' proposals. There was a great deal of vigorous and animated discussion about the issues. Careful time management allowed a complete presentation of all the issues, with some discussion for each, although no conclusions were reached. Since both Ohta and Kaufman agreed to distribute their lists to the electronic mailing lists for continued discussion and resolution, the details are not presented here. The meeting closed with Jim proposing that Eastlake/Kaufman reduce their proposal to include only the hashed resource record, for two reasons. First, there is the assertion that the 512 byte limit would be sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit. TIS will implement the proposed DNS security enhancements with this new version of DNS. Jim will followup with Eastlake and Kaufman about reducing their proposal, identified as Eastlake/Kaufman-lite. Since consensus was not possible within the timeframe allotted for the working group meeting, further discussion of the relative merits of each proposal will continue on the mailing list. The Chair agreed to propose criteria that could be used to evaluate the two proposals --- Eastlake/Kaufman-lite and Ohta --- to aid the working group in selecting one to submit to the standards track. Consensus and a single proposal will be obtained on the mailing list prior to the next IETF; this group expects to meet in San Jose. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/signature Content-ID: <4466.775939930.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,TTHTYlpfSeX5vN9nvjcYomGZ/KE/Ng+YPl2OCmkNY0q1TVztfu4J= BZC5LllMqHW48LR3xV8yLJ5RNqNpKrwZ8JA/e3KV+GO6AFRiqK9Z2Y5IzERFxJ9A2HVHY/oEWJ= lm ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa05567; 3 Aug 94 16:29 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3) id sma028338; Wed Aug 3 16:11:59 1994 Received: by atc.boeing.com (5.57) id AA25721; Wed, 3 Aug 94 13:13:49 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA24439; Wed, 3 Aug 94 13:12:02 -0700 Received: by commanche.ca.boeing.com. (AIX 3.2/UCB 5.64/4.03) id AA22467; Wed, 3 Aug 1994 13:10:48 -0700 Message-Id: <9408032010.AA22467@commanche.ca.boeing.com.> To: kent@bbn.com Cc: galvin@tis.com, dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: (Your message of Tue, 02 Aug 94 15:11:58 D.) <9408021912.AA10180@relay.tis.com> Date: Wed, 03 Aug 94 13:10:47 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Steve In response to your suggestion that an analysis of the length of the typical DNS server responses was needed. We trapped four hours of data on one of our busier servers here at Boeing. We have twenty-some others active as primary/secondaries within the corporation. It makes for some interesting discussion and probably asks more questions than it answers alone. The address has been blanked per security. Take care Terry L. Davis | 206-957-5325 | tld5032@commanche.ca.boeing.com. Charles DeRykus | 206-957-5326 | ced@carios2.ca.boeing.com. Boeing Computer Services, Bellevue, WA --------------- Wednesday August 03,1994 12:57 PM PDT ------------- == As always, the above cannot be construed as representing BOEING. == ---------------------------------------------------------- ---------------------------------------------------------- DNS Server -- Packet Len Data ---------------------------------------------------------- Wed Aug 3 07:19:45 PDT 1994 analysing dns packets to xxx.xx.xxx.xx from: host='*' begin: Wed Aug 3 07:19:46 PDT 1994 end: Wed Aug 3 11:20:07 PDT 1994 query total: 90235 Packet Size No. of Requests ----------- --------------- 553 1 550 1 422 34 421 5 412 1 357 1 335 1 320 1 317 1 316 1 255 27 254 3 253 1 252 1 246 1 240 1 226 2 222 1 220 1 217 2 216 16 210 1 208 4 204 35 201 1 193 1 178 1 175 6 174 2 173 198 172 267 171 303 170 5 169 2 167 1 166 3 165 19 164 21 163 55 162 88 161 181 160 200 159 315 158 1347 157 331 156 548 155 326 154 126 153 94 152 48 151 204 150 95 149 123 148 58 147 43 146 263 145 367 144 3472 143 256 142 215 141 284 140 648 139 460 138 3267 137 2031 136 407 135 34 134 44 133 37 132 2 131 9 130 1 129 3 128 4 127 2 126 2 125 6 124 2 123 17 122 41 121 33 120 26 119 22 118 15 117 5 116 4 115 5 114 6 113 5 112 4 111 1 110 24 109 6 108 5 107 1 106 8 105 13 104 6 103 3 102 14 101 106 100 136 99 171 98 181 97 334 96 519 95 1553 94 654 93 920 92 1986 91 886 90 3736 89 2754 88 1176 87 5235 86 6099 85 2954 84 4344 83 4099 82 2694 81 12039 80 2040 79 1594 78 5505 77 1848 76 472 75 953 74 772 73 3271 72 2074 71 414 70 34 69 57 68 35 67 2 66 9 65 1 63 1 60 1342   Received: from sol.tis.com by magellan.TIS.COM id aa05753; 3 Aug 94 18:15 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma000266; Wed Aug 3 18:16:22 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA17478; Wed, 3 Aug 94 18:14:28 EDT Date: Wed, 3 Aug 94 18:14:28 EDT From: Theodore Ts'o Message-Id: <9408032214.AA17478@tsx-11.MIT.EDU> To: Masataka Ohta Cc: Steve Kent , galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Wed, 3 Aug 94 13:15:27 JST, <9408030415.AA15431@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Wed, 3 Aug 94 13:15:27 JST X-Mailer: ELM [version 2.3 PL11] But, why do you think we need "forward, reverse and cross-certificates"? "titech.ac.jp" and "bbn.com" can cross-certificate each other by configuring each name servers as secondary of the other. This is not correct; merely configuring a nameserver to secondary off of another does not imply that the two domains have cross-certified each other. Every domain is required to set up secondary name servers; this does not imply that each domain will be setting up cross-certificates! - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa05764; 3 Aug 94 18:17 EDT Message-Id: <9408032218.AA00296@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma000291; Wed Aug 3 18:18:21 1994 To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue,\ WA" Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 94 13:10:47 -0800. <9408032010.AA22467@commanche.ca.boeing.com.> Date: Wed, 03 Aug 94 18:16:54 -0400 From: Steve Kent Terry, Thanks for the data. This is exactly the sort of info I think one needs to be able to make some projections about the impact of signatures on DNS accesses. It will, as you suggested, take some time to analyze, and I hope other DNS operators will follow your lead and gather the same sort of data. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05809; 3 Aug 94 19:00 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma001124; Wed Aug 3 19:01:12 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA17936; Wed, 3 Aug 94 19:00:55 EDT Date: Wed, 3 Aug 94 19:00:55 EDT From: Theodore Ts'o Message-Id: <9408032300.AA17936@tsx-11.MIT.EDU> To: Steve Kent Cc: Masataka Ohta , dns-security@tis.com In-Reply-To: Steve Kent's message of Wed, 03 Aug 94 10:33:37 -0400, <9408031437.AA22269@relay.tis.com> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 There is another reason for reverse certificates, which is limiting the number of keys that you need to trust. For example, if your hierarchy is: UN US USSR Army Navy Alice Bob One can make the argument that Alice, in the the U.S. Army, and Bob, in the U.S. Navy, should be able to authenticate to one another without needing to trust the U.N. The reverse certificates provide this because they allow Alice can verify Bob's key using the two reverse certificates (Alice->Army, Army->US), and two forward certificates (US->Navy, Navy->Bob) starting from a locally known, trusted key (Alice's). In contrast, in the top down certification, Alice would have to check three forward certificates (UN->US, US->Navy, Navy->Bob), starting from the U.N.'s key. Perhaps this means that you "obviously" don't put an untrusted organization (like the U.N.) at the top of the hierarchy. But if two users in LCS.MIT.EDU and AI.MIT.EDU want to authenticate to each other, why should they need to rely on anyone's keys at the root level? After all, they need to rely on the security of the keys closest to them anyway, so why add extra trust requirements? - Ted P.S. Also note that the above example also shows that the reverse certificates do not necessarily double the certification chain, compared to the top-down approach. It all depends on how many zones there are between you and the root. In some cases, the reverse certificate approach might actually require fewer certificate verifications!   Received: from sol.tis.com by magellan.TIS.COM id aa05935; 4 Aug 94 3:04 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma005448; Thu Aug 4 03:05:26 1994 Received: by gw.home.vix.com id AA27273; Thu, 4 Aug 94 00:05:09 -0700 Date: Thu, 4 Aug 94 00:05:09 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: <9408032300.AA17936@tsx-11.MIT.EDU> Nntp-Posting-Host: office.home.vix.com In-Reply-To: tytso@athena.mit.edu's message of 3 Aug 1994 17:01:09 -0700 Agreed. In Ted's example, LCS and AI should be able to learn to trust each other if they both trust MIT. EDU and Root shouldn't (have to be) involved. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa06639; 4 Aug 94 10:10 EDT Message-Id: <9408041411.AA10040@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma010034; Thu Aug 4 10:10:57 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 94 19:00:55 -0400. <9408032300.AA17936@tsx-11.MIT.EDU> Date: Thu, 04 Aug 94 10:07:46 -0400 From: Steve Kent Ted, My comments were to be interpreted strictly in the context of the DNS, where the hierarchy is already well defined and where the mapping between those who already control the name space in question and the certification hierarchy could be a homomorphism. Your example is from a different context, one that mixes DNS-style names and X.500- style directory strucure, a hierarchy that does not exist. Nonetheless, your point about a motivation for cross-certificates being appropriate when the higher tiers are not trusted by lower tiers to vouch for identity is generally true. There is a subtle point here, namely that an authority who is recognized as empowered to manage a portion of a name space does is not necessarily trusted by subordinate entities to authenticate them in that name space. This concept was recognized in the PEM hierarchy by not requiring name subordination starting at the root, but rather requiring it only below the third tier in the hierarchy, at the organizational and geopolitical tier. However, because the top two tiers of that design embody semantics that is not derrivable from name formats, and because of the limitations of X.509 certificate formats, it was not possible to syntactically implement the sort of limited cross-certification that the E-K proposal calls for in the DNS context. For example, a cross-certificate that transitioned from one PCA domain to another would not have been automatically detectable by a user following a certification path. As for doubling certification path length, you're right that cross-certificates can actually shorten the length, if they are used as short-cuts between relatively deep points in the hierarchy. However, if they are used primarily at the organization level (rather than at subordinate organizations, etc.), then in the current DNS structure it is likely that they will not really shorten path lengths and probably will lengthen them. Also, I think my comment focused on the use of reserve-certificates per se, where this observation is true, as opposed to reverse certificates plus cross-certificates. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa06865; 4 Aug 94 10:29 EDT Received: from venera.isi.edu(128.9.0.32) by relay via smap (V1.3) id sma010088; Thu Aug 4 10:13:27 1994 Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 4 Aug 1994 07:09:25 -0700 Message-Id: <199408041409.AA09987@venera.isi.edu> To: Steve Kent Cc: Masataka Ohta , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 1994 10:33:37 -0400. <9408031437.AA22269@relay.tis.com> Date: Thu, 04 Aug 94 07:08:10 PDT From: Paul Mockapetris Regardless of which system is adopted, we probably need a model that allows the system to be tested and developed without root participation. Also, since the DNS root is international, we may find ourselves down a policy rathole. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa07830; 4 Aug 94 15:36 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma015935; Thu Aug 4 15:36:57 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA02226; Thu, 4 Aug 94 15:36:30 EDT Date: Thu, 4 Aug 94 15:36:30 EDT From: Theodore Ts'o Message-Id: <9408041936.AA02226@tsx-11.MIT.EDU> To: Steve Kent Cc: Theodore Ts'o , dns-security@tis.com In-Reply-To: Steve Kent's message of Thu, 04 Aug 94 10:07:46 -0400, <9408041410.AA28462@MIT.EDU> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Well, I can certainly come up with examples that are DNS-centric, as opposed to the X.500-style example that I came up with; I simply chose that because it was more "vivid" an example. :-) But there are others that I could come up with, involving transferring grades (aka educational records) between someone at prof@lcs.mit.edu and TA@ai.mit.edu --- or personnel information between AO@research.ibm.com and reorg@corporate.ibm.com where there might very well be strong reasons why MIT and IBM might want some sort of authentication which didn't rely on the trustworthiness of the root servers. There is a valid question of how often these sorts of things come up --- which should drive whether they should be better handled as special-case "cross-certificates", or whether we should use a more general approach using the "up" and "down" certifications of the E-K proposal. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa07939; 4 Aug 94 16:45 EDT Message-Id: <9408042046.AA17055@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma017047; Thu Aug 4 16:46:13 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Thu, 04 Aug 94 15:36:30 -0400. <9408041936.AA02226@tsx-11.MIT.EDU> Date: Thu, 04 Aug 94 16:43:12 -0400 From: Steve Kent Ted, I'm much more comfortable with having a general purpose mechanism for allowing cross-certification within the DNS hierarchy, so that client and server software is generally availabel to do "the right thing," than making special arrangements that would not be readily supported by COTS software. However, I think we need to keep in mind the added complexity of having folks manage cross-certificates, especially in light of the stories I hear about less than ideal management of parts of the current system elements. One should not design on the assumption that cross-certificates would be required in general, since the fan out on cross-certificates could be horrible. One should push for forward certificates from the root, and allow for cross certificates on an as needed basis (and for experiementation and initial deployment). This is the model Charlie articulated last week and its one I'm comfortable with. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa08107; 4 Aug 94 18:40 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma018503; Thu Aug 4 18:40:25 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA05913; Thu, 4 Aug 94 18:40:01 EDT Date: Thu, 4 Aug 94 18:40:01 EDT From: Theodore Ts'o Message-Id: <9408042240.AA05913@tsx-11.MIT.EDU> To: Steve Kent Cc: Theodore Ts'o , dns-security@tis.com In-Reply-To: Steve Kent's message of Thu, 04 Aug 94 16:43:12 -0400, <9408042045.AA25397@MIT.EDU> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Thu, 04 Aug 94 16:43:12 -0400 From: Steve Kent I'm much more comfortable with having a general purpose mechanism for allowing cross-certification within the DNS hierarchy, so that client and server software is generally availabel to do "the right thing," than making special arrangements that would not be readily supported by COTS software. However, I think we need to keep in mind the added complexity of having folks manage cross-certificates, especially in light of the stories I hear about less than ideal management of parts of the current system elements. One should not design on the assumption that cross-certificates would be required in general, since the fan out on cross-certificates could be horrible. One should push for forward certificates from the root, and allow for cross certificates on an as needed basis (and for experiementation and initial deployment). This is the model Charlie articulated last week and its one I'm comfortable with. I think there's a disconnect here somewhere, perhaps in our use of terminologies. In the E-K proposal, there are three kinds of certificates. "Down" certificates, where the parent node certifies the child, "Up" certificates, where the child certifies the parent, and "Cross" certificates where a node certifies some other node which is neither a child nor a parent. (I don't know if they are using these terms, but this is the basic concept in the DASS/SPX model, which is carried over in the E-K proposal, as I understand things.) In the examples that I gave, there weere no cross certificates; there were simply "up" certificates and "down" certificates --- and so without needing any cross certificates, it is possible for users in LCS.MIT.EDU and AI.MIT.EDU to certify one another without needing to trust the root. The claim is that "Up" certificates are not particular hard to manage, compared to "Cross" certificates, since like "Down" certificates, they have a well defined semantic meaning --- this is a certification by a child of its parent's public key. Are you disputing this claim, or the claim that the applications detailed in my last message cannot be accomplished without "Cross" certificates. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa08502; 5 Aug 94 4:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma022627; Fri Aug 5 03:54:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 5 Aug 94 16:45:43 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408050745.AA01836@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Fri, 5 Aug 94 16:45:42 JST Cc: dns-security@tis.com In-Reply-To: <9408031428.AA17783@necom830.cc.titech.ac.jp>; from "Steve Kent" at Aug 3, 94 10:33 am X-Mailer: ELM [version 2.3 PL11] > I am generally a supporter of top-down certification, as > anyone familiar with PEM will attest. I also suggested that we can > ask the managers of the DNS root and top level domains to see if they > will be quick to sign the records that they have responsibility for, > rather than assuming that it will be hard to get these folks to "sign > up" for this service. However, I've seen a lot of email traffic > suggesting that the top level domains representing countries do > exhibit widely varying levels of service, so it may be the case that > these domains will not be uniformly quick to support this technology. > That argues for allowing one-hop cross-certification, to enable > domains to bridge the gaps that may be arise. Also, I agree with > Charlie's argument that such cross-certificates are helpful during > start up. I'm less persuaded by the argument Steve Bellovin put > forth, about companies needing to trust only one another in this > scheme, because if cross-certification were common place, rather than > the exception, I think the system would be quite unmanageable. Then, what we need is not cross certification, but authentication roots other than the DNS root. Moreover, field of ZSIG RR in my proposal is the mechanism to support it, I think. For example, "masterauthenticator.int" can be a signer of "bbn.com" and "titech.ac.jp" and all the name servers in "bbn.com" and "titech.ac.jp" should have some information, for example, MD5 of the zones public key, to authenticate "masterauthenticator.int". The machanism also allows the root zone sign "titech.ac.jp" without signing "ac.jp" nor "jp". So, aren't your requirements satisfied? > I've found many folks who believe that, in general, the higher > tier domains are well run and are thus more likely to do a good job of > managing this certification process. Many argue that lower tier > domains are often poorly managed today, which leads one to question > how trusting them to manage the added burden of cross-certificates > will make the system more secure! Cross-certificates, in one sense, make the system less secure. Currently, resolvers are tied to name servers (SBELT) but not tied to any zone. (Donald-Charile draft is confused on this point that they think name servers are tied to zones they serve, but the issue is a resolver issue) Thus, with the hierarchical scheme, compromizing of a zone only affect zones below it. Moreover, if SBELT hosts are configured with a public key of a foreign zone, the resolver is further protected from the compromized parent zone of the foreign zone. On the other hand, if an SBELT host is compromized, the resolver is compromized. But with a resolver tied to a zone, compromizing of zones above the resolver's zone affect all the queries the resolver makes with false cross certificates. So, the issue is whether we trust SBELT hosts, which are expected to be local, and a root zone or parent zones of some zone > However, in a system with only forward certificates, every node must > have the root public key and the distribution of such a new key is > obviously a big task. The concern about the logistics of this > changeover motivate the use of reverse certificates, as they avoid the > need for every node to acquire the root key directly. That mechanism to dynamically changes information on root name servers has been available for a long time. The problem was that the information was not reliable. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08776; 5 Aug 94 5:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma022814; Fri Aug 5 04:39:52 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 5 Aug 94 17:30:07 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408050830.AA02170@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Fri, 5 Aug 94 17:30:05 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408032214.AA17478@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 3, 94 6:14 pm X-Mailer: ELM [version 2.3 PL11] > But, why do you think we need "forward, reverse and cross-certificates"? > > "titech.ac.jp" and "bbn.com" can cross-certificate each other > by configuring each name servers as secondary of the other. > > This is not correct; merely configuring a nameserver to secondary off of > another does not imply that the two domains have cross-certified each > other. Oops, OK, first of all, in the current DNS model, entities who ask a query may not belongs to DNS tree at all. Even if the entity has a domain name, it has not necessarily the name from which the upward query starts. Even if the entity is a name server serving several zones, it has not necessarily the zone(s) from which the upward query starts. So, saying "cross-certificate" is rather meaningless. When I wrote: > "titech.ac.jp" and "bbn.com" can cross-certificate each other > by configuring each name servers as secondary of the other. it meant that resolvers asking name servers of "titech.ac.jp" about data in "bbn.com" won't be affected by the compromized "com" or "." zone and vice versa. I also assume, as written in my draft, that secondaries statically knows public key (or something like that) of the zone it serves. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09428; 5 Aug 94 11:50 EDT Message-Id: <9408051551.AA26805@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma026801; Fri Aug 5 11:51:26 1994 To: Masataka Ohta Subject: Re: draft DNS Security WG minutes Cc: dns-security@tis.com Date: Fri, 05 Aug 94 11:48:57 -0400 From: Steve Kent Ohta san, One could have authentication roots other than the DNS root, and that is what cross-certificates, or following reverse certificates to a common ancestor, allows. A cross-certificate enables a node (e.g. an organization) to make an explicit assertion that it trusts another node without having to trust nodes higher in the certification tree. A cross-certificate is generally assumed to be manually configured and thus maintenance of cross-certificates is potentially a labor intensive activity. So, without creating any new nodes or pseudo-nodes, one can express these trust relationships whenever it is deemed necessary, e.g., whenever the parties in question do not have adequate trust in superior nodes. I agree that cross-certificates can make the system less secure, but, as pointed out last week, errors (or malicious attacks) in configuring cross-certificates affect only those nodes lower in the certification tree. If one employs cross-certificates only at the organizational level, then this bounds the damage "appropriately." I think the arguments presented in favor of cross-certification don't apply very well if, for example, cross-certificates were employed at TLDs like COM or EDU. I think I understand your comments about about the association between resolvers and name servers vs. zones. The E-K proposal does assume, I believe, that a client (resolver) making a query is a client of some zone, and thus can easily acquire (via local, integrity-secure means) the public key of that zone. That key represents the operable part of the up-certificate from that resolver to the zone, and thus is the basis for starting an up-certification path. I believe your point is that if resolvers don't have such a close association to zones, but rather to servers (which are not represented as secure entities in our models), then the task of acquiring some zone key as a starting point is no easier than acquiring the root key, maybe even harder. Also, if a resolver does not have an affiliation with a zone, then the trust arguments that motivate cross-certificates are not applicable, either. Is this an accurate paraphrase of your concerns? As for the final point, about root key changeover, remember that the requirement here is to be able to distribute a new one to all the resolvers. If the change is just a "preventative maintenance" measure, then I agree that it can be effected in an orderly fashion using the old key. There is a concern that a compromise of the root key would make it very hard to distribute a new one, and so that possibility is the one that the up-certificate approach tends to address better than a pure top-down model. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa09450; 5 Aug 94 11:56 EDT Message-Id: <9408051557.AA26949@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma026938; Fri Aug 5 11:56:37 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Thu, 04 Aug 94 18:40:01 -0400. <9408042240.AA05913@tsx-11.MIT.EDU> Date: Fri, 05 Aug 94 11:55:07 -0400 From: Steve Kent Ted, I apologize for getting lost in our discussion. The terminology I was using is from X.509, where up-certificates are referred to as reverse-certificates, forward-certificates are the equivalent of down-certificates, and cross-certificates are more or less the same. You are right that your examples required only up (reverse) certificates, not cross certificates. In the DNS example, because of the existing tree structure and name constraints, one can use up certificates alone to minimize trust in the top-most tiers, but only if there is a lower node that they trust and which is a common ancestor. Examples given by other folks to motivate cross-certificates focus on inter-organization relationships at higher tiers, where there was no common ancestor node that was trusted. In those cases, cross-certificates are needed to avoid trust in the root or in TLDs such as COM. Sorry for the confusion, Steve   Received: from sol.tis.com by magellan.TIS.COM id aa10306; 5 Aug 94 17:08 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma002395; Fri Aug 5 17:09:07 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA26388; Fri, 5 Aug 94 17:07:58 EDT Date: Fri, 5 Aug 94 17:07:58 EDT From: Theodore Ts'o Message-Id: <9408052107.AA26388@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Fri, 5 Aug 94 17:30:05 JST, <9408050830.AA02170@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Fri, 5 Aug 94 17:30:05 JST When I wrote: > "titech.ac.jp" and "bbn.com" can cross-certificate each other > by configuring each name servers as secondary of the other. it meant that resolvers asking name servers of "titech.ac.jp" about data in "bbn.com" won't be affected by the compromized "com" or "." zone and vice versa. And how do resolvers asking the name servers of "titech.ac.jp" know that they really got an answer from "titech.ac.jp"? Are you assuming authentication by IP address, ala rlogin? - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa12538; 8 Aug 94 7:38 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma012767; Mon Aug 8 07:38:49 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA07338; Mon, 8 Aug 94 07:37:39 EDT Date: Mon, 8 Aug 94 07:37:39 EDT From: Theodore Ts'o Message-Id: <9408081137.AA07338@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Mon, 8 Aug 94 13:44:55 JST, <9408080445.AA05157@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Mon, 8 Aug 94 13:44:55 JST > Are you assuming > authentication by IP address, ala rlogin? No. Resolvers retrieve authenticated data through authenticated communication between SBELT or co-located name servers. Your claim is that you can deal with the cross-certification issue by merely making one site (titech.ac.jp) be a secondary for another (bbn.com). This doesn't work. Merely making one site be a secondary for another doesn't change the fact that the zone key for bbn.com is still signed by the com public key --- which may have been spoofed. There is no authenticated communication between the resolver and the nameserver; the nameserver only hands back signed records, and changing where you get the information by having the resolver talk to a secondary does not change who has signed the records. Hence, your suggested solution of making titech.ac.jp be a secondary for bbn.com has no cryptographic significance, and is rather pointless. If you are suggesting a solution where you have authenticated communication between the resolver and the name server, recall that this requires that the zone private key (or at least some other private key) must be on-line on the name server. This is considered a Bad Thing, for the obvious security reasons. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa12043; 8 Aug 94 1:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma011427; Mon Aug 8 00:53:17 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 13:44:57 +0859 From: Masataka Ohta Return-Path: Message-Id: <9408080445.AA05157@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Mon, 8 Aug 94 13:44:55 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408052107.AA26388@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 5, 94 5:07 pm X-Mailer: ELM [version 2.3 PL11] > > "titech.ac.jp" and "bbn.com" can cross-certificate each other > > by configuring each name servers as secondary of the other. > > it meant that resolvers asking name servers of "titech.ac.jp" about > data in "bbn.com" won't be affected by the compromized "com" or "." > zone and vice versa. > > And how do resolvers asking the name servers of "titech.ac.jp" know that > they really got an answer from "titech.ac.jp"? Don't assume PEM environment where both senders and recipients have mail addresses. Resolvers don't get answer from "titech.ac.jp". Resolvers get answer from name servers. The name servers may or may not serve "titech.ac.jp". > Are you assuming > authentication by IP address, ala rlogin? No. Resolvers retrieve authenticated data through authenticated communication between SBELT or co-located name servers. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa12029; 8 Aug 94 1:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma011746; Mon Aug 8 01:54:48 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 14:45:18 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408080545.AA14050@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Mon, 8 Aug 94 14:45:17 JST Cc: dns-security@tis.com In-Reply-To: <9408051551.AA26805@relay.tis.com>; from "Steve Kent" at Aug 5, 94 11:48 am X-Mailer: ELM [version 2.3 PL11] > Ohta san, > > One could have authentication roots other than the DNS root, > and that is what cross-certificates, or following reverse certificates > to a common ancestor, allows. Fine. I think the following ZSIG mechanism already satisfies your requirements. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. ^^^^^^^^^^^^^^^^^^^^^^^^^^ [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . In general, only a who is a parent or ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ according to their local security policy. For the root zone or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. I provided the field partly because of initial deployment phase. Wordings on treatment of multiple ZSIGs should be added, I think. > A cross-certificate enables a node > (e.g. an organization) to make an explicit assertion that it trusts > another node without having to trust nodes higher in the certification > tree. Certainly. > A cross-certificate is generally assumed to be manually > configured and thus maintenance of cross-certificates is potentially > a labor intensive activity. Agreed. > So, without creating any new nodes or > pseudo-nodes, one can express these trust relationships whenever it is > deemed necessary, e.g., whenever the parties in question do not have > adequate trust in superior nodes. Yes, though I don't think it is so useful in the long run (because the third party is not protected from the malicious superior nodes). Anyway, singer mechanism of ZSIG does not need any new nodes nor pseudo-nodes. > I think I understand your comments about about the association > between resolvers and name servers vs. zones. The E-K proposal does > assume, I believe, that a client (resolver) making a query is a client > of some zone, and thus can easily acquire (via local, integrity-secure > means) the public key of that zone. That key represents the operable > part of the up-certificate from that resolver to the zone, and thus is > the basis for starting an up-certification path. OK, so far. > I believe your point > is that if resolvers don't have such a close association to zones, but > rather to servers (which are not represented as secure entities in our > models), then the task of acquiring some zone key as a starting point > is no easier than acquiring the root key, maybe even harder. Also, if > a resolver does not have an affiliation with a zone, then the trust > arguments that motivate cross-certificates are not applicable, either. > Is this an accurate paraphrase of your concerns? No. What if a host running resolver is compromised? In my model, a resolver may trust local name servers, just as the resovler must trust the very local host on which it is running. My point is that, if there is no strong reason to change DNS architecture, it should be kept as is. > As for the final point, about root key changeover, remember > that the requirement here is to be able to distribute a new one to all > the resolvers. No. "to all the name servers". Resolvers today are not configured with information on root. So, I didn't change it. How resolvers securely know root keys is, in my model, a separate issue. > If the change is just a "preventative maintenance" > measure, then I agree that it can be effected in an orderly fashion > using the old key. There is a concern that a compromise of the root > key would make it very hard to distribute a new one, and so that > possibility is the one that the up-certificate approach tends to > address better than a pure top-down model. An interesting point. But, if root is compromized, keys for "com." and "edu." can be forged, and then, keys for all the organizations can be forged. Revoking them all is a lot harder than redistribution of a new root key, I think. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa14413; 8 Aug 94 10:30 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma014103; Mon Aug 8 10:21:42 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09076; Mon, 8 Aug 94 10:20:59 EDT Date: Mon, 8 Aug 94 10:20:59 EDT From: Theodore Ts'o Message-Id: <9408081420.AA09076@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Mon, 8 Aug 94 21:39:58 JST, <9408081240.AA27960@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Mon, 8 Aug 94 21:39:58 JST No. First of all, as I already wrote to you, precisely speaking, it's not cross-cirtification, at all. Yes, it's not cross-certification at all. It's manual key exchange by another name. > This doesn't work. Merely making one site be a secondary for another > doesn't change the fact that the zone key for bbn.com is still signed by > the com public key --- which may have been spoofed. In my draft, "making one site be a secondary" means configuring the site with zone's public key (or something like that), which does not need com public key to authenticate. Right. I think our key problem is one of terminology. You have been continually redefining words away from their original meaning. Most people understand secondary to mean what it means in the DNS/BIND context --- which is reasonable, since this is the DNS security working group, after all. A secondary name server has a very well definied meaning, as does making one site be a secondary for another. You have an entirely different concept in mind, which is making communications difference. I am reminded of a quotation on Alice in Wonderland --- "A word means what says it means, no more, no less." Which is fine, but which is not very useful when you are trying to communicate to us. So what you are proposing is a method of manual key exchange --- in a method that's even more cumbersome than PGP's friends and family method. In fact, it's identical to what Kerberos administrators need to do now when they want to exchange a cross-realm key --- they meet at a Chinese restaurant, and write down a shared key on the back of a fortune cookie. If we're going to all of the trouble to use a patented public-key cryptrography solution, we might as well get some more benefit out of it than that. Granted, you only have to do it in the case where you don't trust the root, but using the reverse and forward certificates, it's all handled automatically, without the need for a manual key exchange. You still don't understand that, in existing DNS architecture, neither resolver nor name server is bound to a zone. No, but a resolver will tend to trust one zone more than another. In the worse case, system administrator who is designing the resolver can decide that it trusts the root, in which case the resolver's private key can be used to sign the root public key, instead of the public key of some zone. In this model, the security risks are the same as in a pure top-down approach. However, the administrator of a resolver should be able to choose to trust one zone's security administratoion more than another --- and the forward/reverse certificates allow you to do that. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa14772; 8 Aug 94 10:59 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma014275; Mon Aug 8 10:32:05 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09248; Mon, 8 Aug 94 10:31:39 EDT Date: Mon, 8 Aug 94 10:31:39 EDT From: Theodore Ts'o Message-Id: <9408081431.AA09248@tsx-11.MIT.EDU> To: tytso@mit.edu Cc: Masataka Ohta , kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Theodore Ts'o's message of Mon, 8 Aug 94 10:20:59 EDT, <9408081420.AA09076@tsx-11.MIT.EDU> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 8 Aug 94 10:20:59 EDT From: tytso@MIT.EDU (Theodore Ts'o) So what you are proposing is a method of manual key exchange --- in a method that's even more cumbersome than PGP's friends and family method. In fact, it's identical to what Kerberos administrators need to do now when they want to exchange a cross-realm key --- they meet at a Chinese restaurant, and write down a shared key on the back of a fortune cookie. Upon reviewing my words, I realized I spoke too quickly. What Ohta-San is suggesting is not precisely identical to manual key exchange --- you don't actually have to exchange keys. However, it still requires a manual certification of the zone's public key by the zone administrators. Hence, it requires the zone administrators either phyiscally meeting to verify the public key, or some other out of band method secured by public key (using PGP, perhaps) to establish the bona fides of the public key. In this way, it's identical to the requirement of Kerberos cross-authentication problem. The realm administrators either need to meet in person, or use PGP-authenticated and encrypted path to establish the shared session key. (The difference is that in Ohta-san's proposal, it doesn't need to be encrypted, although it still needs to be authenticated out of band.) Like the Kerberos cross-realm authentication, Ohta-san's proposal is an N**2 proposition, where as the reverse and forward certificates are an order N proposition. Finally, since the zone key is not actually signed, but merely configured on the "secondary", it's subject to modification and spoofing at a later date. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa15241; 8 Aug 94 12:00 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma015322; Mon Aug 8 11:35:46 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10233; Mon, 8 Aug 94 11:34:58 EDT Date: Mon, 8 Aug 94 11:34:58 EDT From: Theodore Ts'o Message-Id: <9408081534.AA10233@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Mon, 8 Aug 94 23:46:39 JST, <9408081446.AA01004@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Mon, 8 Aug 94 23:46:39 JST > No. First of all, as I already wrote to you, precisely speaking, it's > not cross-cirtification, at all. > > Yes, it's not cross-certification at all. It's manual key exchange by > another name. Without the forwarder mechanism I mentioned but you have failed to notice, yes. Great. I wish you had admitted this up-front, though. My apologies for my previous outburst, by the way; I let my frustration at your terminology (war is peace, freedom is slavery, cross-certification is manual key exchange) get the better of me. > You still don't understand that, in existing DNS architecture, neither > resolver nor name server is bound to a zone. > > No, but a resolver will tend to trust one zone more than another. A resolver, currently, tends to trust one name server, not one zone, more than another. Yes, but a nameserver isn't guaranteed to have a key (part of the design is that dns records could be signed off-line, so that a name server didn't need to have any trusted information on-line). Hence, you can't trust a name server without doing authentication by IP address. You can, however, trust a zone, since a zone which is playing the secure DNS game is guaranteed to have a key. > In > the worse case, system administrator who is designing the resolver can > decide that it trusts the root, in which case the resolver's private key > can be used to sign the root public key, instead of the public key of > some zone. Are you suggesting any change, or stating your view on the current resolver? I'm not suggesting any change. What I'm suggesting can be done now under the current E-K model. The question which zone a resolver "belongs" to is merely a question of which key does that resolver ultimately trust. If the resolver wants to ultimately trust the root, it can do so. If the resolver wants to trust, say, MIT or BBN, it can do so too. All it needs is to have the ability to get that one single key securely out of band, and sign it. Then, it can use the reverse and forward certificates (and cross-certificates, if they exist) to get from where it is to anywhere else in the tree. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa13103; 8 Aug 94 8:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma013206; Mon Aug 8 08:48:52 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 21:40:00 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408081240.AA27960@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Mon, 8 Aug 94 21:39:58 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408081137.AA07338@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 8, 94 7:37 am X-Mailer: ELM [version 2.3 PL11] > > Are you assuming > > authentication by IP address, ala rlogin? > > No. Resolvers retrieve authenticated data through authenticated > communication between SBELT or co-located name servers. > > Your claim is that you can deal with the cross-certification issue by > merely making one site (titech.ac.jp) be a secondary for another > (bbn.com). No. First of all, as I already wrote to you, precisely speaking, it's not cross-cirtification, at all. > This doesn't work. Merely making one site be a secondary for another > doesn't change the fact that the zone key for bbn.com is still signed by > the com public key --- which may have been spoofed. In my draft, "making one site be a secondary" means configuring the site with zone's public key (or something like that), which does not need com public key to authenticate. > There is no > authenticated communication between the resolver and the nameserver; There is. But I don't mind if you insists on using authentication by IP address. Your security is your problem. > the > nameserver only hands back signed records, and changing where you get > the information by having the resolver talk to a secondary does not > change who has signed the records. So what? > Hence, your suggested solution of making titech.ac.jp be a secondary for > bbn.com has no cryptographic significance, and is rather pointless. I never suggested such a thing. "titech.ac.jp" is a zone. "a secodary" is a name server. "a zone" != "a name server". Thus, it is completely pointless to say "making titech.ac.jp be a secondary". > If you are suggesting a solution where you have authenticated > communication between the resolver and the name server, recall that this > requires that the zone private key (or at least some other private > key) must be on-line on the name server. This is considered a Bad > Thing, for the obvious security reasons. You still don't understand that, in existing DNS architecture, neither resolver nor name server is bound to a zone. As a name server is bound to a host. Thus, the host's private key, whose correcponding public key can not be distributed by secure DNS and will be configured statically, will be used of course. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa14729; 8 Aug 94 10:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma014602; Mon Aug 8 10:54:42 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 23:46:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408081446.AA01004@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Mon, 8 Aug 94 23:46:39 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408081420.AA09076@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 8, 94 10:20 am X-Mailer: ELM [version 2.3 PL11] > No. First of all, as I already wrote to you, precisely speaking, it's > not cross-cirtification, at all. > > Yes, it's not cross-certification at all. It's manual key exchange by > another name. Without the forwarder mechanism I mentioned but you have failed to notice, yes. > You still don't understand that, in existing DNS architecture, neither > resolver nor name server is bound to a zone. > > No, but a resolver will tend to trust one zone more than another. A resolver, currently, tends to trust one name server, not one zone, more than another. > In > the worse case, system administrator who is designing the resolver can > decide that it trusts the root, in which case the resolver's private key > can be used to sign the root public key, instead of the public key of > some zone. Are you suggesting any change, or stating your view on the current resolver? > In this model, the security risks are the same as in a pure > top-down approach. However, the administrator of a resolver should be > able to choose to trust one zone's security administratoion more than > another --- and the forward/reverse certificates allow you to do that. The problem is whether such a change is necessary or not. I'm still unconvinced. But, I'm tired. I think I had better write a separate draft (about optional behaviour of resolvers) on how easily your requirement can be filfulled without changing the existing draft than spending time on ML discussion. Then, let someone else choose. Deal? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa17944; 9 Aug 94 8:33 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3) id sma023837; Tue Aug 9 08:33:59 1994 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 9 Aug 1994 05:32:30 -0700 From: Bill Manning Message-Id: <199408091232.AA22981@zephyr.isi.edu> Subject: Re: draft DNS Security WG minutes To: Masataka Ohta Date: Tue, 9 Aug 1994 05:32:30 -0700 (PDT) Cc: tytso@athena.mit.edu, kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408090540.AA00689@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Aug 9, 94 02:40:25 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1052 > > What I'm suggesting can be done now > > under the current E-K model. > > E-K model suggests too much unnecessary changes to the current DNS > architectture, which is, IMHO, fatal defect of the model. > > Thus, based on the same framework supported by WG consensus, I developped > a simpler model. > > Masataka Ohta > I feel I must interject here. There were a large number of concerns raised in the WG about your top-down approch. This does not indicate to me that the WG has reached a consensus based on your design, which is what I read in the statement above. Also, I do feel that there is a large contigent (including most of the existing developers and designers) that beleive that it will take a change in the DNS structure to support a good security model. This (dnssec) is one of the items driving the development of DNSv2. Attempts to provide security in the current model don't seem to meet the desired needs of the community, even though there are some clever ways to make the attempt. (Such as your model). -- bill   Received: from sol.tis.com by magellan.TIS.COM id aa17487; 9 Aug 94 1:47 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma022522; Tue Aug 9 01:48:04 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 9 Aug 94 14:40:26 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408090540.AA00689@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Tue, 9 Aug 94 14:40:25 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408081534.AA10233@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 8, 94 11:34 am X-Mailer: ELM [version 2.3 PL11] > > Yes, it's not cross-certification at all. It's manual key exchange by > > another name. > > Without the forwarder mechanism I mentioned but you have failed to > notice, yes. > > Great. I wish you had admitted this up-front, though. My apologies for > my previous outburst, by the way; I let my frustration at your > terminology (war is peace, freedom is slavery, cross-certification is > manual key exchange) get the better of me. Your frustration is your problem of having complete illusion on the exsiting DNS. > A resolver, currently, tends to trust one name server, not one zone, > more than another. > > Yes, but a nameserver isn't guaranteed to have a key (part of the design > is that dns records could be signed off-line, so that a name server > didn't need to have any trusted information on-line). Hence, you can't > trust a name server without doing authentication by IP address. My draft explicitely requires the communication between resolvers and SBELT name servers secure. Read it. > You > can, however, trust a zone, since a zone which is playing the secure DNS > game is guaranteed to have a key. In the current DNS, zones are not required to have keys. > Are you suggesting any change, or stating your view on the current > resolver? > > I'm not suggesting any change. You are suggesting a lot of changes. You just don't know how the current DNS is. > What I'm suggesting can be done now > under the current E-K model. E-K model suggests too much unnecessary changes to the current DNS architectture, which is, IMHO, fatal defect of the model. Thus, based on the same framework supported by WG consensus, I developped a simpler model. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa18852; 9 Aug 94 11:44 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma025931; Tue Aug 9 11:44:47 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09198; Tue, 9 Aug 94 11:44:13 EDT Date: Tue, 9 Aug 94 11:44:13 EDT From: Theodore Ts'o Message-Id: <9408091544.AA09198@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Tue, 9 Aug 94 14:40:25 JST, <9408090540.AA00689@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Tue, 9 Aug 94 14:40:25 JST > You > can, however, trust a zone, since a zone which is playing the secure DNS > game is guaranteed to have a key. In the current DNS, zones are not required to have keys. Ah, but if you're doing secure DNS, zones will have keys. Is this a change? Yes. Can you do secure DNS cleanly without requiring that zones have keys? No. > Are you suggesting any change, or stating your view on the current > resolver? > > I'm not suggesting any change. You are suggesting a lot of changes. You just don't know how the current DNS is. We are all suggesting changes to implement secure DNS. That is what this working group is all about. The question is how many changes we need to make. What I was trying to say was that what I was suggesting did not require any changes to the current E-K model. As for whether I know how the current DNS works, is not worth debating on this list. Having rumaged around within the source code of BIND, and done a lot of the work dealing with the MIT nameservers, I would beg to differ, but that's outside the scope of this list. > What I'm suggesting can be done now > under the current E-K model. E-K model suggests too much unnecessary changes to the current DNS architectture, which is, IMHO, fatal defect of the model. Thus, based on the same framework supported by WG consensus, I developped a simpler model. I disagree; and I disagree that you have any consensus supporting your ideas. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa19539; 9 Aug 94 16:16 EDT Message-Id: <9408092017.AA02040@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma002038; Tue Aug 9 16:17:05 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 09 Aug 94 11:44:13 -0400. <9408091544.AA09198@tsx-11.MIT.EDU> Date: Tue, 09 Aug 94 16:14:12 -0400 From: Steve Kent Ted, Ohta's proposal has many elements, and I agree with you that a combination of up, down and cross-certificates (with well-defined validation rules) is probably going to be more palatable to the WG overall than a top-down only scheme. However, I endorse the simplier, more algorithm independent signature record approach of Ohta's proposal and I don't think we should "throw the baby out with the certification hierarchy," to coin a new phrase. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa20703; 10 Aug 94 4:36 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma008981; Wed Aug 10 04:37:14 1994 Received: by gw.home.vix.com id AA02609; Wed, 10 Aug 94 01:36:49 -0700 Date: Wed, 10 Aug 94 01:36:49 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: Paul A Vixie Subject: Re: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: <199408091232.AA22981@zephyr.isi.edu> Nntp-Posting-Host: office.home.vix.com In-Reply-To: bmanning@isi.edu's message of 9 Aug 1994 06:40:36 -0700 >This (dnssec) is one of the items driving the development of DNSv2. That's true. >Attempts to provide security in the current model don't seem to meet the >desired needs of the community, even though there are some clever ways to >make the attempt. (Such as your model). That's not as obviously true, and maybe not true at all. I expect V2 to make things work _better_ but noone has asked for anything in V2 that will _only_ be used to enable security. I've offered a plan by which the most restrictive aspects of V1 (lack of MBZ header bits, limited packet size) can be worked around while V2 proceeds somewhat independently. If you folks are going to hinge DNSSEC on the existence of DNS V2, I need to reshape my priorities. Let me know :-}... -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa20833; 10 Aug 94 7:03 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma009961; Wed Aug 10 07:03:33 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Aug 94 16:53:25 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408100753.AA06560@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Bill Manning Date: Wed, 10 Aug 94 16:53:24 JST Cc: tytso@athena.mit.edu, kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <199408091232.AA22981@zephyr.isi.edu>; from "Bill Manning" at Aug 9, 94 5:32 am X-Mailer: ELM [version 2.3 PL11] > > E-K model suggests too much unnecessary changes to the current DNS > > architectture, which is, IMHO, fatal defect of the model. > > > > Thus, based on the same framework supported by WG consensus, I developped > > a simpler model. > > > > Masataka Ohta > > > > I feel I must interject here. There were a large number of > concerns raised in the WG about your top-down approch. This > does not indicate to me that the WG has reached a consensus > based on your design, which is what I read in the statement > above. "the same framework supported by WG consensus" means minimum granularity and zone, not host, based keying. That's all I assumed. I avoided to assume even the public key cryptography. E-K model assumed a lot more than that in a way hostile to the current DNS architecture. Moreover, X-authentication of E-K model is not yet stated precisely and, thus, not yet a proposal. > Also, I do feel that there is a large contigent (including Please don't just "feel" but try to exlain engneering reason. > most of the existing developers and designers) that beleive > that it will take a change in the DNS structure to support > a good security model. And one counter example is enough to disprove it. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa20869; 10 Aug 94 7:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma009968; Wed Aug 10 07:03:51 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Aug 94 16:57:28 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408100757.AA06575@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Wed, 10 Aug 94 16:57:27 JST Cc: tytso@athena.mit.edu, dns-security@tis.com In-Reply-To: <9408092017.AA02040@relay.tis.com>; from "Steve Kent" at Aug 9, 94 4:14 pm X-Mailer: ELM [version 2.3 PL11] > Ted, > > Ohta's proposal has many elements, and I agree with you that a > combination of up, down and cross-certificates (with well-defined > validation rules) is probably going to be more palatable to the WG > overall than a top-down only scheme. I don't think adding combination of up, down and cross-certificates is so difficult nor complex. But as it changes some fundamental assumptions of DNS, I'd like to be conservative and wanted to know the reason to add it. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa22037; 21 Nov 94 2:56 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma015139; Mon Nov 21 02:56:14 1994 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA10228; Sun, 20 Nov 94 23:51:26 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA25638; Mon, 21 Nov 1994 02:55:52 -0500 Message-Id: <9411210755.AA25638@skidrow.tay.dec.com> To: Internet Drafts Cc: dee@skidrow.tay.dec.com, dns-security@tis.com Subject: draft-ietf-dnssec-as-map-01.txt Date: Mon, 21 Nov 94 02:55:51 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I am hereby submitting the following internet draft: --------------------------------------------------------------------------- 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 Mapping A.S. Number into the DNS 19 November 1994 Expires 20 May 1995 Mapping Autonomous Systems Number into the Domain Name System ------- ---------- ------- ------ ---- --- ------ ---- ------ Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnssec-as-map-01.txt, is intended to be become a standards track RFC concerning DNS and routing security. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list [is there also a router [WG?] mailing list is should be sent to?] or to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Abstract One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see other draft-ietf- dnssec-*.txt) to the Domain Name System will enable it to be used for convenient public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Acknowledgements The contributions of the following persons to this draft are gratefully acknowledged: Ran Atkinson, Michale A. Patton Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................4 2. Autonomous System Number Mapping........................5 3. Meaning of RRs..........................................6 4. Security Considerations.................................7 References.................................................7 Author's Address...........................................8 Expiration and File Name...................................8 Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 1. Introduction There are a number of elements that will be required to secure routing in the Internet. One of these is a way that independently operated top level routing domains be able to authenticate messages to each other. Sharing a private symmetric key between each pair of such domains is impractical. The Automonous System numbering scheme provides for 2**16 such domains which implies approximately 2**31 pairs, an impractical number of keys to securely generate, install, and periodically replace. The solution is to use public key technology whereby each domain has a private key it can use to sign messages. Other domains that know the corresponding public key can then authenticate these messages. Such authenticated messages can be used to set up and replace efficient symmetric keys on an as needed basis. But how do the domains securely obtain the Autonomous System number to public key mapping? Extensions currently being developed for the Domain Name System will enable it to be conveniently used for authenticated public key distribution (see other draft-ietf-dnssec-*.txt). All that is required is a mapping of Autonomous System numbers into domain names, which is provided by this draft. It should be noted that the public keys retrieved from DNS will likely be used mostly to authenticate only initial set up messages. Autonomous Systems that need to converse with any frequency will probably negotiate more efficient session keys. Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 2. Autonomous System Number Mapping Autonomous System (A.S.) numbers are 16 bit quantities. The A.S. number is mapped into a domain name as follows: (1) write the A.S. as a four digit hex number (with leading zeros if necessary), (2) reverse these digits and separated them with dots, and (3) append ".in-as.arpa" to them. Thus the domain name correspond to Autonomos System 69, which is 0045 hex, is 5.4.0.0.in-as.arpa. All of *.in-as.arpa could be handled as one zone or parts of it carved out as subzones as administrative convenience dictates. [I choose .arpa as that seems to follow the in-addr model and A.S. numbers originated in the IPv4 world.] Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 3. Meaning of RRs There are no enforceable restrictions on what resource records can be stored under *.in-as.arpa names; however, the following guidance is given for some RR types (the KEY RR is given first, then the rest in alphabetic order). KEY: This type of resource record associates a public key with the Autonomous System (A.S.) designated by its name. Such a public key can be used to authenticate communications with or between A.S.s. The existence of KEY RRs in the reason for mapping A.S. names into the DNS. Under DNS security as proposed in draft-ietf-dnssec- secext-*.txt the KEY RR can be used to store any type of digital key. A: DO NOT place type A RRs at A.S. nodes. A.S. domain names are reserved for Autonomous Systems only and should NEVER be used for a host or any type of end entity other than an Autonomous System. CNAME: This type of RR is an alias pointing to another domain name. An A.S. could have a CNAME pointing to a different A.S. but this is not likely to be very useful as A.S. RRs will normally be looked up when the A.S. number is actually encountered in use. MX: There is no designated use for an MX RR for an A.S. name. It could point to a host that would accept mail related to that A.S. NS: The presence of NS records under an in-as.arpa name means that it has been carved out as a subzone. This gives the A.S. complete control over the zone refresh parameters and control over the creation of inferior names. No special meaning is currently assigned to such inferior names so, although this is not advised, they could be used for hosts or whatever. PTR: The part of the forward domain tree that administratively corresponds to the A.S. should be indicated by a PTR RR. It some entity, say example.net, has several A.S.s, there would be PTRs to example.net from several names in the in-as.arpa hierarchy. RP: A Responsible Person RR should appear under each A.S. name telling you who you should contact in the case of problems with that A.S. TXT: Text RRs can be used for comments, postal address, or similar notes under an A.S. name. Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 4. Security Considerations The entirety of this document concerns a means to map Internet Autonomous System numbers into the Domain Name System (DNS) so that secure DNS can be used to provide secure distribution of Autonomous System's public keys. References [RFC904] - Exterior Gateway Protocol Formal Specification, D. L. Mills [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications, P. Mockapetris Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Author's Address 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 Expiration and File Name This draft expires 20 May 1995 Its file name is draft-ietf-dnssec-as-map-01.txt. Donald E. Eastlake 3rd [Page 8]   Received: from sol.tis.com by magellan.TIS.COM id aa22074; 21 Nov 94 3:00 EST Received: from inet-gw-3.pa.dec.com(16.1.0.33) by relay via smap (V1.3) id sma015178; Mon Nov 21 03:01:00 1994 Received: from skidrow.tay.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA28423; Sun, 20 Nov 94 23:55:20 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA25744; Mon, 21 Nov 1994 02:59:35 -0500 Message-Id: <9411210759.AA25744@skidrow.tay.dec.com> To: Internet Drafts Cc: dns-security@tis.com, dee@skidrow.tay.dec.com, Charlie Kaufman Subject: draft-ietf-dnssec-secext-02.txt Date: Mon, 21 Nov 94 02:59:35 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I am hereby submitting the following internet draft: --------------------------------------------------------------------------- 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 20 November 1994 Expires 19 May 1995 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Donald E. Eastlake 3rd & Charles W. Kaufman Status of This Document This draft, file name draft-ietf-dnssec-secext-02.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, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions Abstract The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described in detail that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. A explanatory overview of the proposed extensions appears in draft- ietf-dnssec-over-*.txt. The extensions also provide for the storage of authenticated keys in the DNS for DNS use and to support a general public key distribution service. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Acknowledgements The significant contributions of the following persons (in alphabetic order) to this draft are gratefully acknowledged: Madelyn Badger, James M. Galvin, Olafur Gudmundsson, Sandy Murphy, Masataka Ohta, Jeffrey I. Schiller. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Brief Overview of the Extensions.......................6 2.1 Key Distribution.......................................6 2.2 Data Origin Authentication.............................6 2.2.1 Security Provided...................................6 2.2.2 The SIG Resource Record..............................7 2.2.3 The NXD Resource Record..............................7 2.2.4 Signers Other Than The Zone..........................8 2.2.5 Special Problems With Time-to-Live...................8 2.3 DNS Transaction Authentication.........................8 3. The KEY Resource Record................................10 3.1 KEY RDATA format......................................10 3.2 Object Types and DNS Names and Keys...................11 3.3 The KEY RR Flag Octet.................................11 3.4 The KEY Algorithm Version.............................12 3.5 KEY RRs in the Construction of Responses..............13 3.6 File Representation of KEY RRs........................13 4. The SIG Resource Record................................15 4.1 SIG RDATA Format......................................15 4.1.1 Signature Format....................................17 4.1.2 SIG RRs Covering Type ANY...........................18 4.1.3 Zone Transfer (AXFR) SIG............................18 4.1.4 Transaction SIGs....................................18 4.2 SIG RRs in the Construction of Responses..............19 4.3 Processing Responses with SIG RRs.....................19 4.4 File Representation of SIG RRs........................20 5. Non-existent Names.....................................22 5.1 The NXD Resource Record...............................22 5.2 NXD RDATA Format......................................23 5.3 Example...............................................23 5.4 Interaction of NXD RRs and Wildcard RRs...............23 5.5 Blocking NXD Pseudo-Zone Transfers....................24 6. How to Resolve Securely................................25 6.1 Boot File Format......................................25 6.2 Chaining Through Zones................................26 6.3 Secure Time...........................................27 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 7. Operational Considerations.............................28 7.1 Key Size Considerations...............................28 7.2 Key Storage...........................................28 7.3 Key Generation........................................29 7.4 Key Lifetimes.........................................29 7.5 Revocation............................................29 7.6 Root..................................................30 8. Conformance............................................31 8.1 Server Conformance....................................31 8.2 Resolver Conformance..................................31 9. Security Considerations................................32 References................................................32 Authors Addresses.........................................33 Expiration and File Name..................................33 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions 1. Introduction This draft provides detailed descriptions of the DNS protocol extensions to support DNS security and public key distribution. A broad overview of these extensions is provided in draft-ietf- dnssec-over-*.txt. This draft assumes that the reader is familiar with that overview and with the Domain Name System particularly as described in RFCs 1034 and 1035. The requirements and goals of DNS security are described in the overview document. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions 2. Brief Overview of the Extensions The DNS protocol extensions provide three distinct services: key distribution as described in section 2.1 below, data origin authentication as described in section 2.2 below, and transaction authentication, described in section 2.3 below. 2.1 Key Distribution The resource records are defined to associate keys with DNS names. This permits the DNS to be used as a general public key distribution mechanism in support of the data origin authentication and transaction authentication DNS services as well as other security services such as IP level security. The syntax of a KEY resource record is described in Section 3. It includes the name of the entity the key is associated with (frequently but not always the KEY RR owner name), an algorithm identifier, flags indicating the type of entity the key is associated with or asserting that there is no key associated with that entity, and the actual public key parameters. 2.2 Data Origin Authentication Adding security requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource types (and, as a practical matter, the key resource type needed for key distribution). An additional domain name non-existence resource is added to extend authentication to negative responses. This service can be supported by existing resolver and server implementations so long as they could support the additional resource types. If signatures are always separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. To avoid this, security aware servers mitigate that degradation by automatically send exactly the signature(s) needed. 2.2.1 Security Provided Security is provided by associating with resource records in the DNS a cryptographically generated digital signature. Commonly, there will be a single private key that signs for an entire zone. If a security aware resolver reliably learns the public key of the zone, Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions 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. 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 server or even all servers for a zone will not affect the degree of assurance that a resolver has that the data is genuine. A resolver can learn the public key of a zone either by reading it from DNS or by having it staticly configured. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus, to provide a 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 if the intervening zones in the DNS tree are secure. 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.2.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 4. It includes the type of the RR(s) being signed, 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), the cryptographic algorithm in use, and the actual signature. Every name in a zone supporting signed data will have associated with it a SIG resource records for each resource type under that name. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will return with all records retrieved the corresponding SIGs. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record(s) that resolver is interested in. 2.2.3 The NXD Resource Record The above security mechanism provides only a way to sign existing RRs in a zone. Data origin authentication is not obviously provided for Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions the non-existence of a domain name in a zone. This gap is filled by the NXD RR which authenticatably asserts a range of non-existent names in a zone. The owner of the NXD RR is the start of such a ranger and its RDATA is the end of the range; however, there are additional complexities due to wildcards. Section 6 below covers the NXD RR. 2.2.4 Signers Other Than The Zone There are two general 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 to authenticate/update its own record. The public key of the entity must be present in the DNS and be appropriately signed but the other RR(s) may be signed with the entity's key. The other is for support of transaction authentication as described in 2.3 below. 2.2.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 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 manipulate the time to live but a security aware resolver will bound the TTL value it uses at the original signed 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. 2.3 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for message headers. If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response is from the query it sent and that these messages have not been Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions diddled in transit. This is accomplished by optionally adding a special SIG resource record to end of the reply which digitally signs the concatenation of the server's response and the resolver's query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be precalculated. Thus it will be necessary to keep the private 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 transaction 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 origin authentication service requires the implementation of essentially all the mechanisms needed for a rudimentary message authentication service. Thus a simple transaction authentication service based on mechanisms already required by DNS security is included as a strictly optional part of these extensions. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions 3. The KEY Resource Record The KEY RR is used to document a key that is associated with a DNS name. It will be a public key as only public keys are stored in the DNS. This can be the public key of a zone owner, of a host or other end entity, or a user. A KEY 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 of the same type associated with a name. The type number for the KEY RR is 25. 3.1 KEY RDATA format The RDATA for a KEY RR consists of an object name, flags, the algorithm version, and the public key itself. For the MD5/RSA algorithm, that is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- object name +---------------+ / | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The object name, and the flags octets are described in Sections 3.2 and 3.3 below. The flags must be examined before any following data as they control its the format and even whether there is any following data. The public key exponent and modulus length fields show apply only if the MD5/RSA algorithm is in use and a key is present. The public key exponent is an unsigned 24 bit integer. The public key modulus field is a multiprecision unsigned integer. The "modulus length" is an unsigned octet which is the actual modulus length minus 64. This limits keys to a maximum of 255+64 or 319 octets and a minimum of 64 octets. Although moduluses of less than 512 significant bits are not recommended, due to the weak security they provide, they can be represented by using leading zeros. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions 3.2 Object Types and DNS Names and Keys The public key in a KEY RR belongs to the object named in the object name field. Frequently this will also be the owner name of the KEY RR. But they will be different in the case of the key or keys stored under a zone's name for the zone's superzone or keys that are stored for cross certification. The DNS object name may refer to up to three things. 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 . Thus, there are flags in the KEY RR to indicate with which of these roles the object name and public key are associated as described below. It is possible to use the same key for these different things with the same name but this is discouraged. In addition, there are three control bits, the "no key" bit, the "experimental" bit, and the "signatory" bit, as described in 3.3 below. 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 IP autonomous system numbers have been mapped into the in-as.arpa domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in the world have been mapped into the tpc.int domain [...]. This is preferable to having the same name possibly be an autonomous system number, telephone number, and/or host as well as a zone and a user. 3.3 The KEY RR Flag Octet In the "flags" field: Bit 0 is the "no key" bit. If this bit is on, there is no key information and the RR stopw with the flags octet. Bits 1 is the "experimental" bit. Keys may be associated with zones or entities for experimental, trial, or optional use, in which case this bit will be one. If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is off 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 off 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 one, the host might very well sometimes operate in a secure mode and at other Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions times operate without the availability of IP-security. The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bit 2 is the "signatory" bit. It indicates that the key can validly sign RRs of the same name. If the owner name is a wildcard, then RRs with any name which is in the wildcard's scope can be signed including NS and corresponding KEY RRs to carve out a subzone. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The signatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bits 3-4 are reserved and must be zero. If they are found non- zero, they should be ignored and the KEY RR used as indicated by the other flags. Bit 5 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 mailbox 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 through an KEY 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. Bit 6 on indicates that this is a key associated with the non- zone entity whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt]. This is the public key used in connection with the optional DNS transaction authentication service that can be used if the owner name is a DNS server host. It could also be used in an IP-security protocol where authentication of a host was desired. Bit 7 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 DNS data origin authentication public key. 3.4 The KEY Algorithm Version This octet is the key algorithm version parallel to the same field for the SIG resource. The MD5/RSA algorithm described in this draft is number 1. Version numbers 2 through 253 are available for assignment should sufficient reason arise. However, the designation of a new version could have a major impact on interoperability Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions requires an IETF standards action. Version 254 is reserved for private use and will never be assigned a specific algorithm. For version 254, the combined "public exponent", "modulus length" and "modulus" area shown above will actually begin with an Object Identifier (OID) indicating the private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. Algorithm versions 0 and 255 are illegal. 3.5 KEY RRs in the Construction of Responses A request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server. Security aware DNS servers will include KEY RRs as additional information in responses where appropriate as follows: On the retrieval of NS RRs, the zone key KEY RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the KEY RR(s) have lower priority than type A glue RRs. On retrieval of type A RRs, the end entity KEY RR(s) for the host named will be included. On inclusion of A RRs as additional information, their KEY RRs will also be included but with lower priority than the relevant A RRs. 3.6 File Representation of KEY RRs KEY RRs may appear as lines in a zone data file. The object name appears first. The flag octet and algorithm version octets are then represented as unsigned integers; however, if the "no key" flag is on in the flags, nothing appears after the flag octet. If the algorithm specified is the MD5/RSA algorithm, then the exponent and modulus appear. The public key exponent is an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 319 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions If an algorithm from 2 through 253 is specified, the public key parameters required by that algorithm are given. If the algorithm specified is number 254, then an OID appears followed by whatever is required for the private algorithm. Algorithm versions 0 and 255 are illegal. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions 4. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure DNS. As such it is the heart of the security provided. The SIG RR unforgably authenticates other RRs of a particular type and binds them to a time interval and the signer's fully qualified domain name. This is done using cryptographic techniques and the signer's private key. The signer is usually the owner of the zone from which the RR originated. 4.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is 24. The "type covered" is the type of the other RRs covered by this SIG. The algorithm version number is an octet specifying the digital signature algorithm used. The MD5/RSA algorithm described in this draft is version one. Version numbers 2 through 253 are available for assignment should sufficient reason arise to allocate them. However, the designation of a new version could have a major impact on the interoperability of the global DNS systems and requires an IETF standards action. Version 254 is reserved for private use and Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions will never be assigned a specific algorithm. For version 254, the "signature" area shown above will actually begin with an Object Identified (OID) indicating the private algorithm in use and the remainder of the signature area is whatever is required by that algorithm. Version numbers 0 and 2555 are illegal. The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If, on retrieval, the RR appears to have a longer name, the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR should be considered corrupt and ignored. The maximum number of labels possible in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. The field helps optimize the determination of the original form. 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. The SIG is valid until the "signature expiration" time which is an unsigned number of seconds since the start of 1 January 1970. The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The "key footprint" is a 16 bit quantity that is used to help efficiently select between multiple keys which may be applicable and as a quick check that a public key about to be used for the computationally expensive effort to decode the signature is possibly valid. Its exact meaning is algorithm dependent. For the MD5/RSA algorithm, it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is usually the zone which contained the RR(s) being authenticated. The structured of the "signature" field depends on the algorithm chosen and is described below. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions 4.1.1 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, flags, and expiration time of the SIG RR to all of the "type covered" RRs with that owner name. These covered RRs are thereby authenticated. To accomplish this, a data sequence is constructed as follows: data = algorithm | original TTL | Expiration Time | Time signed | Signer's Name | RR(s)... where | is concatenation and RR(s) are all the expanded (no name abbreviation) RR(s) of the type covered with the same owner name as the SIG RR in canonical order. 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. How this data sequence is processed into the signature is algorithm dependent. For the MD5/RSA algorithm, the signature is as follows hash = MD5 ( data ) signature = ( 01 | FF* | 00 | hash ) ** e (mod n) where "|" is concatenation, "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 one octet shorter than the value of n. The size of n, including most and least significant bits (which will be 1) SHALL be not less than 512 bits and not more than 2552 bits. 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 similar to Public Key Cryptographic Standard #1 [PKCS1]. (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.) Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions 4.1.2 SIG RRs Covering Type ANY The SIG RR described above protects all the RRs with a particular owner name and type. Thus a server must supply them all to convince a security aware resolver. However, an unscrupulous server could claim there were no RRs of a particular type under an owner name while presenting signed RRs of other types. To provide a means of protection against this, one SIG RR is added for each owner name that covers the type ANY. It is calculated as indicated above except that all RRs for that owner name, except the SIG RR covering type ANY itself, are included in the data string which is processed into the signature. 4.1.3 Zone Transfer (AXFR) SIG The above SIG mechanisms assure the authentication of all the RRs of a particular name and type and all the RRs of a particular name and any type. However, to secure complete zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all other zone signed RRs. 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 4.1.1. 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. Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity or user key rather than a zone key (see Section 3.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. 4.1.4 Transaction SIGs A response message from a security aware server may optionally contain a special SIG as the last item in the additional information section to authenticate the transaction. This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see section 4.1.1) of the entire preceding DNS reply message, including header, concatenated with the entire DNS query message that produced this response, including the query's header. That is data = full response (less trailing message SIG) | full query Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions Verification of the message SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit and that the response corresponds to the intended query. 4.2 SIG RRs in the Construction of Responses Security aware servers MUST, for every RR the query will return, attempt to send the available SIG RRs which authenticate 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. To minimize possible truncation problems, if a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (section 4.1.4). Such SIG RRs are signed by the DNS server originating the response. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. The class and TTL fields can be zero. To save space, the name should be root (a single zero octet). [There may be a problem with SIG and NXD RR's associated with domain names that are CNAMEs. The DNS RFCs prohibit other types of RRs appearing with a CNAME RR. This problem is being ignored until it is clear if DNS servers will really have a problem with this.] 4.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. The result of such decoding should thenbe verified against the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions appropriate other RRs retrieved. If the message does not pass reasonable checks or the SIG does not check against the signed RRs, 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 authenticated TTL. If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the the response and the query that produced the response. It may be optionally checked and the message rejected if the checks fail. But even it the checks succeed, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. If a resolver does not implement transaction SIGs, it MUST at least ignore them without error. If all reasonable checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated and all other RRs in the response should be considered with suspicion. 4.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 transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) There is no particular problem with the signer, covered type, 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 and algorithm fields appears as unsigned integers. The "labels" field does not appear in the file representation as it can be calculated from the owner name. The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be very long. 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions are concatenated to obtain the full signature. These hex substrings can be split between lines using the standard parenthesis. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions 5. Non-existent Names The SIG RR mechanism described in section 4 above provides strong authentication of RRs that exist in a zone. But is it not immediately clear how to authenticatably deny the existence of a name in a zone. The nonexistence of a name in a zone is indicates by the NXD RR for a name interval containing the nonexistent name. An NXD RR and its SIG are returned in the additional information section, along with the error, if the resolver is security aware. NXD RRs can also be returned if an explicit query is made for the NXD type. The existence of a complete set of NXD records in a zone means that any query for any name to a security aware server serving the zone should result in an reply containing at least one signed RR. 5.1 The NXD Resource Record The NXD resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a zone. The owner name of the NXD RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NXD RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. There is a slight problem with the last NXD in a zone as it wants to have an owner name which is the last existing name in sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXD. There are additional complexities due to interaction with wildcards as explained below. The NXD RRs for a zone can be automatically calculated and added to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions the zone by the same recommended off-line process that signs the zone. The NXD RRs TTL should not exceed the zone minimum TTL. The type number for the NXD RR is xxx. 5.2 NXD RDATA Format The RDATA for an NXD RR consists simply of a domain name. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Example Assume a zone has entries for big.foo.bar medium.foo.bar small.foo.bar tiny.foo.bar Then a query to a security aware server for huge.foo.bar would produce an error reply with the additional information section containing big.foo.bar NXD medium.foo.bar 5.4 Interaction of NXD RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NXD record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NXD RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NXD for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NXD is returned as additional information in connection with a query for a non-existent name. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions If there could be any wildcard RRs in a zone and thus wildcard NXDs, care must be taken in interpreting the results of explicit NXD retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs in the internal. The server can just falsely return the wildcard match NXD instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NXD RR whose owner name and RDATA are both the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. It would be possible to make a more complex NXD feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature that could create new names very difficult (see Section 3.2). 5.5 Blocking NXD Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NXD associated with the zone name. Using the RDATA field from that RR, it can query for the next NXD RR. By repeating this, it can walk through all the NXDs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NXD walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals except by trying every name. If it is desired to block NXD walking, the recommended method is to add a zone wide wildcard of the KEY type which asserts the nonexistence of any keys. This will cause there to be only one NXD RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non-existence of names that NXD RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching that wildcard and can thus hide all the real data and delegations with more specific names in the zone. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 6. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS zone structure to the zone of interest. Such trusted public keys would normally be configured in a manner similar to that described in section 6.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. 6.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: zonekey f.q.d.n algorithm [exponent modulus] for a zone public key or hostkey f.q.d.n algorithm [exponent modulus] for a host public key. f.q.d.n is the domain name of the zone or host. Algorithm is the algorithm in use where one is the MD5/RSA algorithm and 254 indicates a private algorithm. The material after the algorithm is algorithm dependent and, for private algorithms, starts with the algorithm's identifying OID. For the RSA algorithm, it is the public key exponent as a decimal number between 3 and 16777215, and the modulus in hex. 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. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions 6.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have a key. 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 one starts below root. A secure sub-zone is generally indicated by a KEY RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. 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. 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 experimentally secure by the presence of an authenticated KEY RR for the non-secure zone with a no key flag or the presence of a KEY RR with the experimental bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. 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. Nevertheless, continuing to apply secure checks within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. The existence of cross certifications adds further policy questions. Assume we have a zone B.A and a zone Y.X. Many possibilities exist for a secure resolver configured with the B.A key to get to Y.X. If all the zones along the way are secure, it could climb to root and then descend the other side, a total of four hops (B.A -> A -> . -> X -> Y.X). If the B.A administrator had installed a cross certified key for Y.X in the B.A zone, using that would be a shorter and presumably more secure way to find Y.X's key which would be immune to the non-security or even compromise of the servers for A or root or X. But what if some less trusted subzone of B.A, say C.B.A installed a cross certified key for Y.X? If there is a conflict, should this be preferred to a hierarhically derived key obtained by climbing to root and descending? Such questions are a matter of local resolver Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions policy. 6.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions. A variety of time synchronization protocols exist including the Network Time Protocol (NTP, RFC1305). If such protocols are used, they should be used securely so that time can not be spoofed. Otherwise, for example, a host could get its clock turned back and might then believe old SIG and KEY RRs which were valid but no longer are. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions 7. Operational Considerations This section discusses a variety of considerations in secure operation of DNS using these proposed protocol extensions. 7.1 Key Size Considerations There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of a key size should be made by the zone administrator depending on their local conditions. For most schemes, larger keys are more secure but slower. Verification (the most common operation) for the MD5/RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the square of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus only increases the verification time by a factor of 4 but vastly increases the work factor of breaking the key. [RSA FAQ] However, larger keys increase size of the KEY RR and usually the SIG RR. This increases the change of UDP packet flow and the possible necessity for using higher overhead TCP. The recommended minimum RSA algorithm modulus size, 640 bits, 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.) 7.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 physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding NXD and SIG RRs. Then the augmented file can be transferred, perhaps by sneaker-net, to the networked zone primary server machine. The idea is to have a one way information flow to the network to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions 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 be off net and should not be updated based on an unsecured network mediated communication. Non-zone private keys, such as host keys, may have to be kept on line to be used for real-time purposes such a IP secure session set-up. 7.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-*.txt. It is strongly recommended that key generation also occur off-line, perhaps on the machine used to sign zones (see Section 7.2). 7.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 zone key should have a lifetime significantly over five years. The recommended maximum 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 maximum lifetime for end entity keys that are used for IP-security or the like and are kept on line is 36 days with the intent that they be replaced monthly or more often. In some cases, an entity key lifetime of a little over a day may be reasonable. 7.5 Revocation [This is new and should probably be moved to someplace above...] Data in the DNS is authenticated via keyed digital signatures. Thus to revoke data, we need to alter the time period of the key's effectiveness to not include the date signed of the data to be remoked. Note that the case of a compromised key, where we wish to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions make its period of effectiveness null, we generally need only think of the KEY RR as data and make the period of effectiveness of the superzone's key not include the time of the previous superzone signing of the key. Normally, a KEY retrieved from the DNS appears to be effective from the beginning of time until the expiration of the SIG that authenticated it. (If this were not so, a secure zone would have to be resigned every time its superzone is resigned.) When data is being revoked, a zone can be resigned with a later date signed but a mechanism is need to make the earlier SIG of the now revoked data not longer valid. A dawn for the effectiveness of a node's KEY RR is provided, when desired, by having the key appear self-signed. This declares the time signed of the self signature as the time of effectiveness of the key(s). Note this is entirely under the control of a zone and asynchronous with its superzone's signings. This technique covers non-zone entities as well. For an owner to have a dawn to the effectiveness of its delegated key (which is signed by the zone key), it need only self-sign its key and the date signed is the dawn. 7.6 Root The root zone includes its own key self-signed. It should also be noted that in DNS the root is a zone unto itself. Thus the root zone key should only be see signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Implementations MAY reject as bogus any purported root signature of records with a name more than one level below root. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions 8. Conformance Several levels of server and resolver conformance are defined. 8.1 Server Conformance Three levels of server conformance are defined as follows: Zilch server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXD RRs. It is believed that most current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG, KEY, and NXD RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXD RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to automatically include SIG, KEY, and NXD RRs in responses as appropriate, as well as meeting minimal compliance. 8.2 Resolver Conformance Two levels of resolver compliance are defined: A Zilch compliance resolver can handle SIG, KEY, and NXD RRs when they are explicitly requested. It is believed that current resolvers are Zilch compliant. A fully compliant resolver understands KEY, SIG, and NXD RRs, maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, and performs additional queries as necessary to obtain KEY, SIG, or NXD RRs from non-security aware servers. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions 9. Security Considerations This document concerns technical details of extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction security. If should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host; however, this does not stop someone for substituting an unauthorized host at that address or capturing packets sent to that address and responding with packets apparently from that address. Any reasonably complete security system will require the protection of many other facets of the Internet. 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 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] 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 Iris Associates Telephone: +1 508-392-5276 EMail: charlie_kaufman@iris.com Expiration and File Name This draft expires 19 May 1995. Its file name is draft-ietf-dnssec-secext-02.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33]   Received: from sol.tis.com by magellan.TIS.COM id aa22410; 21 Nov 94 4:51 EST Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3) id sma015843; Mon Nov 21 04:52:21 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA12595; Mon, 21 Nov 1994 10:50:06 +0100 Message-Id: <199411210950.AA12595@mitsou.inria.fr> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Subject: Re: draft-ietf-dnssec-as-map-01.txt In-Reply-To: Your message of "Mon, 21 Nov 1994 02:55:51 EST." <9411210755.AA25638@skidrow.tay.dec.com> Date: Mon, 21 Nov 1994 10:50:06 +0100 From: Christian Huitema Donald, Did you consider the mapping of autonomous system numbers in the IPv4 address space already used by SDRP? They needed to specify source routes "through an AS", so they represent the AS cloud by the IP address "128.0.x.y", where the last two bytes encode an Autonomous System number. This usage would translate in a prefix of "0.128.in-addr.arpa". Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa25278; 21 Nov 94 9:51 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma019080; Mon Nov 21 09:51:30 1994 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA05411; Mon, 21 Nov 94 06:44:03 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA05679; Mon, 21 Nov 1994 09:48:30 -0500 Message-Id: <9411211448.AA05679@skidrow.tay.dec.com> To: Christian Huitema Cc: "Donald E. Eastlake 3rd (Beast)" , dns-security@tis.com Subject: Re: draft-ietf-dnssec-as-map-01.txt In-Reply-To: Your message of "Mon, 21 Nov 94 10:50:06 +0100." <199411210950.AA12595@mitsou.inria.fr> Date: Mon, 21 Nov 94 09:48:30 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Christian, No, I hadn't considered that. If there is already a convenient encoding of AS numbers into DNS and no conflicts on the use of RRs at that name, then there is no particular reason to invent a new mapping... Donald From: Christian Huitema To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com In-Reply-To: Your message of "Mon, 21 Nov 1994 02:55:51 EST." <9411210755.AA25638@skidrow.tay.dec.com> >Donald, > >Did you consider the mapping of autonomous system numbers in the IPv4 address >space already used by SDRP? They needed to specify source routes "through an >AS", so they represent the AS cloud by the IP address "128.0.x.y", where the >last two bytes encode an Autonomous System number. This usage would translate >in a prefix of "0.128.in-addr.arpa". > >Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa06259; 22 Nov 94 20:08 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3) id sma015155; Tue Nov 22 20:10:17 1994 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09404; 22 Nov 94 14:50 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-02.txt Date: Tue, 22 Nov 94 14:50:36 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9411221450.aa09404@IETF.CNRI.Reston.VA.US> --NextPart A Revised 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-02.txt Pages : 33 Date : 11/21/1994 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described in detail that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. A explanatory overview of the proposed extensions appears in draft-ietf-dnssec-over-*.txt. The extensions also provide for the storage of authenticated keys in the DNS for DNS use and to support a general public key distribution service. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19941121132011.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941121132011.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from sol.tis.com by magellan.TIS.COM id aa17910; 26 Nov 94 22:34 EST Received: from unknown(131.112.32.132) by relay via smap (V1.3) id sma018001; Sat Nov 26 22:35:31 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 27 Nov 94 12:26:54 +0859 From: Masataka Ohta Return-Path: Message-Id: <9411270327.AA06407@necom830.cc.titech.ac.jp> Subject: revised draft-ohta-simple-dns To: dns-security@tis.com Date: Sun, 27 Nov 94 12:26:53 JST Cc: dns-security@tis.com X-Mailer: ELM [version 2.3 PL11] Dear DNSSEC members; I have just posted the following revised internet draft. It's a little more simplified and a lot more compatible with the existing DNS than the previous version. Optional cross authentication scheme is also added. Masataka Ohta ------------------------------------------------------------------------ INTERNET DRAFT M. Ohta draft-ohta-simple-dns-01.txt Tokyo Institute of Technology November 1994 Simple Secure DNS Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, 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. Abstract An extension to DNS is proposed to make answers from it authenticated. The extension is designed to be minimal, which will be useful as a framework to make applications provide required level of authentication and/or confidentiality. The changes to the existing architecture of DNS is also minimized. 1. Introduction The purpose of the secure DNS protocol extension is to make data from DNS authenticated. In general, security has two aspects, authentication to make data unforgable and confidentiality to make data secret. As the fundamental role of DNS is to make its database available all around the world, no confidentiality is considered in this document. IQUERY, an optional feature of DNS, is inherently insecure, and not considered in this document. This document is written with the assumption that readers thoroughly understand the existing DNS described in RFC 1034 and RFC 1035. On the other hand, little knowledge on cryptography is assumed. M. Ohta Expires on June 1, 1995 [Page 1] INTERNET DRAFT Simple Secure DNS November 1994 To make DNS secure, two cryptographic mechanisms: digesting and signature, are combined. Digesting is the mechanism to compute a short digest of a byte stream. The mechanism should be complex enough so that, given a digest value of some byte stream, it should be practically impossible to forge a different byte stream which has the same digest value. The other is the mechanism to give signature to a byte stream with some secret information. The mechanism should be complex enough so that, given a signature value of some data and the original data itself, it should be practically impossible to guess the secret information. The signature can be verified by sharing secret information between related parties or by using private/public key technology. This document does not specify the actual mechanisms to generate digests and signatures. As long as the above two basic authentication mechanisms are reliable, secure DNS is designed to be reliable against all forms of attacks save the denial of service attacks of the most basic form, which is least harmful. That is, the secure DNS may report a temporal failure against some form of denial of service attacks. But all the answers other than the temporal failure is reliable to the extent that the basic authentication mechanisms up to the root or other locally reliable zones are reliable. For example, if a resolver can communicate with no name servers because of some attack such as unplugging of cables, the only thing the resolver can do is to report the temporal failure, which is one of the most basic form of a denial of service attack. On the other hand, secure DNS can securely report negative answers that a node does not exists or that an RR type does not exist for a given node. Authentication is provided zone wise. A secure zone is a zone whose authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. For the maximum security, both the secret information and the signature generation mechanism of a zone should be kept off-line. In this case, even if on-line name servers of the zone is compromised, security on the DNS information of the zone is not compromised. In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. M. Ohta Expires on June 1, 1995 [Page 2] INTERNET DRAFT Simple Secure DNS November 1994 Though the secure DNS can be an authenticated source of information to establish secure communication between hosts, such as distribution of host's public keys, it is out of the scope of this document and a separate document should be provided. A security aware name server is a name server which supports queries for the new RR types in this document with required additional section processing. For more protection against some denial service type attack, additional authentication mechanism may be supported for secure zone transfer. A security aware recursive resolver is a resolver which can perform authenticated retrieval of DNS data in secure zones. From several seed zones, DNS tree is recursively traversed with authentication to get the final authenticated answer. A security aware recursive resolver is configured with static information to confirm that data from name servers of some seed zones are actually secure. A security aware stub resolver is a resolver which can perform authenticated communication with a recursive resolver. A stub resolver may be configured with static information to authenticate communication between recursive resolvers. The recursive and stub resolvers may be colocated on the same host and communicate securely though some operating system mechanism, for example, UNIX domain sockets, or they may be located on different hosts. So, how the recursive and stub resolvers securely communicate is out of scope of this document. But, it is suggested that a security aware stub resolver communicate with a security aware recursive resolver colocated with name server through normal DNS query through secure IP [SECIP] protocol. In this case, secure IP can not use DNS to establish security relationship so that some static configuration is necessary. The protocol in this document is carefully designed so that existing name servers can cooperate with security aware resolvers and name servers. 2. Changes to the Previous Version and to the Existing Mechanism A lot of simplification is performed to the previous version of the draft: "draft-ohta-simple-dns-00.txt. First, protocol in this document, now, introduces no important changes to the existing DNS architecture. That is: No new OPCODE, NCQUERY, is added. Some query types for authentication matches its own RR type and CNAME. The M. Ohta Expires on June 1, 1995 [Page 3] INTERNET DRAFT Simple Secure DNS November 1994 impossibility of the current DNS to have CNAME only zone is left untouched. SD (Security Desired) bit is not added. As the desire needs to be expressed only for the secure communication between recursive and stub resolvers, it's out of the scope of this document. If secure IP protocol is used for the communication the fact that the secure IP protocol is used itself shows that the security is desired. SA (Security Assured) bit is not added. Instead, if secure communication channel to stub resolvers is used, secure recursive resolver must assure RRs that the answer section contains authenticated data only. Meaning of MINTTL field of SOA RRs is untouched, though it is widely known that using it as negative caching period is inappropriate. Cases of domain names are not canonicalized. They are canonicalized only when digest value is computed. To NSIG RR, field is added. Optional resolver operation mode for cross authentication is added. 3. New Data Types New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG and ZL are added to secure zones. Actual RR type names or values for the data and their syntax may vary according to specific authentication algorithm. Detailed explanation, including the actual RR type values for new data types, are not given in this document. Square bracketed notation "[RR]" is used to designate a instance of a new data type "RR". In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. Binary format of each RRs are arranged with the byte sex of bigendean in the same order as the textual format. When RR types are used as query type, RRD and NSIG query matches a CNAME record too. M. Ohta Expires on June 1, 1995 [Page 4] INTERNET DRAFT Simple Secure DNS November 1994 RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet with the following canonicalization: No domain name compression is performed. Upper case letters in domain names are converted to the corresponding lower case letters. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. For example, four strings "AB", "AC", "BA" and "ABC" are sorted as ["AB", "ABC", "AC", "BA"]. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with the (original TTL) field of the RRD record. When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] records for each RR type the node has. But, it is impossible and unnecessary to cover s of RRD, NSIG and ZSIG with digest. Still, it is necessary to have RRD of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. M. Ohta Expires on June 1, 1995 [Page 5] INTERNET DRAFT Simple Secure DNS November 1994 NSIG (Node SIGnature) Signature on RRD computed using secret information of the zone, added to secure nodes. [NSIG] RRs have the following syntax: [NSIG] where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or KERBEROS), is a domain name of a zone who signs [ZA] and is the time when the signature is computed. is the number of seconds the signature will be valid after . and are 32 bit quantities. is of variable length. Throughout the document, time is a 32 bit quantity, unless otherwise specified. Absolute time is counted by the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and wraps around after 2^32 seconds (about 136 years). As the 32 bit time value circulates, zone's secret information should be changed at least once per 50 years. Otherwise, stale data signed 136 years ago may be distributed with a valid signature. When computing ; , and of [RRD] are serialized with the byte order used in DNS packets and the resulting byte stream is signed by the zone's signature mechanism(s). No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. ZA (Zone Authenticator) Data added to a secure zone to specify how to verify NSIGs of nodes within the zone. [ZA] RRs have the following syntax: M. Ohta Expires on June 1, 1995 [Page 6] INTERNET DRAFT Simple Secure DNS November 1994 [ZA] where [ZA] is the RR name of ZA, is the time from when the is used. is 32 bit absolute time. is of variable length. The actual content of varies by the authentication algorithm. It may be a public key of the zone or IP addresses of authentication centers of the zone which maintains secret information of related parties. field is useful to smoothly change zone's secret information. Usually, a zone has only one record of [ZA] type. But, a zone may have two such records when zone's secret information is being changed. Otherwise, authentication of RRs signed before the change fails with a new . If multiple [ZA]s exist during the transition, field of NSIG is compared to the fields in [ZA]s to select the RR actually used for the signature. Older RR should disappear after all the signature signed with it is assured to have expired. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . , and are the same as that of [NSIG] except that the signature covers the sequence of , where is the field of [RRD] of [ZA] of a signed zone. In general, only a who is a parent or an ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s according to their local security policy. If multiple ZSIG RRs of different [ZSIG] values exist, the most preferable one is chosen by the resolver's local security policy. For the root zone or M. Ohta Expires on June 1, 1995 [Page 7] INTERNET DRAFT Simple Secure DNS November 1994 locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". ZL will have the following syntax. [ZL] ... where [ZL] is the RR name of ZL data, is the number of seconds appropriate for negative caching, is the number of domains covered by the record. The record contains all the domain names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) and before sorted with dictionary order. Cases of characters in , ... must be canonicalized to lower cases. and is merely a separator and should not be interpreted that such a node exists unless explicitly listed as . Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last, which makes domain name compression work quite well. Within labels, comparison are by dictionary oder, that is, first bytes are compared first. For example, "a.b.c.", "a.c.b.", "a.c.", "ab.c.", "ac.b." and "c." are ordered as "ac.b.", "a.c.b.", "c.", "a.c.", "ab.c." and "a.b.c.". M. Ohta Expires on June 1, 1995 [Page 8] INTERNET DRAFT Simple Secure DNS November 1994 Thus, the name of the zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as , it is considered to be ordered after all the other names in the domain. For example, [ZL] 0 represents a zone consisting of only a single node. and are two byte integers. , , , ..., have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). , and are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of ... contained in the [ZL] record itself. 4. Name Server Operation Changes to the operation of name servers is minimal. A primary name server of a zone has access to signature mechanisms of the zone and derives authenticated data from them. A secondary name server is configured with IP addresses of other name servers from which zone information is transferred. Secure zone transfer, protected by zone's key, may be used to detect that the primary server compromised and continue operation with older but secure data. The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the following description: The actual algorithm used by the secure name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to M. Ohta Expires on June 1, 1995 [Page 9] INTERNET DRAFT Simple Secure DNS November 1994 provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node contains a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put authenticated addresses available from authoritative data or the cache. If they are unavailable, use glue RRs, if they exists. Go to step 4. c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the M. Ohta Expires on June 1, 1995 [Page 10] INTERNET DRAFT Simple Secure DNS November 1994 answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label unless the query type is of RRD. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Go to step 6. 4. Start matching down in the cache. If QNAME is found in the cache, copy all the RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data at 3.b, look for the best one from the cache, and put it in the authority section. Go to step 6. 5. Using the local resolver or a copy of its algorithm (see resolver section of this document) answer the query. Store the results, including any intermediate CNAMEs, in the answer section of the response. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. For secure zone transfer, new query types [SXFR] are added. The actual name and value of [SXFR] depends on the authentication mechanism used. It is assumed that each secondary server is statically configured with digest of ZA of a zone it serves. The TCP transport of a secure zone transfer meessage has the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone message | |s | | |t | | |e +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the M. Ohta Expires on June 1, 1995 [Page 11] INTERNET DRAFT Simple Secure DNS November 1994 signature of the transferred zone. Unlike AXFER, [SXFR] uses four bytes for zone data length to transfer large zones such as "com.". 5. Resolver 5.1 Client-Resolver Interface Client programs tells security requirements to the resolver. The requirement includes whether they need security or not and which digesting or signature mechanism they consider reliable. 5.2. Data Structures The resolver algorithm in the next subsection assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: SNAME the domain name we are searching for. STYPE the QTYPE of the search request. SCLASS the QCLASS of the search request. SLIST a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, [ZA] and [ZSIG] of the zone if the zone is secure, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. SBELT a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The configuration file also contains information of ZA RRs the SBELT servers serves. The match count will be -1 to indicate that M. Ohta Expires on June 1, 1995 [Page 12] INTERNET DRAFT Simple Secure DNS November 1994 no labels are known to match. CACHE A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. TTL for secure data should be shortened not to exceed its authenticated period. Data in the cache also contains a bit telling whether the resolver think the data is secure or not. In the CACHE, authenticated RR has precedence over unauthenticated RR. During authentication, data should be stored in the cache as unauthenticated. Later, if the data is proven to be secure, the bit is flagged. If the data is proven to be insecure, the data is flushed. 5.3 Resolver Algorithm Stub resolvers believes anything recursive resolvers returns through secure communication channel. For recursive resolvers, the four step algorithm in the section "5.3.3. Algorithm" of RFC 1034 must be replaced with the following: The top level algorithm has four steps: 1. See if the answer is in local secure information, and if so return it to the client. 2. Find the best servers to ask. 3. Send them queries until one returns a response. 4. Analyze the response, either: a. if the response answers the question or contains a name error, try to authenticate it, cache the data and other authentication information as well as returning the answer back to the client. b. if the response contains a better delegation to other servers, try to retrieve and authenticate ZSIG and ZA M. Ohta Expires on June 1, 1995 [Page 13] INTERNET DRAFT Simple Secure DNS November 1994 of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. c. if the response shows a CNAME and that is not the answer itself, try to authenticate the CNAME, cache the CNAME and other authentication information, change the SNAME to the canonical name in the CNAME RR and go to step 1. d. if the response shows a servers failure, an authentication failure or other bizarre contents, delete the server from the SLIST and go back to step 3. Authentication by resolvers are done as follows: 1. if the answer is in the authoritative data of a secure zone of a name server co-located with the resolver, no further authentication is necessary. 2. To authenticate RRD of ZA, use ZSIG and authenticated ZA of zone. 3. To authenticate ZA, use RRD of ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate RRD, use NSIG and authenticated ZA. 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. 7. if the response is a name error, that is, a node which matches query does not exist, confirm it by authenticating ZL data in the additional section of the response. For example, to authenticate that data matching "a.b.c.d." dose not exist in a zone "c.d.", it should be confirmed that nodes "a.b.c.d." and "*.b.c.d" do not exist but "b.c.d." does exist. Depending on the zone's structure (whether "b.c.d." exists or not), the same thing may be confirmed by the fact that nodes "a.b.c.d.", "*.b.c.d", "b.c.d" and M. Ohta Expires on June 1, 1995 [Page 14] INTERNET DRAFT Simple Secure DNS November 1994 "*.c.d" do not exist. 8. if the response is a data not found error, that is, the query does not match any RR type of the node, retrieve all the authenticated RRD type records of the node and confirm that they don't contain RR types which matches the query. Authentication chains between zones have the following structure: digest ZA of well known signer zone------>digest value statically | configured in name | servers | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<----------RRD of ZA Figure 1. Authentication Chains of Zone Data Authentication chains within a zone have the following structure: ZA of the Node's Zone | | | signature NSIG<---------RRD of RR type RRD ^ |digest | RRD of RR type ^ |digest | RR with RR type M. Ohta Expires on June 1, 1995 [Page 15] INTERNET DRAFT Simple Secure DNS November 1994 other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5.4 Resolver Algorithm for Cross Authentication (Optional) Usually, recursive resolver traverses DNS tree in top down manner from the nearest ancestor (often, the root node) of the sought node down toward the leaf direction. The selection corresponds to the step 2. 2. Find the best server to ask. of the top level resolver algorithm in section 5.3. By introducing a new RR type: XSIG, it is possible to find the best server in a bottom up manner. XSIG has the following format: XSIG <[ZA]> where, is the variable length digest of <[ZA]> RR of zone. The value of XSIG is . Usually, is an ancestor of . Then, if a resolver is configured with static authentication information of , the resolver can reliably know the [ZA] information of zone. If zone also has XSIG, authentication may be chained up to the root zone. During the up sequence of authentication, XSIG may, only once, traverse the DNS tree, after which only the down sequence through NSIG (as described in step 4.b in section 5.3) is allowed. The algorithm to find the best server with terminology of the section 5.2 is as follows: 1. Start from a zone served by SBELT name servers. 2. If the zone has XSIG record with of the ancestor of the SNAME, the search has finished. 3. If the zone has XSIG record with of the ancestor of the zone itself, up the zone hierarchy and recursively continue the search at step 2. 4. If none of the conditions are met, try the next zone in the M. Ohta Expires on June 1, 1995 [Page 16] INTERNET DRAFT Simple Secure DNS November 1994 SBELT. If no zones are remaining, the search has failed. The use of the cross authentication scheme introduce some vulnerability but removes some, discussion on which is quite complex. There are also complex performance trade-offs. For example, even if an ancestor zone of SNAME is found in cache, the above steps must always be performed to find the nearest ancestor of SNAME, which is necessary for the security property of the cross authentication scheme. So, in this document, it's use is completely optional. 6. Secure Time and Secure DNS DNS is designed to be highly fault tolerant. That is, if a secondary server can't communicate with other servers, the secondary server can behave as authoritative until SOA period is reached. Thus, until a resolver securely knows that period has passed, a name server may give old but authenticated answer to a query whose node does not exist. Thus, period should be minimized. Moreover, clocks of signers and resolvers should be accurate enough. It is recommended that signers clock should have maximum allowable error of /20. When resolvers caching information, it should be confirmed that cached period is shorter than and *19/20 fractions rounded down minus the expected maximum error of the resolvers' clocks. Due to clock skew, a resolver may receive a dated in the future. The data should be relied if the error is below /10 fractions rounded down plus the expected maximum error of the resolver's clocks. To have an Internet wide upper bound on the life time of stale data, longer than a week should be shortened to a week. 7. Secure DNS and Additional Section Processing To authenticate DNS reply on a certain node, a lot of information about the node is necessary. Such information may be provided in the additional section. On the other hand, though the existing DNS suggests to add various information in the additional section, data on nodes which is not queried needs, such as additional As for MX, are not so useful if they can't be authenticated. Thus, for secure DNS, it is recommended to add additional information with the following preference as long as the addition won't make the M. Ohta Expires on June 1, 1995 [Page 17] INTERNET DRAFT Simple Secure DNS November 1994 reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. additional information on the queried node. other additional information. 8. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X form a single set of specification. Even if two specifications share the same digesting or signature mechanism, they have different [RRD] or [NSIG] values. 9. References [RFC1034] [RFC1035] [SECIP] Security Considerations The entire document is devoted on a security issue to make answers from DNS authenticated over unreliable transport mechanisms. No confidentiality is considered. Author's Address Masataka Ohta Computer Center Tokyo Institute of Technology M. Ohta Expires on June 1, 1995 [Page 18] INTERNET DRAFT Simple Secure DNS November 1994 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.cc.titech.ac.jp M. Ohta Expires on June 1, 1995 [Page 19]