Received: from relay.tis.com by neptune.TIS.COM id aa12025; 12 Feb 96 11:17 EST Received: by relay.tis.com; id LAA22841; Mon, 12 Feb 1996 11:19:20 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022827; Mon, 12 Feb 96 11:18:52 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28432; Mon, 12 Feb 96 11:17:56 EST Received: by relay.tis.com; id LAA22824; Mon, 12 Feb 1996 11:18:50 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma022809; Mon, 12 Feb 96 11:18:30 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14760; 12 Feb 96 9:49 EST To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: The IESG Subject: Last Call: Domain Name System Security Extensions to Proposed Standard Date: Mon, 12 Feb 96 09:49:39 -0500 Message-Id: <9602120949.aa14760@IETF.CNRI.Reston.VA.US> Sender: dns-security-request@neptune.tis.com Precedence: bulk The IESG has received a request from the Domain Name System Security Working Group to consider the following two Internet-Drafts for the status of Proposed Standards: 1. Domain Name System Security Extensions 2. Mapping Automous Systems Number into the Domain Name System The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by February 26, 1996. Received: from relay.tis.com by neptune.TIS.COM id aa24677; 13 Feb 96 1:04 EST Received: by relay.tis.com; id BAA04924; Tue, 13 Feb 1996 01:06:21 -0500 From: bmanning@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004922; Tue, 13 Feb 96 01:05:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05241; Tue, 13 Feb 96 01:04:57 EST Received: by relay.tis.com; id BAA04917; Tue, 13 Feb 1996 01:05:52 -0500 Received: from venera.isi.edu(128.9.0.32) by relay.tis.com via smap (V3.1) id xma004913; Tue, 13 Feb 96 01:05:47 -0500 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Feb 1996 22:06:53 -0800 Posted-Date: Mon, 12 Feb 1996 22:02:23 -0800 (PST) Message-Id: <199602130602.AA27964@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 12 Feb 1996 22:02:23 -0800 Subject: Re: Last Call: Domain Name System Security Extensions to Proposed To: The IESG Date: Mon, 12 Feb 1996 22:02:23 -0800 (PST) Cc: IETF-Announce: @CNRI.Reston.VA.US:;, CNRI.Reston.VA.US@TIS.COM, dns-security@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM In-Reply-To: <9602120949.aa14760@IETF.CNRI.Reston.VA.US> from "The IESG" at Feb 12, 96 09:49:39 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 177 Sender: dns-security-request@neptune.tis.com Precedence: bulk > > 2. Mapping Automous Systems Number into the Domain Name System > I think it is about time for this draft to be advanced. -- --bill Received: from relay.tis.com by neptune.TIS.COM id aa01705; 14 Feb 96 12:09 EST Received: by relay.tis.com; id MAA01258; Wed, 14 Feb 1996 12:11:23 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001250; Wed, 14 Feb 96 12:10:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26347; Wed, 14 Feb 96 12:09:58 EST Received: by relay.tis.com; id MAA01242; Wed, 14 Feb 1996 12:10:53 -0500 Received: from bart.bbn.com(128.89.1.226) by relay.tis.com via smap (V3.1) id xma001237; Wed, 14 Feb 96 12:10:30 -0500 Received: from GAAK.BBN.COM by BART.BBN.COM id aa29086; 14 Feb 96 12:08 EST Date: Wed, 14 Feb 1996 12:06:29 EST Message-Id: To: Namedroppers@internic.net Cc: DNS-security@TIS.COM Subject: Expires RR proposal From: "Michael A. Patton" Sender: dns-security-request@neptune.tis.com Precedence: bulk At the last IETF there was some discussion about an RR to achieve the expiration features of the DNSSEC draft, but without the appearance of any security (or the requirement for the security overhead). Many people put forward good reasons for having this as a separate thing. I've put together a draft of a spec for this (extremely drafty :-). It's attached to this message, and I'd appreciate any feedback (both of the open questions in the document, and discussion on the list as to whether this is the right approach). In the document, meta comments are set off with [[[triple brackets]]] to isolate them from the main text. If people think it would be useful, we should consider some discussion (at the end of :-) the DNSIND meeting in LA (what's the deadline for submission? I think Friday, so get those comments in quick :-). -MAP ---------------------------------------------------------------- INTERNET DRAFT M. A. Patton Expiration Date: April 1996 BBN December 1995 Scheduled Expiration of DNS Resource Records 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``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 (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires April 1996. [[[Global issues for entire draft: Draft as written expires all RRs of a type together. This seems to be reasonable given some other discussions, but may be controversial. Since my inclination was towards treating a whole RR set the same already and I couldn't figure out a good way to be more fine-grained, I felt it was useful to do it this way, at least to start. For all these reasons, I will leave it as is, unless someone comes up with a compelling reason for it, AND a good design for how to do it. Do we need to expire CNAMES? Can't put an EXP there...unless we make EXP an exception to that rule. I think the DNSsec does this for SIGs...just extend that exemption? Should the SOA serial be updated when records expire? I think the same words that are in the DynDNS draft should be put here... Problem is that this can happen in both primary and secondary servers. Interaction with Dynamic Update. Do expired RRs appear to be there or not for the conditioning section of an update. May want them to appear to be there for several reasons 1) they need to be deleted for real (maybe); 2) may be trying to replace just around time of expire and not having them is a race condition; and 3) may have been used in conditioning because a recent query showed it there. On the other hand, these may want to be really gone once expired, because they're no longer visible to queries and therefore updates may assume they don't exist and say that in the conditional part... Should anything be said about expiring EXP RRs? This draft lets you do it, which can result in odd behaviour. On the other hand, I don't see why outlawing it is really needed (maybe someone will come up with a good use for this "feature"). ]]] Abstract This document describes an additional RR type for the Domain Name System[7,8] which provides for scheduled expiration of RRs in the DNS. These RRs record the time at which a referenced set of RRs are to be removed from the DNS. This can be used to provide the information required to automatically support the reduced TTLs described in RFC1034[8] when anticipating a change, and by being in the zone data, will communicate that information to other servers that recognize the RR, in particular, secondary servers that recieve the data by Zone Transfer (AXFR or IXFR[2]). Introduction [[[TBD]]] [[[Ref discussion in DNSIND and DNSSEC]]] 1. definition of the RR type The Expires RR is defined with mnemonic "EXP" and TYPE code [[[TBD]]] (decimal). The format is based slightly on the format used for the SIG RR in the DNS Security Extensions[1] The format of an Expires (EXP) RR is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = EXP | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | COVERS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TIME | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: * NAME: an owner name, i.e., the name of the DNS node to which this resource record pertains. * TYPE: two octets containing the EXP RR TYPE code of 31 (decimal). * CLASS: two octets containing the RR IN CLASS code of 1. * TTL: a 32 bit signed integer that specifies the time interval in seconds that the resource record may be cached before the source of the information should again be consulted. * RDLENGTH: 6 * COVERS: is the type code of the RR set that it covers or 255 to indicate that it applies to all RRs of the same name and class. This is a subset of the QTYPE defined in RFC1035. * TIME: The date and time that the referenced RRs are due to expire, represented as an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. [[[It's been suggested to add an "Effective on" time or function. If that's desired by anyone, my temptation is to make it separate. For this to be useful, it (and EXP) would really need to apply to specific RRs rather than a whole RR set. This makes it hard. For all these reasons, I will leave it out, unless someone comes up with a compelling reason for it, AND a good design for how to do it. My inclination is that this should be done with something like adding an EXP, then at the "effective time" doing a DYNDNS update removing the EXP and the RRs it covers and adding the new ones. This probably requires that the expired RRs appear to be there whether they've expired or not for the purposes of update, but they may not be visible to queries, can we make this reasonable.]]] 2. Master File Format The format of EXP RRs follows all the rules of RFC 1035, Section 5, "Master Files." Example master file (based on the example in RFC1035): @ IN SOA VENERA Action.domains ( 20 ; SERIAL 7200 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS A.ISI.EDU. NS VENERA NS VAXA MX 10 VENERA MX 20 VAXA ; address record for host A is good until 8am, 1 Jan 1996 A A 26.3.0.103 EXP A 19960101080000 VENERA A 10.1.0.52 A 128.9.0.32 ; all address records for host VENERA are good until midnight, 31 May 1996 EXP A 19960531000000 ; no expiration for VAXA's addresses VAXA A 10.2.0.27 A 128.9.0.33 3. Handling of Expires RRs and RRS covered by them When an authoritative server [[[is this limitation good? bad? other?]]] returns any RR covered by an Expires RR, it must assure that the TTL is small enough that copies will not be cached beyond the given expiration time. Although the server does not need to actually remove expired RRs from its database, it must give the appearance of having done so when formulating replies to query or transfer requests. A simple algorithm for skipping over expired RRs or adjusting their TTL to match an expiration time is shown below: if expire > now { if (expire - now) > TTL { TTL = (expire - now) } include RR in reply } This algorithm makes the TTL just small enough to satisfy the EXP requirements. Some people have suggested more elaborate techniques to reduce the inherent inconsistencies introduced. Such an algorithm might be to use a two day TTL when the change is more than a week away, but a week ahead, start lowering the TTL such that 3 days before the change only 1 day TTLs are given out, and a day in advance it's down to a few hours, and a few hours in advance it's down to 30 minutes. The usefulness of this more gradual approach has been debated [[[do I have any references on this discussion???]]], but in any case it is a local matter as long as the TTL does not exceed that given by the simple algorithm above. 4. Additional Section Processing [[[Do we need this?]]] [[[Maybe suggest including them when they apply? Probably not useful.]]] 5. Acknowledgements The original arguments for this as a separate RR were put forward by Robert Elz in the DNSIND Working Group. Many others described uses and requirements that were the basis of this design. Comments and some explanatory text from Walt Lazear were helpful. I'd also like to thank Arnt Gulbrandsen for his collected list of DNS RFCs and permission to use it as the basis for the References section and Bill Manning, the author of RFC1348[4], for unwittingly supplying the boilerplate and diagrams I used as a basis for this document. Much of the layout of the RR was based on the work of Donald Eastlake and Charles Kaufman in the design of the DNS Security Extensions. 6. Security Considerations Security issues are not [[[yet]]] discussed in this memo. [[[Should any be???]]] [[[ EXP allows add permission to be turned into delete permission]]] [[[ interaction with DNSSEC, which has a different variant of expiration, and with secure update[TBD]. ]]] 7. References [1] DNSsec draft [[[fill in details]]] [2] IXFR draft [[[fill in details]]] [3] RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller, "Common DNS Implementation Errors and Suggested Fixes.", 10/06/1993. [4] RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992. [5] RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart, "New DNS RR Definitions", 10/08/1990. [6] RFC 1101: P. Mockapetris, "DNS encoding of network names and other types", 04/01/1989. [7] RFC 1035: P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. [8] RFC 1034: P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. [9] RFC 1033: M. Lottor, "Domain administrators operations guide", 11/01/1987. [10] RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987. [11] RFC 974: C. Partridge, "Mail routing and the domain system", 01/01/1986. 8. Authors' Address: Michael A. Patton Bolt Beranek and Newman 10 Moulton Street Cambridge, MA, 02138 Phone: (617) 873 2737 FAX: (617) 873 3457 Email: map@bbn.com This Internet Draft expires April 1996 Received: from relay.tis.com by neptune.TIS.COM id aa03656; 14 Feb 96 13:57 EST Received: by relay.tis.com; id NAA03705; Wed, 14 Feb 1996 13:59:07 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003697; Wed, 14 Feb 96 13:58:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02107; Wed, 14 Feb 96 13:57:42 EST Received: by relay.tis.com; id NAA03693; Wed, 14 Feb 1996 13:58:37 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma003685; Wed, 14 Feb 96 13:58:22 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7207; Wed, 14 Feb 96 13:59:14 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 3514; Wed, 14 Feb 1996 13:59:14 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Wed, 14 Feb 96 13:59:14 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA20309; Wed, 14 Feb 1996 14:00:11 -0500 Message-Id: <9602141900.AA20309@edisto.watson.ibm.com> X-External-Networks: yes To: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Wed, 14 Feb 96 12:06:29 EST. Date: Wed, 14 Feb 96 14:00:11 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk In light of DNSSEC, the EXP RR seems superfluous to me. Everything you can do with EXP, I can do with a SIG. I can't think of when I'd ever want to use EXP. (And in a 10,000 node zone, where each node has an A, KEY, and SIG RR, another 10,000 EXP RR's is going to be a hard sell, no?) I was actually at the Dallas meetings, but I missed the point behind defining a new RR to do something the SIG is more than capable of handling. Edie Received: from relay.tis.com by neptune.TIS.COM id aa09149; 14 Feb 96 16:58 EST Received: by relay.tis.com; id RAA07556; Wed, 14 Feb 1996 17:00:08 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007540; Wed, 14 Feb 96 16:59:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15228; Wed, 14 Feb 96 16:58:43 EST Received: by relay.tis.com; id QAA07537; Wed, 14 Feb 1996 16:59:38 -0500 Received: from bart.bbn.com(128.89.1.226) by relay.tis.com via smap (V3.1) id xma007534; Wed, 14 Feb 96 16:59:36 -0500 Received: from GAAK.BBN.COM by BART.BBN.COM id aa00832; 14 Feb 96 16:59 EST Date: Wed, 14 Feb 1996 16:57:54 EST Message-Id: To: edie@watson.ibm.com Cc: Namedroppers@internic.net, DNS-security@TIS.COM In-Reply-To: <9602141900.AA20309@edisto.watson.ibm.com> (edie@watson.ibm.com) Subject: Re: Expires RR proposal From: "Michael A. Patton" Sender: dns-security-request@neptune.tis.com Precedence: bulk Date: Wed, 14 Feb 96 14:00:11 -0500 From: "Edie E. Gunter" In light of DNSSEC, the EXP RR seems superfluous to me. That was my reaction when I first heard it mentioned in Dallas, but many discussions at DNSIND, DNSSEC, and in the corridors, convinced me that it was an interesting avenue to explore. Since I was thus on both sides of that question at different times, I figured I might be a good candidate to balance the exposition. Everything you can do with EXP, I can do with a SIG. I can't think of when I'd ever want to use EXP. The times you'd want to use an EXP are when your zone does not run security (which can happen for many reasons[*]) and thus you don't have SIGs. Even if you have some SIGs, using EXPs when what you want is expiration, rather than overloading the SIGs for this function may be simpler to manage (i.e. I could add EXPs by hand edit, I probably wouldn't hand edit a SIG) in some contexts. The original proposal (which is in the DNSSEC doc) was to use a SIG that didn't have any signature data (this has been variously called the NULL SIG algorithm or the "no security" algorithm). The security people were (rightfully, IMHO) somewhat leery of specifying in the DNS Security spec, something that gave no security. This concern came out clearly near the end of the DNSIND meeting. Thus the idea of a separate RR for when this is the functionality you want. Logically use of the EXP RR replaces use of the SIG RR with NULL algorithm. I was actually at the Dallas meetings, but I missed the point behind defining a new RR to do something the SIG is more than capable of handling. The discussion (as I recall) happened mostly at the end of the DNSIND meeting, very briefly at DNSSEC, and in the corridors in between. The basic reason is that there are valid uses for expiration above and beyond those required for DNSSEC, and since there may be reasons that security isn't run[*], having the expiration available as a separable part of the DNS seemed like the right idea. There is a placeholder in the document where I intended to put some of this discussion (in the intro), but I haven't had the time, yet. I'll save this message as a start on that... -MAP (*) Is it even legal in France and/or China to have SIG RRs on your server? (I don't know IANAL, especially in those countries :-). If I have a large isolated (small i) internet on which I trust everyone, why should I pay the cost of running crypto algorithms on all my DNS servers all the time just so I can expire some RRs occasionally? Received: from relay.tis.com by neptune.TIS.COM id aa23210; 15 Feb 96 10:31 EST Received: by relay.tis.com; id KAA16143; Thu, 15 Feb 1996 10:33:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016140; Thu, 15 Feb 96 10:32:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13129; Thu, 15 Feb 96 10:31:59 EST Received: by relay.tis.com; id KAA16133; Thu, 15 Feb 1996 10:32:54 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma016127; Thu, 15 Feb 96 10:32:45 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4255; Thu, 15 Feb 96 10:33:37 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5603; Thu, 15 Feb 1996 10:33:37 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 15 Feb 96 10:33:36 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA20173; Thu, 15 Feb 1996 10:34:35 -0500 Message-Id: <9602151534.AA20173@edisto.watson.ibm.com> X-External-Networks: yes To: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Wed, 14 Feb 96 16:57:54 EST. Date: Thu, 15 Feb 96 10:34:35 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > The original proposal (which is in the DNSSEC doc) was to use a SIG > that didn't have any signature data (this has been variously called > the NULL SIG algorithm or the "no security" algorithm). The security > people were (rightfully, IMHO) somewhat leery of specifying in the DNS > Security spec, something that gave no security. If this is the only argument, then why not remove SIG from the DNS Security spec into its own spec and allow it to be general purpose? Seriously. Rename it (if you like) and make the signature information optional. (Although I must ask, why is it okay to have a KEY RR with no key data, but it is NOT okay to have a SIG RR with no signature data?) > The times you'd want to use an EXP are when your zone does not run > security (which can happen for many reasons[*]) and thus you don't have > SIGs. Are EXP's disallowed in secure DNS? If not which expiration time will win -- that of the SIG or that of the EXP? Do we really want 2 set of rules regarding what happens to expired RRs -- DNSSEC says they appear as if they've been deleted; the EXP spec implies maybe not? We want dynamic updates to work the same whether you use security or not, right? I do. > Even if you have some SIGs, using EXPs when what you want is > expiration, rather than overloading the SIGs for this function may be > simpler to manage (i.e. I could add EXPs by hand edit, I probably > wouldn't hand edit a SIG) in some contexts. Ah, but simpler for who? A sysadmin surely doesn't need the duplication. And, editting a NULL SIG by hand is as simple as editting an EXP by hand, imho. Edie Received: from relay.tis.com by neptune.TIS.COM id aa03213; 19 Feb 96 17:28 EST Received: by relay.tis.com; id RAA14711; Mon, 19 Feb 1996 17:29:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014704; Mon, 19 Feb 96 17:29:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00296; Mon, 19 Feb 96 17:28:19 EST Received: by relay.tis.com; id RAA14701; Mon, 19 Feb 1996 17:29:17 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma014699; Mon, 19 Feb 96 17:28:52 -0500 Received: by callandor.cybercash.com; id RAA11570; Mon, 19 Feb 1996 17:35:47 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma011567; Mon, 19 Feb 96 17:35:42 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA20674; Mon, 19 Feb 96 17:26:27 EST Date: Mon, 19 Feb 1996 17:26:27 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Edie E. Gunter" Cc: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: <9602151534.AA20173@edisto.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk I don't really care that much either way on the EXP RR but I think the primary argument for it was that you SIG's expiration dates may most easily be set all the same by an application that goest through and signs your zone. So an RR might expire in some higher sense either before or after its authenticating SIG expires. Data would not be considered valid if either the EXP or SIG had expired. Donald PS: The dns sec draft does include a "null" SIG and KEY RR so you can use these for expiration under the curretn dns sec draft if you want. On Thu, 15 Feb 1996, Edie E. Gunter wrote: > Date: Thu, 15 Feb 96 10:34:35 -0500 > From: Edie E. Gunter > To: Namedroppers@internic.net, DNS-security@TIS.COM > Subject: Re: Expires RR proposal > > > The original proposal (which is in the DNSSEC doc) was to use a SIG > > that didn't have any signature data (this has been variously called > > the NULL SIG algorithm or the "no security" algorithm). The security > > people were (rightfully, IMHO) somewhat leery of specifying in the DNS > > Security spec, something that gave no security. > > If this is the only argument, then why not remove SIG from the > DNS Security spec into its own spec and allow it to be general > purpose? Seriously. Rename it (if you like) and make the signature > information optional. > > (Although I must ask, why is it okay to have a KEY RR with no key > data, but it is NOT okay to have a SIG RR with no signature data?) > > > The times you'd want to use an EXP are when your zone does not run > > security (which can happen for many reasons[*]) and thus you don't have > > SIGs. > > Are EXP's disallowed in secure DNS? If not which expiration time > will win -- that of the SIG or that of the EXP? Do we really want > 2 set of rules regarding what happens to expired RRs -- DNSSEC > says they appear as if they've been deleted; the EXP spec implies > maybe not? We want dynamic updates to work the same > whether you use security or not, right? I do. > > > Even if you have some SIGs, using EXPs when what you want is > > expiration, rather than overloading the SIGs for this function may be > > simpler to manage (i.e. I could add EXPs by hand edit, I probably > > wouldn't hand edit a SIG) in some contexts. > > Ah, but simpler for who? A sysadmin surely doesn't need the duplication. > And, editting a NULL SIG by hand is as simple as editting > an EXP by hand, imho. > > Edie > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa22146; 22 Feb 96 2:26 EST Received: by relay.tis.com; id CAA25100; Thu, 22 Feb 1996 02:28:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025098; Thu, 22 Feb 96 02:27:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13117; Thu, 22 Feb 96 02:26:58 EST Received: by relay.tis.com; id CAA25094; Thu, 22 Feb 1996 02:27:58 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma025092; Thu, 22 Feb 96 02:27:29 -0500 Received: from [153.37.13.174] (pool046.Max18.Los-Angeles.CA.DYNIP.ALTER.NET [153.37.13.174]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id XAA04578; Wed, 21 Feb 1996 23:27:05 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Feb 1996 02:30:48 -0400 To: "Edie E. Gunter" From: "James M. Galvin" Subject: Re: Expires RR proposal Cc: Namedroppers@internic.net, DNS-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk At 11:34 AM 2/15/96, Edie E. Gunter wrote: >> The original proposal (which is in the DNSSEC doc) was to use a SIG >> that didn't have any signature data (this has been variously called >> the NULL SIG algorithm or the "no security" algorithm). The security >> people were (rightfully, IMHO) somewhat leery of specifying in the DNS >> Security spec, something that gave no security. > >If this is the only argument, then why not remove SIG from the >DNS Security spec into its own spec and allow it to be general >purpose? Seriously. Rename it (if you like) and make the signature >information optional. You are missing the point. I was particularly vocal against the use of SIG RRs with no signature. It sounds like an oxymoron to me: here's a SIG RR to give you security; oh by the way there's no signature and thus no security. However, being sensitive to the needs of dynamic update in particular, there is clearly a need for an expiration time for RRs. So, the particular suggestion at the DNS security meeting was that the expiration RR be created (so that the concept is useful in general) and that the SIG RR would later be specified to disallow NULL signatures and might even have the expiration value removed in favor of this more general mechanism. The details of this suggestion will be visited when the specification is advanced from proposed to draft. >(Although I must ask, why is it okay to have a KEY RR with no key >data, but it is NOT okay to have a SIG RR with no signature data?) It is necessary to be able to state authoritatively, i.e., guarantee, that key does not exist for a given domain name. One mechanism by which this might be accomplished is to have a SIG record that always covered all RRs for a given domain. Thus, whenever you retrieve a KEY RR you would have to retrieve them all to verify that no KEY RR was intended to exist. A transaction SIG RR is also mechanism that could help this problem. However, it should be straightforward to see that being able to state authoritatively there is no key is a feature worth having. >> The times you'd want to use an EXP are when your zone does not run >> security (which can happen for many reasons[*]) and thus you don't have >> SIGs. > >Are EXP's disallowed in secure DNS? If not which expiration time >will win -- that of the SIG or that of the EXP? Do we really want >2 set of rules regarding what happens to expired RRs -- DNSSEC >says they appear as if they've been deleted; the EXP spec implies >maybe not? We want dynamic updates to work the same >whether you use security or not, right? I do. An expire RR only applies to the RR which it covers, as indicated by the COVER field in the RR. Thus, there should be no conflict. The only potential conflict I see is during the interim existence of both an EXP RR and the expiration in the SIG RR, which wins if there is an EXP RR that covers SIG RRs? My preference is the EXP RR wins, in deference to the migration path of eliminating the SIG RR expiration field. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa20531; 23 Feb 96 9:49 EST Received: by relay.tis.com; id JAA22305; Fri, 23 Feb 1996 09:51:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022302; Fri, 23 Feb 96 09:50:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19475; Fri, 23 Feb 96 09:49:55 EST Received: by relay.tis.com; id JAA22292; Fri, 23 Feb 1996 09:50:54 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma022285; Fri, 23 Feb 96 09:50:45 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20581; 23 Feb 96 9:44 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.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-ddi-00.txt Date: Fri, 23 Feb 96 09:44:04 -0500 Message-Id: <9602230944.aa20581@IETF.CNRI.Reston.VA.US> Sender: dns-security-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Detached Domain Name System Information Author(s) : D. Eastlake Filename : draft-ietf-dnssec-ddi-00.txt Pages : 8 Date : 02/22/1996 A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS) in archival contexts or contexts not connected to the Internet. 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-ddi-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-ddi-00.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: <19960222175802.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-ddi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-ddi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222175802.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa20779; 23 Feb 96 10:00 EST Received: by relay.tis.com; id KAA22557; Fri, 23 Feb 1996 10:01:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022549; Fri, 23 Feb 96 10:01:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20339; Fri, 23 Feb 96 10:00:23 EST Received: by relay.tis.com; id KAA22544; Fri, 23 Feb 1996 10:01:24 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma022540; Fri, 23 Feb 96 10:01:22 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20774; 23 Feb 96 9:46 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.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-update-00.txt Date: Fri, 23 Feb 96 09:46:05 -0500 Message-Id: <9602230946.aa20774@IETF.CNRI.Reston.VA.US> Sender: dns-security-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-00.txt Pages : 15 Date : 02/22/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution service (draft-ietf-dnssec-secext-*.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of strong security for the update operation. This draft describes how to use DNS digital signatures covering requests and data to secure updates and restrict them to those authorized to perform them as indicated by the updater's possession of cryptographic keys. 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-update-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-update-00.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: <19960222171824.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222171824.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa21945; 23 Feb 96 11:04 EST Received: by relay.tis.com; id LAA23979; Fri, 23 Feb 1996 11:06:26 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023972; Fri, 23 Feb 96 11:05:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25650; Fri, 23 Feb 96 11:04:56 EST Received: by relay.tis.com; id LAA23965; Fri, 23 Feb 1996 11:05:56 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xmaa23949; Fri, 23 Feb 96 11:05:28 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0803; Thu, 22 Feb 96 12:22:50 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5411; Thu, 22 Feb 1996 12:22:50 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 22 Feb 96 12:22:50 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA18232; Thu, 22 Feb 1996 12:23:53 -0500 Message-Id: <9602221723.AA18232@edisto.watson.ibm.com> X-External-Networks: yes To: "James M. Galvin" Cc: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Thu, 22 Feb 96 02:30:48 D. Date: Thu, 22 Feb 96 12:23:53 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > You are missing the point. I was particularly vocal against the use of SIG > RRs with no signature. It sounds like an oxymoron to me: here's a SIG RR > to give you security; oh by the way there's no signature and thus no > security. I'm afraid I may still be missing the point... > However, being sensitive to the needs of dynamic update in particular, > there is clearly a need for an expiration time for RRs. So, the particular > suggestion at the DNS security meeting was that the expiration RR be > created (so that the concept is useful in general) The concept is useful in general. The EXPIRES RR, however, offers no more generality than a NULL SIG, that I can see. > and that the SIG RR > would later be specified to disallow NULL signatures and might even have > the expiration value removed in favor of this more general mechanism. The > details of this suggestion will be visited when the specification is > advanced from proposed to draft. I would hope that you'd leave DNSSEC just like it is. The NULL SIG has been found to work just fine in the AIX and OS/2 DNS products which support dynamic updates. > However, it should be straightforward to see that being able to state > authoritatively there is no key is a feature worth having. Granted. Still, as you said above, it sounds like an oxymoron to me: here's a KEY RR to give you security; oh by the way there's no key data and thus no security. I don't see why the SIG is different here. Lack of signature data in a SIG would be a pretty strong hint to me that there is no security. But, I could always verify that by going back to the server and looking at the KEY. Edie Received: from relay.tis.com by neptune.TIS.COM id aa25719; 23 Feb 96 14:10 EST Received: by relay.tis.com; id OAA26952; Fri, 23 Feb 1996 14:11:57 -0500 From: lazear@gateway.mitre.org MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026947; Fri, 23 Feb 96 14:11:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08214; Fri, 23 Feb 96 14:10:26 EST Received: by relay.tis.com; id OAA26940; Fri, 23 Feb 1996 14:11:27 -0500 Received: from gateway.mitre.org(128.29.31.10) by relay.tis.com via smap (V3.1) id xma026936; Fri, 23 Feb 96 14:11:03 -0500 Received: from dockside.mitre.org (dockside.mitre.org [128.29.31.77]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id OAA11438; Fri, 23 Feb 1996 14:12:05 -0500 (EST) Received: from localhost (lazear@localhost) by dockside.mitre.org (8.7.2/8.7.2) with SMTP id OAA20769; Fri, 23 Feb 1996 14:15:24 -0500 (EST) Message-Id: <199602231915.OAA20769@dockside.mitre.org> X-Authentication-Warning: dockside.mitre.org: lazear owned process doing -bs X-Authentication-Warning: dockside.mitre.org: Host lazear@localhost didn't use HELO protocol To: "Edie E. Gunter" Cc: "James M. Galvin" , Namedroppers@internic.net, DNS-security@TIS.COM, lazear@gateway.mitre.org Subject: Re: Expires RR proposal In-Reply-To: Your message of "Thu, 22 Feb 96 12:23:53 EST." <9602221723.AA18232@edisto.watson.ibm.com> Date: Fri, 23 Feb 96 14:15:23 -0500 Sender: dns-security-request@neptune.tis.com Precedence: bulk > The concept is useful in general. The EXPIRES RR, however, offers > no more generality than a NULL SIG, that I can see. > The EXPIRE RR does not need some other server to verify with a KEY RR that the null SIG record is valid. The EXPIRE RR stands by itself, as do A, CNAME, and PTR records. No other infrastructure is required. > > and that the SIG RR > > would later be specified to disallow NULL signatures and might even have > > the expiration value removed in favor of this more general mechanism. The > > details of this suggestion will be visited when the specification is > > advanced from proposed to draft. > > I would hope that you'd leave DNSSEC just like it is. The > NULL SIG has been found to work just fine in the AIX and > OS/2 DNS products which support dynamic updates. > Did those systems have to implement *any* other infrastructure to make the NULL SIG work? It is the added complexity of nulling out the rest of DNSSEC that is annoying to those who want EXPIRE RRs. > > However, it should be straightforward to see that being able to state > > authoritatively there is no key is a feature worth having. > > Granted. Still, as you said above, it sounds like an oxymoron to me: > here's a KEY RR to give you security; oh by the way there's no key > data and thus no security. > The EXPIRE RR is a timer, not a security feature. One doesn't need to make the simple function more complicated. > I don't see why the SIG is different here. Lack of signature > data in a SIG would be a pretty strong hint to me that there is > no security. But, I could always verify that by going back > to the server and looking at the KEY. Exactly the complexity to avoid. Walt Received: from relay.tis.com by neptune.TIS.COM id aa26784; 23 Feb 96 15:11 EST Received: by relay.tis.com; id PAA28936; Fri, 23 Feb 1996 15:13:43 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028929; Fri, 23 Feb 96 15:13:15 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12245; Fri, 23 Feb 96 15:12:13 EST Received: by relay.tis.com; id PAA28924; Fri, 23 Feb 1996 15:13:13 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma028919; Fri, 23 Feb 96 15:13:07 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9367; Fri, 23 Feb 96 15:13:34 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 3955; Fri, 23 Feb 1996 15:13:34 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Fri, 23 Feb 96 15:13:34 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA15345; Fri, 23 Feb 1996 15:14:38 -0500 Message-Id: <9602232014.AA15345@edisto.watson.ibm.com> X-External-Networks: yes To: lazear@gateway.mitre.org Cc: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Fri, 23 Feb 96 14:15:23 EST. <199602231915.OAA20769@dockside.mitre.org> Date: Fri, 23 Feb 96 15:14:37 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > Did those systems have to implement *any* other infrastructure to make > the NULL SIG work? It is the added complexity of nulling out the rest > of DNSSEC that is annoying to those who want EXPIRE RRs. No, nothing else from DNSSEC was needed for NULL SIGs. > > I don't see why the SIG is different here. Lack of signature > > data in a SIG would be a pretty strong hint to me that there is > > no security. But, I could always verify that by going back > > to the server and looking at the KEY. > Exactly the complexity to avoid. And, if you don't care about security, you don't do this more complex step. The complexity I'd like to avoid is that of DNS as a whole -- duplication of function in multiple RRs and over-engineering solutions to simple problems. Edie Received: from relay.tis.com by neptune.TIS.COM id aa27109; 23 Feb 96 15:28 EST Received: by relay.tis.com; id PAA29611; Fri, 23 Feb 1996 15:29:55 -0500 From: lazear@gateway.mitre.org MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029603; Fri, 23 Feb 96 15:29:27 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13293; Fri, 23 Feb 96 15:28:25 EST Received: by relay.tis.com; id PAA29600; Fri, 23 Feb 1996 15:29:25 -0500 Received: from gateway.mitre.org(128.29.31.10) by relay.tis.com via smap (V3.1) id xma029586; Fri, 23 Feb 96 15:29:04 -0500 Received: from dockside.mitre.org (dockside.mitre.org [128.29.31.77]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id PAA12476; Fri, 23 Feb 1996 15:30:04 -0500 (EST) Received: from localhost (lazear@localhost) by dockside.mitre.org (8.7.2/8.7.2) with SMTP id PAA20909; Fri, 23 Feb 1996 15:33:23 -0500 (EST) Message-Id: <199602232033.PAA20909@dockside.mitre.org> X-Authentication-Warning: dockside.mitre.org: lazear owned process doing -bs X-Authentication-Warning: dockside.mitre.org: Host lazear@localhost didn't use HELO protocol To: "Edie E. Gunter" Cc: lazear@gateway.mitre.org, Namedroppers@internic.net, DNS-security@TIS.COM, lazear@gateway.mitre.org Subject: Re: Expires RR proposal In-Reply-To: Your message of "Fri, 23 Feb 96 15:14:37 EST." <9602232014.AA15345@edisto.watson.ibm.com> Date: Fri, 23 Feb 96 15:33:20 -0500 Sender: dns-security-request@neptune.tis.com Precedence: bulk > No, nothing else from DNSSEC was needed for NULL SIGs. > And, if you don't care about security, you don't do this more > complex step. > > The complexity I'd like to avoid is that of DNS as a whole -- > duplication of function in multiple RRs and over-engineering > solutions to simple problems. > Perhaps it makes sense to split out the SIG RR into its own document, to allow it to progress independant of the DNSSEC work? Perhaps as a "special case" description of the NULL SIG and its usage, leaving the "secure" usage to be defined in the context of the rest of the DNSSEC? This might satisfy both the secure and insecure usage environments? Walt Received: from relay.tis.com by neptune.TIS.COM id aa04490; 23 Feb 96 23:52 EST Received: by relay.tis.com; id XAA04963; Fri, 23 Feb 1996 23:43:57 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004960; Fri, 23 Feb 96 23:43:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28475; Fri, 23 Feb 96 23:42:26 EST Received: by relay.tis.com; id XAA04957; Fri, 23 Feb 1996 23:43:27 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma004955; Fri, 23 Feb 96 23:43:11 -0500 Received: by gw.home.vix.com id UAA26457; Fri, 23 Feb 1996 20:44:13 -0800 (PST) Date: Fri, 23 Feb 1996 20:44:13 -0800 (PST) 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: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <199602232033.PAA20909@dockside.mitre.org> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: lazear@gateway.mitre.org's message of 23 Feb 1996 13:13:20 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk >Perhaps it makes sense to split out the SIG RR into its own >document, to allow it to progress independant of the DNSSEC >work? Perhaps as a "special case" description of the NULL SIG >and its usage, leaving the "secure" usage to be defined in the >context of the rest of the DNSSEC? This might satisfy both >the secure and insecure usage environments? > > Walt DNSSEC is almost at PS. And the description of SIG(NULL) in the document is adequate to EXP's purposes. Perhaps Donald and Charlie will add a sentence or two during the PS review process? -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa04487; 23 Feb 96 23:52 EST Received: by relay.tis.com; id XAA04952; Fri, 23 Feb 1996 23:42:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004949; Fri, 23 Feb 96 23:41:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28446; Fri, 23 Feb 96 23:40:56 EST Received: by relay.tis.com; id XAA04945; Fri, 23 Feb 1996 23:41:57 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma004942; Fri, 23 Feb 96 23:41:40 -0500 Received: by gw.home.vix.com id UAA26402; Fri, 23 Feb 1996 20:42:42 -0800 (PST) Date: Fri, 23 Feb 1996 20:42:42 -0800 (PST) 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: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <9602232014.AA15345@edisto.watson.ibm.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: edie@watson.ibm.com's message of 23 Feb 1996 13:07:51 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk In article <9602232014.AA15345@edisto.watson.ibm.com>, edie@watson.ibm.com ("Edie E. Gunter") writes: > The complexity I'd like to avoid is that of DNS as a whole -- > duplication of function in multiple RRs and over-engineering > solutions to simple problems. Me, too. Since a SIG(NULL) does what EXP would do, and since SIG(NULL) is much easier to implement than SIG(*), I see no reason for EXP. I see EXP as unnecessary complexity for a system whose comparitive simplicity has been its biggest reason for success. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa11814; 24 Feb 96 11:19 EST Received: by relay.tis.com; id LAA08474; Sat, 24 Feb 1996 11:21:36 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008472; Sat, 24 Feb 96 11:21:07 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10670; Sat, 24 Feb 96 11:20:04 EST Received: by relay.tis.com; id LAA08469; Sat, 24 Feb 1996 11:21:06 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma008467; Sat, 24 Feb 96 11:21:05 -0500 Received: by callandor.cybercash.com; id LAA25245; Sat, 24 Feb 1996 11:28:30 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma025243; Sat, 24 Feb 96 11:28:26 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA23891; Sat, 24 Feb 96 11:18:48 EST Date: Sat, 24 Feb 1996 11:18:47 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Re: Expires RR proposal (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk Guess I should have cc'ed dns-security to star with on this message... ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html ---------- Forwarded message ---------- Date: Sat, 24 Feb 1996 10:40:56 -0500 From: Donald E. Eastlake 3rd To: Multiple recipients of list NAMEDROPPERS Subject: Re: Expires RR proposal On Fri, 23 Feb 1996 lazear@GATEWAY.MITRE.ORG wrote: > Perhaps it makes sense to split out the SIG RR into its own > document, to allow it to progress independant of the DNSSEC > work? Perhaps as a "special case" description of the NULL SIG > and its usage, leaving the "secure" usage to be defined in the > context of the rest of the DNSSEC? This might satisfy both > the secure and insecure usage environments? This doesn't seem particularly useful to me. The current DNSSEC draft (draft-ietf-dnssec-secext-09.txt) provides for null signatures (algorithm 253 signatures) and currently has the following sort of verbage is a couple of places: "... Number 253, known as the "expiration date algorithm", is used when the expiration date or other non-signature fields of the SIG are desired without any actual security. It is anticipated that this algorithm will only be used in connection with some modes of DNS dynamic update. For number 253, the signature field will be null. ..." I suspect some minor tweaking of this would be all that would be required for separate expiration use. But so far I haven't noticed anyone answer my point that I thought the reason for an EXP RR was when you *did* have security. In that case, the SIGs are normally all added by a seprate applicaton that puts a uniform expiration date in, sometime far enough in the future that you are sure you will get around to re-signing the zone before then. I suppose it could take into account TTL but that's not the right thing either as TTL is really just for cache consistency, not ultimate expiration. So if you do have security and the SIG expiration is fixed by your security machinery and TTL is for cache consistency, there is no place for expiration other than EXP. > Walt Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa19164; 26 Feb 96 8:58 EST Received: by relay.tis.com; id JAA20495; Mon, 26 Feb 1996 09:00:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020486; Mon, 26 Feb 96 09:00:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01130; Mon, 26 Feb 96 08:59:06 EST Received: by relay.tis.com; id JAA20476; Mon, 26 Feb 1996 09:00:09 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma020462; Mon, 26 Feb 96 08:59:53 -0500 Received: from [153.37.6.7] (pool007.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.7]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id GAA03150; Mon, 26 Feb 1996 06:00:38 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 09:04:37 -0400 To: Paul A Vixie From: "James M. Galvin" Subject: Re: Expires RR proposal Cc: dns-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk At 12:42 AM 2/24/96, Paul A Vixie wrote: >In article <9602232014.AA15345@edisto.watson.ibm.com>, >edie@watson.ibm.com ("Edie E. Gunter") writes: >> The complexity I'd like to avoid is that of DNS as a whole -- >> duplication of function in multiple RRs and over-engineering >> solutions to simple problems. > >Me, too. Since a SIG(NULL) does what EXP would do, and since SIG(NULL) >is much easier to implement than SIG(*), I see no reason for EXP. I see >EXP as unnecessary complexity for a system whose comparitive simplicity >has been its biggest reason for success. Well, beauty is in the eyes of the beholder. SIG(NULL) was invented to accommodate the needs of dynamic update that wanted an expire without security. Frankly, I don't know why, but there's more of them than there are of me, so C'est la Vie. However, I do not support SIG(NULL), I have never supported SIG(NULL), and I never will support SIG(NULL). It's hard enough convincing people what is secure and what's not, when there is security and when there isn't, and we're only going to confuse the issue further by providing a security enhancement to DNS with absolutely no security whatsoever. It's totally ludicrous. Dynamic update should have done EXP in the first place. In fact, SIG should use EXP instead of having it in the SIG RR; that's the only reason I relented in my argument against SIG(NULL). People did not want to slow down DNSSEC by waiting for EXP so we needed a transition state. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa20591; 26 Feb 96 9:57 EST Received: by relay.tis.com; id JAA21959; Mon, 26 Feb 1996 09:59:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021948; Mon, 26 Feb 96 09:59:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04818; Mon, 26 Feb 96 09:58:07 EST Received: by relay.tis.com; id JAA21940; Mon, 26 Feb 1996 09:59:10 -0500 Received: from unknown(147.28.0.39) by relay.tis.com via smap (V3.1) id xma021928; Mon, 26 Feb 96 09:58:40 -0500 Received: by rip.psg.com (Smail3.1.29.1 #1) id m0tr4Og-00080KC; Mon, 26 Feb 96 06:59 PST Message-Id: Date: Mon, 26 Feb 96 06:59 PST From: Randy Bush To: "James M. Galvin" Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal References: Sender: dns-security-request@neptune.tis.com Precedence: bulk > Dynamic update should have done EXP in the first place. In fact, SIG > should use EXP instead of having it in the SIG RR; that's the only reason I > relented in my argument against SIG(NULL). People did not want to slow > down DNSSEC by waiting for EXP so we needed a transition state. agreed. randy Received: from relay.tis.com by neptune.TIS.COM id aa21981; 26 Feb 96 11:04 EST Received: by relay.tis.com; id LAA23266; Mon, 26 Feb 1996 11:06:10 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023259; Mon, 26 Feb 96 11:05:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10574; Mon, 26 Feb 96 11:04:37 EST Received: by relay.tis.com; id LAA23247; Mon, 26 Feb 1996 11:05:40 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma023235; Mon, 26 Feb 96 11:05:20 -0500 Received: by gw.home.vix.com id IAA29970; Mon, 26 Feb 1996 08:06:20 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA31959; Mon, 26 Feb 1996 08:06:20 -0800 Message-Id: <9602261606.AA31959@wisdom.home.vix.com> To: "James M. Galvin" Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of "Mon, 26 Feb 1996 09:04:37 -0400." Date: Mon, 26 Feb 1996 08:06:20 -0800 From: Paul A Vixie Sender: dns-security-request@neptune.tis.com Precedence: bulk Someone here said that the expiration in a SIG pertains to me signature, whereas the expiration in an EXP pertains to EXP's RRset. If that's right, then the solutions spaces are disjoint and we should progress both. Received: from relay.tis.com by neptune.TIS.COM id aa29869; 26 Feb 96 16:22 EST Received: by relay.tis.com; id QAA01198; Mon, 26 Feb 1996 16:23:55 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001193; Mon, 26 Feb 96 16:23:27 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03550; Mon, 26 Feb 96 16:22:21 EST Received: by relay.tis.com; id QAA01184; Mon, 26 Feb 1996 16:23:25 -0500 Received: from unknown(129.34.139.4) by relay.tis.com via smap (V3.1) id xma001177; Mon, 26 Feb 96 16:23:20 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5123; Mon, 26 Feb 96 16:23:39 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 4963; Mon, 26 Feb 1996 16:23:38 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Mon, 26 Feb 96 16:23:38 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA19247; Mon, 26 Feb 1996 16:24:44 -0500 Message-Id: <9602262124.AA19247@edisto.watson.ibm.com> X-External-Networks: yes To: Paul A Vixie Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Mon, 26 Feb 96 08:06:20 PST. <9602261606.AA31959@wisdom.home.vix.com> Date: Mon, 26 Feb 96 16:24:44 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > Someone here said that the expiration in a SIG pertains to me signature, > whereas the expiration in an EXP pertains to EXP's RRset. If that's > right, then the solutions spaces are disjoint and we should progress both. There's just this one funny little quirk to be resolved. DNSSEC specifies that when the SIG expires, the covered RRs in effect go away (they're no longer provided in query responses and don't appear in a zone transfer.) I think the idea here was that secure servers don't give out unauthenticated data. ?? The net then is that when the SIG expires, the covered RRset also expires. Of course, if Jim wants to revamp DNSSEC to remove/redesign this "feature" and have the security stuff work with a new EXPIRE RR, as has been suggested/implied here, that's a different matter. Edie Received: from relay.tis.com by neptune.TIS.COM id aa00561; 27 Feb 96 17:45 EST Received: by relay.tis.com; id RAA20396; Tue, 27 Feb 1996 17:47:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020392; Tue, 27 Feb 96 17:47:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06541; Tue, 27 Feb 96 17:45:56 EST Received: by relay.tis.com; id RAA20389; Tue, 27 Feb 1996 17:46:59 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma020386; Tue, 27 Feb 96 17:46:45 -0500 Received: from [153.37.7.16] (pool016.Max7.Washington.DC.DYNIP.ALTER.NET [153.37.7.16]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id OAA04130; Tue, 27 Feb 1996 14:47:37 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 1996 17:51:37 -0400 To: "Edie E. Gunter" From: "James M. Galvin" Subject: Re: Expires RR proposal Cc: Paul A Vixie , dns-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk At 5:24 PM 2/26/96, Edie E. Gunter wrote: >> From Paul Vixie >> Someone here said that the expiration in a SIG pertains to me signature, >> whereas the expiration in an EXP pertains to EXP's RRset. If that's >> right, then the solutions spaces are disjoint and we should progress both. > >There's just this one funny little quirk to be resolved. DNSSEC >specifies that when the SIG expires, the covered RRs in effect >go away (they're no longer provided in query responses and don't >appear in a zone transfer.) I think the idea here was that >secure servers don't give out unauthenticated data. ?? The net >then is that when the SIG expires, the covered RRset also expires. > >Of course, if Jim wants to revamp DNSSEC to remove/redesign this >"feature" and have the security stuff work with a new EXPIRE RR, >as has been suggested/implied here, that's a different matter. I don't think a revamp/remove/redesign is necessary. At least, a scenario where there's a conflict is not immediately obvious to me. It would help me if someone who may be more knowledgeable about dynamic update could identify one. The expiration in the SIG RR indicate when the SIG expires. A SIG RR covers a particular type of other RR. When the SIG expires the RRs are to be removed from the DNS. The expiration in the EXP RR covers a particular type of other RR. When that time is reached the RRs are to be removed from the DNS. In either case, when the expiration time is reached the data is to be considered unavailable and removed from the DNS. I'm at a loss to identify a time when I would want either the signature or the expiration to remain valid when the other has been reached. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa01218; 27 Feb 96 18:12 EST Received: by relay.tis.com; id SAA20887; Tue, 27 Feb 1996 18:13:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020882; Tue, 27 Feb 96 18:13:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07118; Tue, 27 Feb 96 18:12:26 EST Received: by relay.tis.com; id SAA20877; Tue, 27 Feb 1996 18:13:29 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma020873; Tue, 27 Feb 96 18:13:23 -0500 Received: by gw.home.vix.com id PAA00366; Tue, 27 Feb 1996 15:14:12 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA00233; Tue, 27 Feb 1996 15:14:17 -0800 Message-Id: <9602272314.AA00233@wisdom.home.vix.com> To: "James M. Galvin" Cc: "Edie E. Gunter" , dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of "Tue, 27 Feb 1996 17:51:37 -0400." Date: Tue, 27 Feb 1996 15:14:17 -0800 From: Paul A Vixie Sender: dns-security-request@neptune.tis.com Precedence: bulk Dynamic Update does not require any sort of SIG(NULL) or EXP RR. That need was part of previous drafts, and is long, long gone. Patton's draft is not security related or dynamic update related, but rather is just a normal DNS extension. I have no idea why it is being discussed on dns-security. Received: from relay.tis.com by neptune.TIS.COM id aa13545; 28 Feb 96 4:19 EST Received: by relay.tis.com; id EAA25585; Wed, 28 Feb 1996 04:21:34 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025582; Wed, 28 Feb 96 04:21:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14453; Wed, 28 Feb 96 04:20:00 EST Received: by relay.tis.com; id EAA25579; Wed, 28 Feb 1996 04:21:04 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma025577; Wed, 28 Feb 96 04:20:51 -0500 Received: by gw.home.vix.com id BAA15808; Wed, 28 Feb 1996 01:21:52 -0800 (PST) Date: Wed, 28 Feb 1996 01:21:52 -0800 (PST) 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: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <9602262124.AA19247@edisto.watson.ibm.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: edie@watson.ibm.com's message of 26 Feb 1996 14:24:16 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk >There's just this one funny little quirk to be resolved. DNSSEC >specifies that when the SIG expires, the covered RRs in effect >go away (they're no longer provided in query responses and don't >appear in a zone transfer.) I think the idea here was that >secure servers don't give out unauthenticated data. ?? The net >then is that when the SIG expires, the covered RRset also expires. That strikes me as the wrong thing to do. Send the data, along with the expired signature. What's expired is the signature, not the data. This constitutes my first and only objection to DNSSEC, but since Edie had to point it out to me, I'm not going to lodge it formally (I had my chance.) -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa21716; 28 Feb 96 10:52 EST Received: by relay.tis.com; id KAA01329; Wed, 28 Feb 1996 10:54:00 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001307; Wed, 28 Feb 96 10:53:35 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28325; Wed, 28 Feb 96 10:52:29 EST Received: by relay.tis.com; id KAA01293; Wed, 28 Feb 1996 10:53:32 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma001276; Wed, 28 Feb 96 10:53:10 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9113; Wed, 28 Feb 96 10:53:55 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 8402; Wed, 28 Feb 1996 10:53:55 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Wed, 28 Feb 96 10:53:54 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA15217; Wed, 28 Feb 1996 10:55:02 -0500 Message-Id: <9602281555.AA15217@edisto.watson.ibm.com> X-External-Networks: yes To: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Tue, 27 Feb 96 17:51:37 D. Date: Wed, 28 Feb 96 10:55:01 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk Jim, > I don't think a revamp/remove/redesign is necessary. At least, a scenario > where there's a conflict is not immediately obvious to me. It would help > me if someone who may be more knowledgeable about dynamic update could > identify one. Dynamic update doesn't need expiration. I don't think there's a problem there. > The expiration in the SIG RR indicate when the SIG expires. A SIG RR > covers a particular type of other RR. When the SIG expires the RRs are to > be removed from the DNS. > > The expiration in the EXP RR covers a particular type of other RR. When > that time is reached the RRs are to be removed from the DNS. > > In either case, when the expiration time is reached the data is to be > considered unavailable and removed from the DNS. I'm at a loss to identify > a time when I would want either the signature or the expiration to remain > valid when the other has been reached. What you've described here sounds reasonable. My original complaint (over in namedroppers) against the EXPIRE RR, which got lost in all the hubbub over NULL SIGs, was that if there were two ways for RR's to be expired, how would the server decide which expiration time would win? As a user, I don't want to go to the trouble to set up an EXPIRE RR only to have a SIG expire earlier wiping out my data before I wanted it to go. I'll need to know to set them both the same. ?? (An implementation detail is how to resolve this with an offline zone signing procedure.) My other complaint (which also got lost in the fray) was against having two different ways of treating the expired RR's. DNSSEC says when the SIG expires, the RR's are gone. The EXPIRE spec suggests that they may stay around and be used in dynamic update processing. If the two different ways of treating expired data were allowed, then this raises lots of questions. If the EXPIRE time arrives before the SIG time in secure DNS, then are the EXPIRE rules used in handling the expired RRs? And vice versa if the SIG time arrives first? If EXPIRE RRs are used in unsecure DNS, would we see different results for the same database, same update, as in a secure DNS? It seems to me if there are 2 ways to expire data, then what happens to that expired data should be the same using either method of expiration. Someone suggested that the EXPIRE RR would only be used in unsecure DNS. I haven't seen anything from the DNSSEC folks to indicate it would be disallowed in secure DNS, however. What I thought you (or was it someone else?) were suggesting in earlier mail where it was mentioned having DNSSEC use an EXPIRE RR, was that you would do something like remove the expiration time from the SIG and *require* an EXPIRE RR for every SIG. Then, the time in the EXPIRE RR would indicate when the SIG would expire (of course, since an EXPIRE covers an RR type I don't know if this would work.) And then maybe DNSSEC would require EXPIRE RRs for the RRs the SIG covers and it would require that those expiration times be set the same as for the SIG. Of course, this would all be handled by software so managing it would not be a big deal. It would, however, make the zone files much larger with all these extra RR's. That's the kind of redesign I thought was being suggested. Obviously, I misunderstood. Now, I really don't know what was meant by hinting DNSSEC could use the EXPIRE RR. Sorry to be so longwinded... Edie Received: from relay.tis.com by neptune.TIS.COM id aa28776; 29 Feb 96 17:27 EST Received: by relay.tis.com; id RAA28025; Thu, 29 Feb 1996 17:29:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028017; Thu, 29 Feb 96 17:29:12 -0500 Received: from polar.tis.com.tis.com by tis.com (4.1/SUN-5.64) id AA12566; Thu, 29 Feb 96 17:28:06 EST Date: Thu, 29 Feb 96 17:28:06 EST From: Olafur Gudmundsson Message-Id: <9602292228.AA12566@tis.com> Received: by polar.tis.com.tis.com (4.1/SMI-4.1) id AA08175; Thu, 29 Feb 96 17:28:05 EST To: dns-security@neptune.tis.com Subject: ANNOUNCE: TIS/DNSSEC Beta 1.0 is now available Sender: dns-security-request@neptune.tis.com Precedence: bulk We are please to announce that the first Beta release of TIS/DNSSEC is now available. This version is a implementation of the current DNSSEC draft and it is based on bind-4.9.3-REL, it uses RSAREF, but you need to retrieve a copy from RSA. We are actively seeking beta testers. We are also pleased to announce the FIRST secure zone, sd-bogus.tis.com which is served from uranus.tis.com. We are also making a DNSSEC enhanced version of DIG available, in executable form for popular platforms. This version of dig is extended to query sd-bogus and other secure servers. There are no export restrictions on the executables For information on how to acquire TIS/DNSSEC retrieve the file /pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP, for further instruction on how the get the TIS/DNSSEC distribution. The new dig a sunos4.x executable versions are ftp:/ftp.tis.com/pub/DNSSEC/sdig.sunos4.gz Other versions will be made available as ftp:/ftp.tis.com/pub/DNSSEC/sdig..gz If you have any questions or problems please send a note to tisdnssec-support@tis.com. If you compile the new dig on a popular platform that we do not have an executable for please let us know. Enjoy, Olafur