From owner-dns-security Fri Aug 1 10:51:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01481 for dns-security-outgoing; Fri, 1 Aug 1997 10:49:16 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: <199707302214.PAA28837@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Aug 1997 10:32:09 -0400 To: dns-security@tis.com From: Edward Lewis Subject: Secure resolution Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Not to distract us from the "should we be dinking" debate ;) I have been working on writing a secure resolver for what now seems like an eternity. (Note to my boss, gee, sir, I am making continued measured improvement.) In trying to think of all possible ways of attacking DNSSEC, I've come up with a "topic for discusion." Suppose I receive a set of records and a signature that does indeed verify them. This does not guarantee that the records are true, as "we" have been assuming. The signature may have been generated by some entity other than the true zone. (A related attack might consist of taking genuine data and unscrupulously substituting a bad signature - so all others will drop the data.) To counter act this attack, for each retrieval, I need to determine who has the right to sign a record. This can be "message intensive" as I retrieve NS records and SOA records from the top down. (Mind you, cached records will speed up the process). Suggestion: What could help this process is the inclusion of the signed SOA record of the authoritive zone in the authority section. Why? It's a long story, best told by example. For: l4.l3.l2.l1.l0 type data SIG type by l2.l1.l0 I need to see that l4.l3.l2.l1.l0. and l3.l2.l1.l0. do not have SOAs and either: l2.l1.l0 does (along with a key signed by l1.l0) or l2.l1.l0 does not but has a key signed by someone whose key is signed by a zone somewhere along the line The SOA might be helpful even as additional data. There are two more issues. One is: When a non-zone domain name (e.g., singsing.hq.tis.com in hq.tis.com) has its own KEY set, signed by the zone, it and the zone can sign for, say, the TXT record set under the name. E.g.: hq.tis.com. SOA ... KEY ... SIG (KEY) by tis.com. singsing KEY ... SIG (KEY) by hq.tis.com. TXT ... SIG (TXT) by ? The latter signer could be either hq.tis.com. or singsing.hq.tis.com. (Of course, singsing's NXT, NS, and KEY must be signed by hq.tis.com.) Question: should the "rightful signer" be more specifically defined in the draft? Maybe this is a BCP topic. The other issue: DNSSEC doesn't necessarily end the hijacking of the DNS tree by others. Without being facetious, although one could easily be here, let's say Suzy is the owner of the one true root zone and Debbie is a competitor selling alternative tld's. Debbie could grab Suzy's signed data, remove the Suzy's signatures, add Debbie's extra (tld) data, and sign it with her private key and promote the result (and her public key) as the true root. This isn't a DNSSEC technical issue, but I'm raising it so we don't think that DNSSEC will 100% secure the root namespace from current attacks. Suzy needs to ensure the out of band transmission of her public keys is secure enough to make sure Debbie can't substitute hers. (This is definitely a BCP topic.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Aug 1 14:25:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03106 for dns-security-outgoing; Fri, 1 Aug 1997 14:23:48 -0400 (EDT) X-Authentication-Warning: defenestration.hq.tis.com: bwelling owned process doing -bs Date: Fri, 1 Aug 1997 14:31:57 -0400 (EDT) From: Brian Wellington X-Sender: bwelling@defenestration.hq.tis.com To: "Theodore Y. Ts'o" cc: John Gilmore , "James M. Galvin" , dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: <199708010228.WAA18036@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 31 Jul 1997, Theodore Y. Ts'o wrote: > Date: Wed, 30 Jul 1997 15:14:12 -0700 > From: John Gilmore > > The only DNSSEC code running in production today was written by me. > My code is in BIND-4.9.5 and BIND-8.1.1. There is no TIS code in > there. My code was based on some secure update code donated by IBM. > I guess there must be more than one developer. > > So it's in the latest released versions of BIND, eh? That's (in my > opinion) a strong reason not to change things; otherwise the confusion > resulting from the change is likely to set back the DNS deployment by > quite a bit. I wouldn't go so far as to say that DNSSEC is implemented in BIND 8.1.1. There's enough support so that the KEY, SIG, and NXT types are understood and (usually) correctly handled by named and dig. However, there are still some places where the new records are incomorreclty parsed, and none of the data is actually processed yet; SIGs and KEYs are not used for verification, NXTs are never sent when the server can authoritatively deny the existence of an RRSET. Additionally, only the last SIG record for a given name is stored. Overall, the DNSSEC code in BIND 8.1.1 is far from complete. We should have a prototype available soon which provides (nearly) a full implementation of RFC 2065 (without SIG AXFR), based on a highly enhanced version of BIND 8.1.1. If anyone would like a copy of the first prototype release (in a couple of days), let me know. > John, how many sites would you estimate are actually using the DNS SEC > features in BIND today? Since the current DNSSEC features do not support any security, there would be no reason to use them. I'd estimate 0. Brian From owner-dns-security Fri Aug 1 20:26:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05157 for dns-security-outgoing; Fri, 1 Aug 1997 20:23:46 -0400 (EDT) Message-Id: <199708020032.RAA24188@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-reply-to: Date: Fri, 01 Aug 1997 17:32:01 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > > So it's in the latest released versions of BIND, eh? That's (in my > > opinion) a strong reason not to change things; otherwise the confusion > > resulting from the change is likely to set back the DNS deployment by > > quite a bit. > > I wouldn't go so far as to say that DNSSEC is implemented in BIND 8.1.1. > There's enough support so that the KEY, SIG, and NXT types are understood > and (usually) correctly handled by named and dig. And the resolver, named-xfer, host, nslookup, ... > However, there are > still some places where the new records are incomorreclty parsed, > Additionally, only the last SIG record for a > given name is stored. First I've heard of any bugs. It all worked in BIND-4.9.5 when I checked it in. > and none > of the data is actually processed yet; SIGs and KEYs are not used for > verification, NXTs are never sent when the server can authoritatively deny > the existence of an RRSET. The server does return SIG records at the appropriate times, when they exist. It does not do any crypto, though, nor does it return KEY or NXT records unless you query for them (or for all records). My intent was to roll out support for the RR types before the export control and crypto licensing work was completed. In particular, to get an installed base of BINDs that can be secondary servers for later DNSSEC-secured zones. It has turned out to be quite a pain to get secondaries to upgrade; it took me more than a year, and changing one secondary to a different host, before I could add a KEY record to my own toad.com zone. (If your secondaries run a BIND that doesn't support an RR type used in your zone, named-xfer crashes on the secondary with a mysterious message in /var/tmp, and they never get zone updates until you remove the new RR. This can be prettied up, but is unfixable since the name compression in new RR types is not known by the secondary.) (You might consider this a reason to not change the RR format. The change would only set back *current* BINDs by, say, a month. But then we'll have to wait for those BINDs to deploy into the world before anyone can use the proposed new KEY RR. BINDs with the current RR format have been propagating for most of a year.) The export control work is almost complete, and the crypto licensing discussions are proceeding. Cryptographic code itself can't be integrated into BIND until these are handled. > > John, how many sites would you estimate are actually using the DNS SEC > > features in BIND today? Very few. I was hoping that people would use it for publishing keys for other cryptographic protocols, but that hasn't happened yet. (Such key publication doesn't require cryptographic validation. Some key formats, such as X.509 and PGP, already contain their own signatures. Others might still find a use for a defense against passive attacks even though active attacks would defeat their security. IPSEC would be using KEY records now, if its development had proceeded according to plan.) John From owner-dns-security Fri Aug 1 20:43:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05263 for dns-security-outgoing; Fri, 1 Aug 1997 20:41:45 -0400 (EDT) Message-Id: <199708020050.RAA24541@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Edward Lewis cc: dns-security@tis.com, gnu@toad.com Subject: Re: Secure resolution In-reply-to: Date: Fri, 01 Aug 1997 17:50:15 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > Suppose I receive a set of records and a signature that does indeed verify > them. This does not guarantee that the records are true, as "we" have been > assuming. The signature may have been generated by some entity other than > the true zone. Yes. Thanks, Ed! This is another area that I've been hoping any new draft would clear up. The DNSSEC specs never specify what a valid chain of signatures is. This might be fine for a certificate checker like Netscape, which can pop up a dialog box and ask the user if there's any doubt. But for a certificate checker embedded in a daemon, and in a library routine behind gethostbyname(), this is intolerable. There must be a specified algorithm that conclusively says Yea or Nay. (Of course there can be locally-configured overrides: "We trust this signature even if it doesn't match the worldwide generic rules." But there have to be worldwide generic rules, embedded into the worldwide generic BIND software and into other implementations of DNSSEC.) It significantly complicates the signature-checking process to not know how many zones "up" the signer is permitted to be. For example, the root should not be able to sign an arbitrary record anywhere in the tree; the registrar for the COM domain should not be able to sign singsing.hq.tis.com. My suggestion for dealing with this is to *require* that there be a KEY record at each level of the tree, signed by the key for the level one up. I am undecided about whether a zone boundary (SOA) should also be required at each sublevel of a secured zone (suggestions welcome). But if we require intermediate KEY records, then we know we can verify singsong.hq.tis.com with KEY record from hq.tis.com, and we can verify that with a KEY record from tis.com, which we can verify with a KEY record from .com, which we can verify with the root key. If we don't make this simple rule, then things get a lot more complicated. Here's a message I sent to the DNSSEC RFC authors more than a year ago: To: dee@cybercash.com, charlie_kaufman@iris.com, gnu Cc: paul@vix.com Subject: DNSSEC I-D comments Date: Fri, 07 Jun 1996 18:39:50 -0700 From: John Gilmore I've been implementing parts of the DNSSEC specs in BIND, and have found a few issues which I'll mention briefly, to see if you're aware of them. ... * The I-D is not specific about exactly how a resolver can determine the cryptovalidity of an RR. Suppose it comes with a SIG record which isn't signed by its own zone? (The spec recommends supplying KEY record signed by super- and sub-zones in addition to those signed by your own zone. And there will be further signers for Dynamic DNS.) Even the question assumes that one can tell what zone an RR is from (which may be possible, by insisting on cryptovalid NXT records for the places where a zone encompasses more than one level of domain hierarchy). Should such strangely signed SIG record be believed? Can anyone sign anyone else's RR's? Here's a draft algorithm: Have RR of type T. Query for all "SIG T" records. For each "SIG T" retrieved, Examine the signer name. If we know a priori the private key of the signer, Check the signature. If it fails, ignore this "SIG T". If it succeeds, believe the "T" RR is cryptovalid. [If this signer name isn't the immediate parent or child of the zone containing the orignial RR, ignore it? One must determine parent/childhood via cryptovalid SOA and NXT records, though, which involves recursion.] Query for all "KEY" records for the signer name. RECURSE to determine cryptovalidity of all "signer KEY"s. For each cryptovalid "signer KEY", Use the public key in the "signer KEY" to check the signature in the "SIG T" record. If it fails, ignore the "SIG T". If it succeeds, believe the "T" RR is cryptovalid. If you get here, you lack a public key for the current "SIG T". Skip it and go on to the next one. If you get here, you lack checkable "SIG T" records. Your RR of type T is not cryptovalid. This assumes that *any* SIG record can be believed, even if it's ronald@mcdonalds.com signing a key for beef@wendys.com. How should this algorithm be modified to further constrain the validation process? I've [bracketed] a possible way, but it's not clear to me that one can tell in the DNS what the immediate parent zone of an RR is, or what its immediate child zones are. Here's a draft algorithm to cryptovalidate the zone name containing an RR named "RRNAME": Query for "SOA" records for "RRNAME", and run them through the above process for cryptovalidity. If the response is: Cryptovalid SOA: its name is your zone. Cryptovalid NXDOMAIN: chop off last name in RRNAME and loop Cryptovalid no records (NXT): chop last name and loop Anything else: Fail. Note that these algorithms call each other and may nest to great depth. John Gilmore From owner-dns-security Fri Aug 1 21:32:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05477 for dns-security-outgoing; Fri, 1 Aug 1997 21:30:14 -0400 (EDT) Message-Id: <199708020138.SAA25476@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: Securing the root, in real life In-reply-to: Date: Fri, 01 Aug 1997 18:38:48 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk Ed Lewis said: > This isn't a DNSSEC technical issue, but I'm raising it so we don't think > that DNSSEC will 100% secure the root namespace from current attacks. Suzy > needs to ensure the out of band transmission of her public keys is secure > enough to make sure Debbie can't substitute hers. (This is definitely a > BCP topic.) I've been mulling this over for a while, too. Clearly BIND and secure resolvers will have to come with some public key(s) embedded in it for validating the root zone, just as today it comes with a root.cache file so that the root servers can be located. The alternative is that each sysadmin who installs a machine has to manually configure at least one public key. I don't think people who ship OS's and network appliances are going to ship products that way. It would be a bad idea, though to ship the public key for the "." zone in OS releases and BIND distributions. If the key ever needed to be changed (e.g. because the private key had been lost or stolen), it *would* require a manual administrative act at every DNS server or secure resolver. This would throw the net into chaos, with many machines unable to communicate (even if the manufacturer told the user how to change the root public key, the user would probably lose the instructions). It would mean that the act of changing the root key might well be more disruptive to the net than letting a root-key thief impersonate people at will. Not a pleasant thought. Much of the design for securing the root belongs in a Best Current Practice, but we need to look at it for the DNSSEC specs as well. If we decide it's wise, the software will have to implement a bcryptovalidation algorithm that permits some key other than the root key to be the "root" of the validation hierarchy. We've been assuming that the cryptovalidation algorithm would terminate with the root key. The best solution I've come up with is to have a "proto-root" or "root-signer" key embedded in the software, which could be used to validate a signature on the root key. This would permit the root key to be changed. The root private key needs to be used frequently, to sign the root zone with a short validity period so that RR's can be canceled. (Active attackers can replay earlier SIG records if they have long validity periods, even if those records are no longer distributed by the zone itself. This results from not actively checking a CRL on every signature - which I think is a good design decision.) The result is that the root key has to be relatively accessible, and thus relatively stealable. However, the proto-root key only needs to be used when the root key changes. A set of signatures covering the next ten years can be generated with it (to be gradually released over time), then it can go into a vault, under vacuum seal and alarms, and not be withdrawn again for ten years, or until a root key compromise is detected. I think if we standardize the cryptovalidation algorithm posted in my last message, it would allow this idea to work. The root key would not be initially presumed valid by the algorithm, since the resolver wouldn't have a statically-configured key for it. So the root's SIG records would be fetched, and their signers compared to the statically-configured keys. If there's a match, it may not matter what the name of the proto-root is (e.g. "root-signer.") But if the names of signers are checked *before* the statically-configured keys are checked, then such a signer would be bounced because it isn't the parent of the root zone. A disadvantage of the proto-root proposal is that a procedure which only happens every ten years is likely to be forgotten or fubar when it is next needed. The hardware and software needed to use it might also be unobtainable (have you tried to read an 800 BPI magtape recently?). Even a once-a-year procedure would require some diligence. For example, the root's owner could always ensure that they have three years' worth of proto-root signatures for the root key in hand. Then if, at the minus-three-years point when they go to make more, the proto-root key is discovered to be unavailable, we'd have three years to propagate new resolver software (or reconfigure old software) to include a new proto-root key. (The proto-root secret key could be stored by N-of-M secret-sharing, but there is no standard software for secret-sharing. Such software would have to be written and maintained, for once-a-year use. It would of course be likely to be buggy. And the programmer who debugs that software with live data -- the way it would fail -- would get to see the proto-root private key, which no human should ever see.) I could also see pluses and minuses of a design that distributed N different alternative root keys or root-signer keys in BIND. Someone else care to explore this option? Comments, please. John From owner-dns-security Fri Aug 1 22:36:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05760 for dns-security-outgoing; Fri, 1 Aug 1997 22:33:16 -0400 (EDT) Message-Id: <199708020241.TAA26744@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: How does DNSSEC handle multiple registrars in a domain? In-reply-to: Date: Fri, 01 Aug 1997 19:41:50 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk We are facing a situation where we shortly expect to have twenty to fifty different organizations submitting RR's into new top-level domains. In such an environment, how does Secure DNS work? I can think of a few ways: * Each registrar submits unsigned records to a central point; the central point signs all records with its key. The records are unprotected until the central point signs them. * Each registar signs its records with its key; there are twenty to fifty KEY records for the name of this zone, and all of them are valid for signing any name in the zone. * Each registrar signs its records with its key; these signatures are checked and stripped off by the central point, and replaced by a signature with the central point's key. There's a similar question about how this interacts with Dynamic Update. We'd presumably like it if new domain registrations were reflected instantly via dynamic update. I don't know enough about that topic to know how it would interact here, but I think dynamic updates are being secured via DNSSEC... John Gilmore From owner-dns-security Sun Aug 3 12:24:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14473 for dns-security-outgoing; Sun, 3 Aug 1997 12:18:38 -0400 (EDT) Message-Id: <199708031627.JAA06092@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Sun, 3 Aug 97 09:27:02 -0700 To: John Gilmore Subject: Re: Securing the root, in real life cc: dns-security@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199708020138.SAA25476@toad.com> X-No-Archive: : yes Sender: owner-dns-security@ex.tis.com Precedence: bulk This may seem a little less than lucid, but... Over the past year I've convinced myself several times DNSsec isn't going to work due to issues of management at the roots and resolvers. The proto-key approach attempts to solve some of the management problems but is nothing more than a CA's CA. It has merit but creates as many problems as it solves. The ultimate issue however, is who do you trust? Can we trust one government to be the CA's CA? A government cooperative? One or more corporations? A group of individuals? I think the answer to those questions is no; however, maybe there is a "maybe?" In the spirt of the CA's CA proposal, what if a key cooperative is formed by one or more well-accepted ethical organizations, such as the NCSA, IEEE, IETF, and NPR (or the BBC)? After trust the issues are security and mechanics. Vacuum seals and alarms are great but I think it is a bad idea to have the proto-root key in one place. The impact of its loss or compromise is too great. Pre-computed registrar keys has the same problem. I do not believe registrar keys are going to change frequently, maybe once in three years. For new registrars, a meeting can be held once a year to sign them. An out-of-bad mechanism (such as a group of people from different parts of the globe meeting in Zurich) bringing the proto-root key parts together doesn't seem like a substantial burden, unless you are the new register or their customers. :) There is a security risk bringing the parts together (e.x., the parts are confiscated when they enter the country), but it may be less than if the parts are stored together. (Of course, we could purchase an abandoned oil platform and establish our own country--it has been done.) Just some thoughts... -dpg From owner-dns-security Sun Aug 3 23:12:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17067 for dns-security-outgoing; Sun, 3 Aug 1997 23:10:36 -0400 (EDT) Date: Sun, 3 Aug 1997 23:18:52 -0400 From: Tal Rabin Message-Id: <9708040318.AA24578@sibylla.watson.ibm.com> To: dns-security@tis.com, gnu@toad.com Subject: Re: Securing the root, in real life Sender: owner-dns-security@ex.tis.com Precedence: bulk > I think it is a bad idea to have the >proto-root key in one place. The impact of its loss or >compromise is too great. > Excellent point! >There is a security risk bringing the >parts together Definitely true. But there is no need to bring the pieces together! There are means for computing signatures out of pieces of a key wihtout reconstructing the key, given that the pieces have been generated in a specific manner, as John said in an N-out-of-M threshold secret sharing scheme, for example. These methods enable even to deal with faulty pieces. Furthermore, they guarantee the security of the secret key over time even after repeated break-ins into the system. These modes of computation are known as proactive threshold cryptography. There is extensive research on this topic, and now some implementations under way. Tal ~p From owner-dns-security Mon Aug 4 08:11:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20247 for dns-security-outgoing; Mon, 4 Aug 1997 08:10:04 -0400 (EDT) Message-Id: <3.0.32.19970803134414.00c773f8@mbl.edu> X-Sender: crocker@mbl.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 03 Aug 1997 13:44:15 -0400 To: dennis.glatting@plaintalk.bellevue.wa.us From: Steve Crocker Subject: Re: Securing the root, in real life Cc: John Gilmore , dns-security@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk To avoid having just one party in charge of saying who's root is the real root, shift your point of view. Configure the bind clients to listen to any of a number of "publishers." Each publisher's job is to list who the various roots are. A publisher is not in charge of controlling, authorizing or creating any of the roots; its only job is to report who the roots are. Publishers can compete with each other for accuracy, completeness and availability. I'm envisioning that each vendor who supplies DNS software will configure into his product the names of one or more publishers, but it should also be easy for the end user to add or delete publishers. This avoids the issue of having just one proto-key. Steve At 09:27 AM 8/3/97 -0700, Dennis Glatting wrote: > >This may seem a little less than lucid, but... > >Over the past year I've convinced myself several times DNSsec >isn't going to work due to issues of management at the roots and >resolvers. The proto-key approach attempts to solve some of >the management problems but is nothing more than a CA's CA. It >has merit but creates as many problems as it solves. The >ultimate issue however, is who do you trust? > >Can we trust one government to be the CA's CA? A government >cooperative? One or more corporations? A group of >individuals? I think the answer to those questions is no; >however, maybe there is a "maybe?" In the spirt of the CA's CA >proposal, what if a key cooperative is formed by one or more >well-accepted ethical organizations, such as the NCSA, IEEE, >IETF, and NPR (or the BBC)? > >After trust the issues are security and mechanics. Vacuum >seals and alarms are great but I think it is a bad idea to have the >proto-root key in one place. The impact of its loss or >compromise is too great. Pre-computed registrar keys has the >same problem. > >I do not believe registrar keys are going to change frequently, >maybe once in three years. For new registrars, a meeting can be >held once a year to sign them. An out-of-bad mechanism (such as a >group of people from different parts of the globe meeting in >Zurich) bringing the proto-root key parts together doesn't >seem like a substantial burden, unless you are the new register >or their customers. :) There is a security risk bringing the >parts together (e.x., the parts are confiscated when they >enter the country), but it may be less than if the parts are >stored together. (Of course, we could purchase an abandoned >oil platform and establish our own country--it has been done.) > > >Just some thoughts... > > >-dpg > > > > ---------------------------------- Steve Crocker Desk: +1 703 716 5214 CyberCash, Inc. Main: +1 703 620 4200 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 22091 crocker@cybercash.com From owner-dns-security Mon Aug 4 08:12:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20321 for dns-security-outgoing; Mon, 4 Aug 1997 08:12:05 -0400 (EDT) Message-Id: <3.0.2.32.19970804093538.007bd8f0@mail.communities.com> X-Sender: mccoy@mail.communities.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 04 Aug 1997 09:35:38 -0700 To: John Gilmore From: Jim McCoy Subject: Re: Securing the root, in real life Cc: dns-security@tis.com In-Reply-To: <199708020138.SAA25476@toad.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk John Gilmore wrote: [regarding securing the "root" of the DNS tree and maintaining the security of a long-lived key in an unstable environment...] > >(The proto-root secret key could be stored by N-of-M secret-sharing, >but there is no standard software for secret-sharing. [...]) > >I could also see pluses and minuses of a design that distributed N >different alternative root keys or root-signer keys in BIND. Someone >else care to explore this option? A couple of options one could also consider are: 1) Since this operation is something which is performed infrequently it is possible to consider some of the more esoteric crypto protocols. Group signature operations can allow for various threshold agreements to be used to determine the nature of the TLDs (and given the current direction which domestic U.S. policy seems to be headed on this issue...) and would allow for the infrequent key operations to be performed through various secure, distributed multi-party computations. Compromise would require attacking multiple locations, parties who "drop out" can have their shares regenerated by a pre-determined subset of the whole, and a particular threshold can be used to add members to the system. 2) Given the nature of the changes we are making to the DNS system there is another, more radical, option which should also be considered; do not make an effort to protect a "global" root but rather use the "branch protection" which DNSSEC allows to give local DNS perspectives security without dictating structure (roots can exist but are not mandated.) One of these days we are all going to learn that global namespaces, any global namespace, does not work. Never has, never will... jim From owner-dns-security Mon Aug 4 10:55:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21413 for dns-security-outgoing; Mon, 4 Aug 1997 10:55:05 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-as-map-05.txt Date: Mon, 04 Aug 1997 09:36:11 -0400 Message-ID: <9708040936.aa04852@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-05.txt Pages : 8 Date : 1997-08-02 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. Additions have developed to the Domain Name System to enable it to be used for authenticated public key distribution [RFC 2065]. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS security can be used to distribute their public keys. [Changes from previous version are to accommodate AS numbers larger than 16 bits and to delegate on decimal boundaries rather than binary boundaries.] Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu 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-as-map-05.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. 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: <19970802142643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802142643.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Mon Aug 4 11:10:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21507 for dns-security-outgoing; Mon, 4 Aug 1997 11:10:05 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Aug 1997 11:18:20 -0400 To: dns-security@tis.com From: Edward Lewis Subject: Secure resolver states & return codes Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk The following is a portion of the spreadsheet I am using to manage the return codes from the routine I am writing to perform fully secure DNS lookups (i.e., a secure resolver). I omitted (for the sake of a lot of things) "mechanisitic" errors (such as passing a null pointer into the routine), ill-formatted response buffers, and the funky prefixes on the defined constants. (If you'd rather think enums instead of defined constants, be my guest.) The table formatting is: "What's returned/detected" "What is discovered" "coarse return code" "fine return code" The course return code is what the routine returns at the function call level. (A number of coarse values are not shown here because they indicate a mechanistic error.) The fine return code is buried in a structure passed back with the reply. Things to note: 1) There are three different cases of signed responses, a signed answer, a signed NXT denying existence, and a signed SOA denying existence. The three are distinct in meaning yet all share the same subcases - with one exception (kind of). The signed answers are not checked for "appropriateness" in the block. (The check is done elsewhere). 2) The unsigned version of these cases similarly share common elements. 3) Defining "appropriate" is a whole matter in and of itself. 4) FAILED does not relate to the result of the verification process. Rather it refers to the result of the lookup process. A failed verification is as helpful to telnet as a verified non-existence of the name. ANSWERs only are returned in four subcases - verified answer, qualified unsigned answers (2 cases), and SIG-only response answering a query for the SIG type. 5) Unwanted = I didn't ask for it, ergo, this response is (assumed to be) a denial of existence message. 6) Bare signature refers to a SIG(type) arriving without any type records. I am putting this out to see if others have discovered "states" I haven't considered. I am *not* interested in a debate about the API design at this point. (Mine's not perfect, but I'm still in the process of understanding the nature of the problem - which will be the driving factor in the API design.) Signed appropriate answers and are appropriate and verify ANSWER VERIFIED but no local keys FAILED NO_LOCAL_KEYS but there are multiple SIGs FAILED MULTIPLE_SIG but is temporally invalid FAILED SIG_TIME_BAD but zone has a NULL key in parent FAILED SIG_UNEXPECTED but zone has no keys FAILED NO_ZONE_KEYS but fails verification FAILED VERIFY_FAILED but by signed by wrong name FAILED WRONG_SIGNER but with illegal key FAILED ILLEGAL_KEY Unsigned appropriate answers and zone has a NULL key in parent ANSWER UNSIGNED_SURE and zone has no keys ANSWER UNSIGNED_UNSURE but zone has a key in parent FAILED SIG_EXPECTED Bare signature(s) in response and SIG was the query type ANSWER UNSIGNED_SURE but SIG was not the query type FAILED BARE_SIG (Unwanted) NXT w/ SIG(NXT) and are appropriate and verify FAILED NOSUCHSET_NXT but no local keys FAILED NO_LOCAL_KEYS_NXT but there are multiple SIGs FAILED MULTIPLE_SIG_NXT but is temporally invalid FAILED SIG_TIME_BAD_NXT but zone has a NULL key in parent FAILED SIG_UNEXPECTED_NXT but zone has no keys FAILED NO_ZONE_KEYS_NXT but fails verification FAILED VERIFY_FAILED_NXT but by signed by wrong name FAILED WRONG_SIGNER_NXT but with illegal key FAILED ILLEGAL_KEY_NXT but are inappropriate FAILED WRONG_NXT (Unwanted) NXT w/o SIG(NXT) and zone has a NULL key in parent FAILED NSS_UNSIGNED_SURE and zone has no keys FAILED NSS_UNSIGNED_UNSURE but the zone has a key in its parent FAILED EXPECTED_SIG_NXT (Unwanted) SOA w/o SIG(SOA) and zone has a NULL key in parent FAILED NSS_UNSIGNED_SURE and zone has no keys FAILED NSS_UNSIGNED_UNSURE but the zone has a key in its parent FAILED WRONG_DENIAL (Unwanted) SOA w/ SIG(SOA) and are appropriate and verify FAILED NOSUCHSET_SOA but no local keys FAILED NO_LOCAL_KEYS_SOA but there are multiple SIGs FAILED MULTIPLE_SIG_SOA but is temporally invalid FAILED SIG_TIME_BAD_SOA but zone has a NULL key in parent FAILED SIG_UNEXPECTED_SOA but zone has no keys FAILED NO_ZONE_KEYS_SOA but fails verification FAILED VERIFY_FAILED_SOA but by signed by wrong name FAILED WRONG_SIGNER_SOA but with illegal key FAILED ILLEGAL_KEY_SOA but are inappropriate FAILED WRONG_SOA NXDOMAIN w/ no records (unmodified) FAILED EMPTY_NXDOMAIN Inappropriate answers (unmodified) FAILED WRONG_ANSWER "Response to an "ANY" query" All have same RRset status (fine) common answer common answer Differing status's SEE_ANSWER specific set answer NXT valid but contradictory SEE_ANSWER spec. set & CONTRAD... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Mon Aug 4 12:14:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21903 for dns-security-outgoing; Mon, 4 Aug 1997 12:12:51 -0400 (EDT) Date: Mon, 4 Aug 1997 12:14:04 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: proposed SIG textual record change In-Reply-To: <199707302247.PAA29465@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk But just a normal query to a SIG with a wildcard name will very often result in a RR in which the labels field is "wrong" (owner name longer than labels indicates). Such RRs should be printed normally rather than with an error message or as a hex dump. (An RR with an owner name *shorter* than indicated by labels is always erroneous.) And you can't tell what the binary should be for such a retrieved RR without the labels value. It should not be hard for the new SIG text format code to read old SIG text format with the labels field omitted. So the only problem would be earlier code trying to read a master file produced by newer code. Based on the above, I believe the change in the SIG text is correct and should stay. Donald On Wed, 30 Jul 1997, John Gilmore wrote: > Date: Wed, 30 Jul 1997 15:47:27 -0700 > From: John Gilmore > To: dns-security@tis.com, gnu@toad.com > Subject: Re: proposed SIG textual record change > > I see the proposed change in the textual format of the SIG record of > marginal benefit. Even if the label field was explicit in the textual > records, implementations should be checking that the specified number > of labels matches the actual number of labels in the RR name, and > printing a warning or error if they don't match. Thus they'll need > access to the RR name anyway. If object-oriented implementations have > trouble performing this check, perhaps they should rethink their > object structure. Object orientation is no excuse for preventing > subroutines from accessing information that they need to do a high > quality job. > > If there is a concern that in the current SIG record, invalid label > counts will not be visible, it is misplaced. When printing a SIG RR, > if the label count doesn't match the actual number of labels on the RR > name, BIND-4.9.X already prints a comment field containing a warning > and the value of the labels field. This was changed in BIND-8, which > dumps the entire RR in hex instead, with a comment about it being an > invalid RR. I thought the earlier treatment was kinder, but I guess > one of the BIND maintainers didn't want special code to pamper bogus > RR's, once they had written the general case "invalid RR dump" code. > > John Gilmore > ===================================================================== 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 From owner-dns-security Mon Aug 4 12:16:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21909 for dns-security-outgoing; Mon, 4 Aug 1997 12:14:38 -0400 (EDT) Date: Mon, 4 Aug 1997 12:17:30 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: NXT record proposed changes In-Reply-To: <199707302255.PAA29584@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk John, Though what you say it true, I think it would be better to design for the long run. Howver, I have thought about this a bit more and would note that the proposed text representation in NXT is a list of RR type mnemonics or numbers. Thus if there were two representations possible, the current simple bit map and a more complex sparse bit map, going RR to text and back could result in different binary representation and cause signatures to fail. This going signed-object->text->signed-object is something to be avoided but it could happen and it is always best to design authentication systems so you can survive it. Therefore, if we are to have a more complex bit map, either similar to Elz's proposal or mine, it must be so specified that there is a unique conversion from a list of RR types to the NXT data RDATA which encodes that list. Donald PS: Similar considerations were why, in RFC 2065, it was specified that leading zeros were not permitted in various variable size KEY and SIG fields. However, TIS asked for that restriction to be removed and these fields are printed to base64 in the text representation so the exact binary form should be preserved. On Wed, 30 Jul 1997, John Gilmore wrote: > Date: Wed, 30 Jul 1997 15:55:41 -0700 > From: John Gilmore > To: dns-security@tis.com, gnu@toad.com > Subject: Re: NXT record proposed changes > > A small comment. The only immediate danger of having high-value RR > types comes from Microsoft, which high-handedly assigned itself two RR > types, 0xFF01 and 0xFF02, which we only discovered by examining packet > dumps from Microsoft servers. I suggest that we need not consider the > needs of people who ignore our standards processes while claiming to > "Embrace and Extend". If it makes their NXT records huge, I say > hurrah! > > John > ===================================================================== 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 From owner-dns-security Mon Aug 4 13:57:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22748 for dns-security-outgoing; Mon, 4 Aug 1997 13:54:39 -0400 (EDT) Date: Mon, 4 Aug 1997 13:57:54 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: <199708020032.RAA24188@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Fri, 1 Aug 1997, John Gilmore wrote: > Date: Fri, 01 Aug 1997 17:32:01 -0700 > From: John Gilmore > To: dns-security@tis.com, gnu@toad.com > Subject: Re: draft-ietf-dnssec-secext2-00.txt > > > > So it's in the latest released versions of BIND, eh? That's (in my > > > opinion) a strong reason not to change things; otherwise the confusion > > > resulting from the change is likely to set back the DNS deployment by > > > quite a bit. > > > > I wouldn't go so far as to say that DNSSEC is implemented in BIND 8.1.1. > > There's enough support so that the KEY, SIG, and NXT types are understood > > and (usually) correctly handled by named and dig. > > And the resolver, named-xfer, host, nslookup, ... Yes but none of them actually do any cyrpto or verify any signatures, do they? > > However, there are > > still some places where the new records are incomorreclty parsed, > > Additionally, only the last SIG record for a > > given name is stored. > > First I've heard of any bugs. It all worked in BIND-4.9.5 when I > checked it in. > > > and none > > of the data is actually processed yet; SIGs and KEYs are not used for > > verification, NXTs are never sent when the server can authoritatively deny > > the existence of an RRSET. > > The server does return SIG records at the appropriate times, when they > exist. It does not do any crypto, though, nor does it return KEY or > NXT records unless you query for them (or for all records). > > My intent was to roll out support for the RR types before the export > control and crypto licensing work was completed. In particular, to > get an installed base of BINDs that can be secondary servers for later > DNSSEC-secured zones. It has turned out to be quite a pain to get > secondaries to upgrade; it took me more than a year, and changing one > secondary to a different host, before I could add a KEY record to my > own toad.com zone. (If your secondaries run a BIND that doesn't > support an RR type used in your zone, named-xfer crashes on the > secondary with a mysterious message in /var/tmp, and they never get > zone updates until you remove the new RR. This can be prettied up, > but is unfixable since the name compression in new RR types is > not known by the secondary.) > > (You might consider this a reason to not change the RR format. The > change would only set back *current* BINDs by, say, a month. But then > we'll have to wait for those BINDs to deploy into the world before > anyone can use the proposed new KEY RR. BINDs with the current RR > format have been propagating for most of a year.) Your real world experience with BIND roll out is certainly something we should take into account. I'll respond in detail to your comments on the KEY RR changes, which are the only real problem and the only for for which the new draft suggests going to a new RR number. > The export control work is almost complete, and the crypto licensing > discussions are proceeding. Cryptographic code itself can't be > integrated into BIND until these are handled. I thought the export approval was for DNSSEC code with places to plug in crypto (RSA REF in US and EuroRef outside)? DNS only uses authentication, not confidentiality... > > > John, how many sites would you estimate are actually using the DNS SEC > > > features in BIND today? > > Very few. I was hoping that people would use it for publishing keys > for other cryptographic protocols, but that hasn't happened yet. > (Such key publication doesn't require cryptographic validation. Some > key formats, such as X.509 and PGP, already contain their own > signatures. Others might still find a use for a defense against > passive attacks even though active attacks would defeat their > security. IPSEC would be using KEY records now, if its development > had proceeded according to plan.) > > John 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 From owner-dns-security Mon Aug 4 16:58:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24045 for dns-security-outgoing; Mon, 4 Aug 1997 16:57:07 -0400 (EDT) Date: Mon, 4 Aug 1997 13:35:24 -0700 From: Erik.Nordmark@eng.sun.com (Erik Nordmark) Message-Id: <199708042035.NAA15944@bobo.eng.sun.com> To: dns-security@tis.com Subject: Draft of interest to DNSsec Cc: nordmark@jurassic.eng.Sun.COM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk I don't follow the DNSsec working group but I've published an ID (see below) that can potentially bypass the trust of a secure DNS. I'd like to make sure that the draft gets sufficient security review. If you have any comments please send them to me or the IPng list (ipng@sunroof.eng.sun.com) Thanks, Erik ----- Begin Included Message ----- >From owner-ipng@sunroof.eng.sun.com Wed Jul 30 18:11:11 1997 Date: Wed, 30 Jul 1997 17:39:03 -0700 From: nordmark@jurassic (Erik Nordmark) To: ipng@sunroof.eng.sun.com Subject: (IPng 4219) Site prefixes draft available MIME-Version: 1.0 I've submitted an Internet Draft based on the presentation I did in Memphis on Site Prefixes. If you want a preview before it shows up in the Internet Drafts directories you can get it from: ftp://playground.sun.com/pub/nordmark/draft-ietf-ipngwg-site-prefixes-00.txt Abstract This document specifies extensions to IPv6 Neighbor Discovery to carry site-prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ----- End Included Message ----- ----- End Included Message ----- From owner-dns-security Mon Aug 4 21:31:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA25605 for dns-security-outgoing; Mon, 4 Aug 1997 21:28:40 -0400 (EDT) Date: Mon, 4 Aug 1997 21:31:04 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <199707282009.NAA04954@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 28 Jul 1997, John Gilmore wrote: > Date: Mon, 28 Jul 1997 13:09:54 -0700 > From: John Gilmore > > > What I would like is for the community to speak up what they think > > about the changes in the specification > > My initial take is that the new KEY records are not a sufficient > improvement over the existing KEY records that it's worth making an > incompatible change. I agree that there are things in RFC 2065 > that we can and should tighten up, but let's NOT make any changes > that render deployed code incompatible. Well, I certainly willing to consider the option of not changing KEY (or, actually, not adopting a new format with a new RR number.) But there isn't really any DNSSEC crypto code deployed. There is just RR handling stuff. And how much code is there that uses that? I don't really know... I think DNS that offers cryptographically enforced security may deploy more rapidly as i represents a quantum leap in security against threats which have proved very real within the past month. > DNSSEC is not a draft any more, it's a Proposed Standard. We can't > keep dinking around with it to our hearts' content. There are things > we would now like to change in IP and TCP and SMTP and SNMP and PPP > and lots of other protocols, but we live with them and the world is > much better off as a result. *Please* don't set back the process of > standardizing and deploying DNSSEC, in return for some relatively > useless changes. The benefit of DNSSEC will be great -- but the > benefit is still zero until people can use it. Every day we slow down > its deployment we reduce that benefit. The proposed spec changes > don't add enough benefit to offset the reduction. I want DNSSEC deployed as soon as possible also. But right now is the last chance for change. As per other quotes posted, it is not at all unexpected for Proposed Standards to be changed. People are not supposed to operationally deploy with a presumption of stability until the Draft or Full Standard level (which are what all of you other examples are). > In case you forgot, governments worldwide are actively trying to > *outlaw* DNS security. (The outgoing UK Conservative government was > the most obvious -- their draft law at http://www.dti.gov.uk/pubs/ > would outlaw the provision of digital signatures for other parties, > whether for free or not. DNSSEC depends on parent zones being able to > sign child zones' keys. Luckily the Labour party won the election, > and the proposal has stalled, but since NSA is pushing it in dozens of > countries, it will be back.) I suggest that we get DNSSEC working and > deployed before these "proposals" are actually being debated in > legislatures. It would help to kill the bills to be able to say "five > thousand companies in this country are already doing this every day > without a problem -- now why do you want to make it illegal?" Excellent points but there isn't significant amount of real DNSEC code deployed out there, that I can tell, i.e., code that really signs RRs and looks for a chain of KEY-SIG-KEY-SIG... till it gets to a key that it was staticly configured to trust. If there are changes based on the requests of users or some implementation experience we have had, how much delay will incorporating them really have on deployment? I think that a production BIND with DNSSEC will be pretty popular and deploy pretty fast, though there will always be pockets that lag behind. > The three incompatible changes to the KEY record are: > > > *lengthened* flags 4 bytes flags 2 bytes > > The RFC 2065 flags field has four reserved bits. But it also has many > bits allocated that we could simply recycle in a backward-compatible > way. Here are the flags from RFC 2065 (excerpted): > > Bit 0 and 1 are the key "type" field. Bit 0 a one indicates > that use of the key is prohibited for authentication. Bit 1 a one > indicates that use of the key is prohibited for confidentiality. > Bit 2 is the "experimental" bit. Bit 2 is freed up under the new draft. > Bits 3-4 are reserved and must be zero. > Bit 5 on indicates that this is a key associated with a "user" > or "account" at an end entity, usually a host. > 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 ... > Bit 7 is the "zone" bit and indicates that this is a zone key > for the zone whose name is the KEY RR owner name. This is the public > key used for DNS data origin authentication. Technically the "zone" bit tells you about what the owner name means, not what protocls you can use. Admittedly, I'm not sure what protocols "zones" participate in other than DNS... It has been stated by some that bits 5-7 are mutually exclusive. This is not a requirement and it doesn't say that in RFC 2065 or the new draft. It does advise against using the same key for different meanings of the same name. If they were made mutually exclusive, you could save one bit here. > Bit 8 is reserved to be the IPSEC [RFC 1825] bit ... > Bit 9 is reserved to be the "email" bit ... > Bits 10-11 are reserved and must be zero. > Bits 12-15 are the "signatory" field. If non-zero, they > indicate that the key can validly sign RRs or updates of the same > name. > > But protocols are only supposed to get a flags bit if the exact same > keying material (KEY RR) can be used unchanged by several protocols. > RFC 2065 says: I don't think it has to be the "exact same ... unchanged ..." keying material. Any reasonably simple algorithmic change would be fine. > It is intended that new uses of DNS stored keys would initially be > implemented, and operational experience gained, using the > experimental range of the protocol octet. If demand for widespread > deployment for the indefinite future warrants, a value in the > assigned range would then be designated for the protocol. Finally, > (1) should the protocol become so widespread in conjunction with > other protocols and with which it shares key values that duplicate > RRs are a serious burden and (2) should the protocol provide > substantial facilities not available in any protocol for which a > flags field bit has been allocated, then one of the remaining flag > field bits may be allocated to the protocol. > > Since neither DNS zones, IPSEC, nor Email qualifies for (1), none of > them should (at this time) get a dedicated flag bit. They are just > protocols, which will each have unique keys. I think it quite likely that there would be a host identity key that could be used with IPSEC, host level Email, and TLS. In a Proposed Standard, I view these bit reservations as somewhat tentative, in any case. > Since no protocol numbers are allocated, in either RFC 2065 or in the > proposed draft, perhaps this is why people keep inappropriately > assigning flag bits for protocols! I suggest that we assign: > > 1 DNS Zone signing This another way of saving the one bit that can also by saved by making the user/end-entity/zone distinction a two bit field. > 2 IP Security > 3 Email The problem here of course, is who is going to win the Email secuirty wars... Are you sure you don't want MOSS, PGP, S/MIME, MSP, ... values... :-) > 4 TLS It really seems very likely that a host would use the same long term identity key for IPSEC and TLS and for host level email security... > 5 MUSE (email encryption by mail transfer agents) MUSE isn't a security protoctol really but a meta-syntax which would invoke existing Email security, I can't see a need for a separate value. > and make it *trivial* for other groups that want to use key records to > get an assignment. (I think we should dump the idea that people who > want to deploy KEY records *must* do it in the experimental range > first; we've just allocated under 2% of the available values.) Making I'm willing to drop that but this is the first mention by anyone of any dissatisfcation with it. I don't know how you translate "It is intended ..." into a "*must*". > these allocations, and making it easy to get a protocol number for new > uses, will eliminate the bit pressure on the flags field. IANA assignment is pretty quick and easy. About the only thing that would be faster (but much larger) is to make it use URL syntax or something so that anyone with a domain name can assign their own values. > If we reserved these three bits, and the Experimental bit (as Don's > draft proposed), then we would go from four spare bits to eight (out > of 16). I think that's enough for the long haul, and would not > require us to double the size of the field. I'm inclined to agree with you. After all, I originally picked 16 bits. But at least one IESG member was leary of so few bits when this was approved as Proposed and TIS has requested this. > > *new* preference 2 bytes > > This new field, which would express MX-like preference among several > keys supplied for the same protocol, would probably be useful. But I > don't think it's worth making an incompatible change for it at this > point. Yes, it is useful, and this is the last practical chance to add it. > > *new* key ident 2 bytes > > This field is unnecessary. In discussions with Olafur, it appears > that the idea is to add a new requirement that zone owners who create > KEY records *must* use unique 16-bit key identifiers (must prevent > duplication). This isn't explicit in Don's draft, though. I though it was.... > What they were trying to do was to make sure that implementations > would never encounter a case where two key ID's ("key fingerprints" in > SIG records in RFC 2065) are the same unless the keys are identical. > But coding the implementations so it will examine a short list of keys, > if they happen to have the same fingerprint, is a much better approach. > > Requiring that key-issuing sites serialize on a single key-numbering > location, in order to provide a slight programming convenience, adds a > system-level complication in order to solve a local problem. And an > unenforceable and uncheckable requirement of uniqueness, that is > depended on for security, creates a security problem where no hole > used to exist. > > It's also alleged that the previous method of computing a "key > fingerprint" in SIG records doesn't work well with non-RSA keys. I > haven't seen evidence of that, though. Realize that we're populating > a 16-bit hash space with sets of keys from the same domain name > (signer name). Even if a single domain name had a thousand keys > (which would be rather tough to retrieve in response to a single DNS > query) it would still only fill about 2% of the 65,536 possible > hashes; the chance of collisions is low. Even if one occurs, you just > get a minor performance problem *for that domain name*. The birthday paradox says that if you have 1000 keys at one name, the probability of collision is very high. Of course the chance of having that many keys to star with seems low. Another advantage to the new technique is that it is algorithm independent. An algorithm independent alternative I had though of was to use the bottom 16 bits of the MD4 hash of the key. (Yes, MD4 is a bit weak but it's fast and this is just for performance, not for security.) I suppose to be supercompatible with current formats and to permit an algorithm independent fingerprint, we could leave it as is for algorithm 1 and define it as the MD4 hash for all others. (I would note that it is currently not defined at all, other than the statement that it is algorithm independent, for any private algorithms that use the extentions of agorithm 254. > In summary, we should deploy the formats that we have now, and > strongly resist the temptation to dink with them. We must provide the > benefit of Secure DNS to the world soon (both to prevent the kind of > spoofing that is going on every day -- try http://www.per if you don't > believe me and to allow keys to be published for other protocols) or > we will not be able to provide it at all. > > John Gilmore 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 From owner-dns-security Mon Aug 4 22:12:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA25782 for dns-security-outgoing; Mon, 4 Aug 1997 22:10:41 -0400 (EDT) Date: Mon, 4 Aug 1997 22:13:46 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Secure resolution In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Fri, 1 Aug 1997, Edward Lewis wrote: > Date: Fri, 1 Aug 1997 10:32:09 -0400 > From: Edward Lewis > > ... > > Suppose I receive a set of records and a signature that does indeed verify > them. This does not guarantee that the records are true, as "we" have been > assuming. The signature may have been generated by some entity other than > the true zone. (A related attack might consist of taking genuine data and The important thing is to have a simple secure scheme and get it deployed. "Truth" is always, to some extent, in the eye of the beholder. If the RRset is secured by a SIG that is signed by a KEY that is secured by a SIG ... leading via the hierarchy to a key the resovler trusts, then you are in pretty good shape. If there are inconsistent data, the RFC and new draft pretty much say to trust the shorter path over the longer one, but this gets into local policy (maybe some staticly configured keys are better than others in the resolvers opinion). Further restrictions on the SIG-KEY-... path, while not unreasonable, are a second order issue and I don't think too much effort should be put into them if it delays deployment. > unscrupulously substituting a bad signature - so all others will drop the > data.) Throwing away or making bad the SIGs in a zone is just another of the uncountable number of denial of service attacks possible. The new draft explicitly says that DNSSEC does not protect against denial of service. > To counter act this attack, for each retrieval, I need to determine who has > the right to sign a record. This can be "message intensive" as I retrieve > NS records and SOA records from the top down. (Mind you, cached records > will speed up the process). The simplest model is that everything in a zone is signed by a zone key which is in turn certified by the parent zone till you get to root. If you allow dynamic update, then it can be signed by an entity key within the zone that can trace authority to the zone key through zero or more intermediate keys, all in the zone. If you allow cross certification, then maybe zone keys can by signed by a staticly confgured entity key in a different zone. But in all cases you have to be able to trace a SIG-KEY-... path to a staticly configured key. > Suggestion: What could help this process is the inclusion of the signed SOA > record of the authoritive zone in the authority section. Why? It's a long > story, best told by example. For: > > l4.l3.l2.l1.l0 type data > SIG type by l2.l1.l0 > > I need to see that l4.l3.l2.l1.l0. and l3.l2.l1.l0. do not have SOAs and > either: > l2.l1.l0 does (along with a key signed by l1.l0) > or > l2.l1.l0 does not but has a key signed by someone whose key is > signed by a zone somewhere along the line > > The SOA might be helpful even as additional data. I don't have a problem in principle but including the SOA and SIG(SOA) makes the reply substantially bigger. We really need to put through the bigger UDP change to DNS as was suggested a while ago by Paul Vixie. > There are two more issues. One is: > > When a non-zone domain name (e.g., singsing.hq.tis.com in hq.tis.com) has > its own KEY set, signed by the zone, it and the zone can sign for, say, the > TXT record set under the name. > > E.g.: > > hq.tis.com. SOA ... > KEY ... > SIG (KEY) by tis.com. > singsing KEY ... > SIG (KEY) by hq.tis.com. > TXT ... > SIG (TXT) by ? > > The latter signer could be either hq.tis.com. or singsing.hq.tis.com. (Of > course, singsing's NXT, NS, and KEY must be signed by > hq.tis.com.) singsing's NS record can be signed by singsing if singsing's key, signed by the zone, gives it authority to sign NSs. The text record can be signed by either. Seems like you would only get this via dynamic update in which case it depends which mode the zone is operating in. > Question: should the "rightful signer" be more specifically defined in the > draft? Maybe this is a BCP topic. To some extent, this is an update topic to be covered in a revision to the secure update RFC. > The other issue: > > DNSSEC doesn't necessarily end the hijacking of the DNS tree by others. > Without being facetious, although one could easily be here, let's say Suzy > is the owner of the one true root zone and Debbie is a competitor selling > alternative tld's. Debbie could grab Suzy's signed data, remove the Suzy's > signatures, add Debbie's extra (tld) data, and sign it with her private key > and promote the result (and her public key) as the true root. Excuse me but I think you are being overly authoritarian. IANA recommends a particular root. It's pefectly clear so far that about 99.5+% of the net will follow that for interoperability. The government doesn't hold a gun to your head and make you use the IANA root. Why shouldn't someone who want to make a fool of themselves be able to zone transfer root, edit it, resign with a different key, and configure their resolvers to point to their root servers and staticly configure their non-recommended root key? Trying to stop this is a sure way to make martyrs of such people besides you will almost certainly fail. It is enough that DNSSEC will stop pollution by RRs that are not in the tree users want to use. > This isn't a DNSSEC technical issue, but I'm raising it so we don't think > that DNSSEC will 100% secure the root namespace from current attacks. Suzy > needs to ensure the out of band transmission of her public keys is secure > enough to make sure Debbie can't substitute hers. (This is definitely a > BCP topic.) I don't see how its different from the root keys installed in NetScape or PEM or SET or anything else. You need to have at least one trusted public key to start from. This is true of all public key based systems I know of. DNSSEC is no different. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > Opinions expressed are property of my evil twin, not my employer. 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 From owner-dns-security Mon Aug 4 22:23:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA25899 for dns-security-outgoing; Mon, 4 Aug 1997 22:22:11 -0400 (EDT) Date: Mon, 4 Aug 1997 22:25:03 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Secure resolution In-Reply-To: <199708020050.RAA24541@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Fri, 1 Aug 1997, John Gilmore wrote: > Date: Fri, 01 Aug 1997 17:50:15 -0700 > From: John Gilmore > Subject: Re: Secure resolution > > > Suppose I receive a set of records and a signature that does indeed verify > > them. This does not guarantee that the records are true, as "we" have been > > assuming. The signature may have been generated by some entity other than > > the true zone. > > Yes. Thanks, Ed! This is another area that I've been hoping any > new draft would clear up. > > The DNSSEC specs never specify what a valid chain of signatures is. > This might be fine for a certificate checker like Netscape, which can > pop up a dialog box and ask the user if there's any doubt. But for a > certificate checker embedded in a daemon, and in a library routine > behind gethostbyname(), this is intolerable. There must be a > specified algorithm that conclusively says Yea or Nay. I don't know that at the Proposed Standard stage we know all the things and type of cross certification that are going to come up. Cross certification is the real problem. > (Of course there can be locally-configured overrides: "We trust this > signature even if it doesn't match the worldwide generic rules." But > there have to be worldwide generic rules, embedded into the worldwide > generic BIND software and into other implementations of DNSSEC.) > > It significantly complicates the signature-checking process to > not know how many zones "up" the signer is permitted to be. For > example, the root should not be able to sign an arbitrary record > anywhere in the tree; the registrar for the COM domain should not > be able to sign singsing.hq.tis.com. It only complicates things if you are trying to enforce these second order extra secrutiy restrictions, beyond hiearchy, on the SIG-KEY-... path, restrictions which only make it less convenient for a higher level key to abuse it's powers. All the complexity and efforts in this area don't stop abuse. .com can just create a new tis.com with a new key and forge all the signatures in it. The owner of .com has, by definition, the power to define what tis.com is. That's how hierarchial naming systems work. Root is a special case in DNS and is only supposed to be one layer deep. The RFC and current draft already say that implementations MAY ignore any attempt by root to sign anything deeper. Furthermore, the new draft contains explicit language saying that a zone can't sign below its delegation points. Since root is so easy to check for, I should probably change the language to require ignorning root signatures below top level domain names. As far as I can see, you are wrong when you say it compicates checking to permit signers from any higher level. It generally simplifies checking an RRset not to have to worry about these zonal boundary singing restrictions. If you want to secure against the compromise of high level keys, I don't think cryptography i what you want. Operational procedures are the way to go. Massive changes to a zone or changes in high level keys could cause alarms and require manual approval. (Notice how much good this did NSI when they screwed .com and .net ...) > My suggestion for dealing with this is to *require* that there be a > KEY record at each level of the tree, signed by the key for the level > one up. I am undecided about whether a zone boundary (SOA) should also > be required at each sublevel of a secured zone (suggestions welcome). > But if we require intermediate KEY records, then we know we can > verify singsong.hq.tis.com with KEY record from hq.tis.com, > and we can verify that with a KEY record from tis.com, which > we can verify with a KEY record from .com, which we can verify > with the root key. I think forcing KEYs and/or zones at every level is excessive and would cause a lot more overhead. > If we don't make this simple rule, then things get a lot more > complicated. Here's a message I sent to the DNSSEC RFC authors > more than a year ago: They only get complicated if we chose to make them so. Within the hierarchy, we can make rules. Simple rules or complex ones. Once you get into cross certification, I think you are deluding yourself if you believe you can make a rule which will encompase very many of the policies sites might want. > To: dee@cybercash.com, charlie_kaufman@iris.com, gnu > Cc: paul@vix.com > Subject: DNSSEC I-D comments > Date: Fri, 07 Jun 1996 18:39:50 -0700 > From: John Gilmore > > I've been implementing parts of the DNSSEC specs in BIND, and have found > a few issues which I'll mention briefly, to see if you're aware of them. > > ... > * The I-D is not specific about exactly how a resolver can determine > the cryptovalidity of an RR. Suppose it comes with a SIG record which > isn't signed by its own zone? (The spec recommends supplying KEY > record signed by super- and sub-zones in addition to those signed by > your own zone. And there will be further signers for Dynamic DNS.) > Even the question assumes that one can tell what zone an RR is from > (which may be possible, by insisting on cryptovalid NXT records for the > places where a zone encompasses more than one level of domain > hierarchy). Should such strangely signed SIG record be believed? Can > anyone sign anyone else's RR's? Here's a draft algorithm: > > Have RR of type T. > Query for all "SIG T" records. > For each "SIG T" retrieved, > Examine the signer name. > If we know a priori the private key of the signer, > Check the signature. If it fails, ignore > this "SIG T". If it succeeds, believe the "T" > RR is cryptovalid. > [If this signer name isn't the immediate parent or child > of the zone containing the orignial RR, ignore it? One > must determine parent/childhood via cryptovalid SOA and NXT > records, though, which involves recursion.] This is the place where cross certification policy is significant. Without cross certification, the signer has to be the same name or higher in that branch of the tree. Pretty easy to check. Or you can do the full blown thing of checking that its either the current zone's key or an entity key that you can trace through the current zone to the zone key... Perhaps most sites would like cross certification to the extent that any RRset signed by a staticly configured key is authenticated. Or perhaps there should be a requriement that the key be enabled to cross certify as part of the static configuration. Beyond that, it gets very murky what sorts of cross certification people are going to want to work. > Query for all "KEY" records for the signer name. > RECURSE to determine cryptovalidity of all "signer KEY"s. > For each cryptovalid "signer KEY", > Use the public key in the "signer KEY" to check the > signature in the "SIG T" record. If it > fails, ignore the "SIG T". If it succeeds, > believe the "T" RR is cryptovalid. > If you get here, you lack a public key for the current > "SIG T". Skip it and go on to the next one. > If you get here, you lack checkable "SIG T" records. Your > RR of type T is not cryptovalid. > > This assumes that *any* SIG record can be believed, even if it's > ronald@mcdonalds.com signing a key for beef@wendys.com. How should > this algorithm be modified to further constrain the validation process? > I've [bracketed] a possible way, but it's not clear to me that one can > tell in the DNS what the immediate parent zone of an RR is, or what > its immediate child zones are. The people at mcdonalds.com are probably perfectly happy believing a key for beef@wnedys.com they signed. That's a reasonable policy for them. But in the absence of specific poicy, you have to fall back to the DNS hiearachy. That is, a key for beef@wendys.com can be signed by beef.wendys.com, wendys.com, .com or . Except that everyone wants to limit this to the first two so that a compromise of .com or . will involve more work before beef.wendys.com can be foreged with cryptographic validity. > Here's a draft algorithm to cryptovalidate the zone name > containing an RR named "RRNAME": > > Query for "SOA" records for "RRNAME", and run them through > the above process for cryptovalidity. > If the response is: > Cryptovalid SOA: its name is your zone. > Cryptovalid NXDOMAIN: chop off last name in RRNAME and loop > Cryptovalid no records (NXT): chop last name and loop > Anything else: Fail. > > Note that these algorithms call each other and may nest to great depth. > > John Gilmore 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 From owner-dns-security Tue Aug 5 00:28:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA26633 for dns-security-outgoing; Tue, 5 Aug 1997 00:26:48 -0400 (EDT) Message-Id: <3.0.1.32.19970805001504.007453f8@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 05 Aug 1997 00:15:04 -0400 To: Steve Crocker From: Olafur Gudmundsson Subject: Re: Securing the root, in real life Cc: dns-security@tis.com In-Reply-To: <3.0.32.19970803134414.00c773f8@mbl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 01:44 PM 8/3/97 -0400, Steve Crocker wrote: >To avoid having just one party in charge of saying who's root is the real >root, shift your point of view. Configure the bind clients to listen to >any of a number of "publishers." Each publisher's job is to list who the >various roots are. A publisher is not in charge of controlling, >authorizing or creating any of the roots; its only job is to report who the >roots are. Publishers can compete with each other for accuracy, >completeness and availability. I'm envisioning that each vendor who >supplies DNS software will configure into his product the names of one or >more publishers, but it should also be easy for the end user to add or >delete publishers. This is the same model as we use today for root server addresses and I think this is the correct model for the key distribution of few top level points. This is simple to implement and add trust mechanisms to. This model in the beginning will involve humans configuring the keys, but later we may be able to automate the system. I think it is important that some of the publishing take palace outside computer networks, advertisements in newspapers/magazines, radio broadcast, etc. Olafur From owner-dns-security Tue Aug 5 00:28:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA26634 for dns-security-outgoing; Tue, 5 Aug 1997 00:26:49 -0400 (EDT) Message-Id: <3.0.1.32.19970805002746.006fb50c@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 05 Aug 1997 00:27:46 -0400 To: John Gilmore From: Olafur Gudmundsson Subject: Re: How does DNSSEC handle multiple registrars in a domain? Cc: dns-security@tis.com, ogud@tis.com In-Reply-To: <199708020241.TAA26744@toad.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 07:41 PM 8/1/97 -0700, John Gilmore wrote: >We are facing a situation where we shortly expect to have twenty to >fifty different organizations submitting RR's into new top-level >domains. In such an environment, how does Secure DNS work? I can >think of a few ways: > > * Each registrar submits unsigned records to a central point; >the central point signs all records with its key. The records are >unprotected until the central point signs them. This is a possibility, but I do not think this is a good idea as it is not possible to look at the signature and see what registration authority is responsible for this name. > > * Each registar signs its records with its key; there are twenty >to fifty KEY records for the name of this zone, and all of them are >valid for signing any name in the zone. This works if on registrar is in charge of names starting with a-c and the next one handles d-g etc. In this case the registrars must reserve the possible first name in their name space and NXT chains will be correct. > > * Each registrar signs its records with its key; these signatures >are checked and stripped off by the central point, and replaced by >a signature with the central point's key. The central point should not strip the signatures. It should only sign the NXT records as it is the only place that can generate and sign the NXT records. In this case we can trace via the signatures the registration authority responsible. (this requires that we can find out what key each authority is using, we can use TXT record stored under the zone name to reflect this). > >There's a similar question about how this interacts with Dynamic >Update. We'd presumably like it if new domain registrations were >reflected instantly via dynamic update. I don't know enough about >that topic to know how it would interact here, but I think dynamic >updates are being secured via DNSSEC... I think the third proposal is the way to go and it will great with dynamic update. > > John Gilmore > Olafur From owner-dns-security Tue Aug 5 00:28:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA26631 for dns-security-outgoing; Tue, 5 Aug 1997 00:26:46 -0400 (EDT) Message-Id: <3.0.1.32.19970804235547.006e8b00@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 04 Aug 1997 23:55:47 -0400 To: "Donald E. Eastlake 3rd" From: Olafur Gudmundsson Subject: Re: NXT record proposed changes Cc: dns-security@tis.com, ogud@tis.com In-Reply-To: References: <199707302255.PAA29584@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 12:17 PM 8/4/97 -0400, Donald E. Eastlake 3rd wrote: >Therefore, if we are to have a more complex bit map, either similar to >Elz's proposal or mine, it must be so specified that there is a unique >conversion from a list of RR types to the NXT data RDATA which encodes >that list. We can define that the verification format of NXT record is a bitmap of the range 0..(max_bit_set+7)/8. In this case we can use Elz's solution and the blocks can be present in any order. Or we specify that the 32 bit blocks MUST sorted be in increasing unsigned integer order. Elz's proposal is simpler than yours, and it maybe to complex anyway. > >Donald > >PS: Similar considerations were why, in RFC 2065, it was specified that >leading zeros were not permitted in various variable size KEY and SIG fields. >However, TIS asked for that restriction to be removed and these fields are >printed to base64 in the text representation so the exact binary form should >be preserved. I only asked for the restriction to be lifted on SIG records, KEY records should never have leading 0 in modulus. The leading zeros are harmless in SIG records and we found crypto systems that required that signature be same size as modulus. The main motivation for zero suppression in SIG records was to save space. The savings are not significant. Simple math: if key length is 8*n+m bits, where 0 To: dns-security@tis.com Subject: Re: How does DNSSEC handle multiple registrars in a domain? In-Reply-To: <3.0.1.32.19970805002746.006fb50c@pop.hq.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I don't mind speculating a bit but the operational exigencies of the new gTLD scheme are many and dwarf the considerations that were taken into account in designing DNSSEC. On Tue, 5 Aug 1997, Olafur Gudmundsson wrote: > Date: Tue, 05 Aug 1997 00:27:46 -0400 > From: Olafur Gudmundsson > To: John Gilmore > Cc: dns-security@tis.com, ogud@tis.com > > At 07:41 PM 8/1/97 -0700, John Gilmore wrote: > >We are facing a situation where we shortly expect to have twenty to > >fifty different organizations submitting RR's into new top-level And how do you know it won't be, say , 200 organization? > >domains. In such an environment, how does Secure DNS work? I can > >think of a few ways: > > > > * Each registrar submits unsigned records to a central point; > >the central point signs all records with its key. The records are > >unprotected until the central point signs them. > > This is a possibility, but I do not think this is a good idea as it is not > possible to look at the signature and see what registration authority is > responsible for this name. That the updates would be unprotected on the way to the central point just seems patently absurd. But it does not follow that they need be protected by DNSSEC SIGs. > > * Each registar signs its records with its key; there are twenty > >to fifty KEY records for the name of this zone, and all of them are > >valid for signing any name in the zone. > > This works if one registrar is in charge of names starting with a-c and the > next one handles d-g etc. In this case the registrars must reserve the > possible first name in their name space and NXT chains will be correct. I don't know what gTLD planning is going on but allowing any registry to sign anything, which probably permits them to update anything and interfere with another registries entries, seems like a bad idea. Besides, having to know 50 keys for the 7 new zones just seems like an unnecessary burden on resolvers. > > * Each registrar signs its records with its key; these signatures > >are checked and stripped off by the central point, and replaced by > >a signature with the central point's key. > > The central point should not strip the signatures. > It should only sign the NXT records as it is the only place that can > generate and sign the NXT records. > In this case we can trace via the signatures the registration authority > responsible. > (this requires that we can find out what key each authority is using, we > can use TXT record stored under the zone name to reflect this). I would bet my money that the gTLD effort will end up using an off the shelf commercial distributed database with symetric entryption on the paths between the registrars and the coordianting point (likely with public key set up of the symetric keys). If you assume success, you are talking about a lot of traffick and doing it all with small datums secured by RSA does not seem like a great design. In any case, there may be lots of whois like information involved, there will be billing by the coordination point, there need to be dispute resolution mechanisms, etc. We don't have any control over their design. I don't think we should impose additional burdens on ourselves by guessing at it. As long as they can secure the output of their system with DSNSEC, we have done enough in my opnion. > >There's a similar question about how this interacts with Dynamic > >Update. We'd presumably like it if new domain registrations were > >reflected instantly via dynamic update. I don't know enough about > >that topic to know how it would interact here, but I think dynamic > >updates are being secured via DNSSEC... I'm not sure what the value of "instantly" is. The rate of changes to the .com zone and related whois info probably over 5,000 a day by now. While we should keep in mind possible requirements, I don't know that initial releases of secure dynamic update need be engineered for .com. On the other hand, the basic DNSSEC mechanisms really do need to have some way of working for big zones, at least with a daily update cycle. > I think the third proposal is the way to go and it will great with dynamic > update. > > > > John Gilmore > > Olafur 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 From owner-dns-security Tue Aug 5 15:09:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02381 for dns-security-outgoing; Tue, 5 Aug 1997 15:09:29 -0400 (EDT) Date: Tue, 5 Aug 1997 15:12:11 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: NXT record proposed changes In-Reply-To: <3.0.1.32.19970804235547.006e8b00@pop.hq.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 4 Aug 1997, Olafur Gudmundsson wrote: > Date: Mon, 04 Aug 1997 23:55:47 -0400 > From: Olafur Gudmundsson > > At 12:17 PM 8/4/97 -0400, Donald E. Eastlake 3rd wrote: > >Therefore, if we are to have a more complex bit map, either similar to > >Elz's proposal or mine, it must be so specified that there is a unique > >conversion from a list of RR types to the NXT data RDATA which encodes > >that list. > We can define that the verification format of NXT record is a bitmap of > the range 0..(max_bit_set+7)/8. Yes, we do need to specify the exact size of the bit map when using the current format. > In this case we can use Elz's solution and the blocks can be present in any > order. Or we specify that the 32 bit blocks MUST sorted be in increasing > unsigned integer order. Whoa, if you go to any scheme with discontinuous blocks, you have to be very persnickity to have a unique encoding. It would have to specify something even more stringent than the blocks in order. For example, if hypothetical RR types 110 and 120 were present, you could encode one of several different blocks that encompass both bits or encode two blocks, one of which encompassed 110 near its end and one of which encompassed 120 at its beginning. The protocol would have to specify exactly which of these was the one unique correct encoding for all circumstances. > Elz's proposal is simpler than yours, and it maybe to complex anyway. True, but I think that, as shown above, for any of these more complex schemes, the standard would have to basicly include a precise pseudo-code algorithm. Given that, it probably does not make much difference. Based on all this, my inclination is to just change to the draft to clearly reserve all "bit map"s that have the zero bit on for future specification. And prohibit trailing zeros in the bit map. > >Donald > > > >PS: Similar considerations were why, in RFC 2065, it was specified that > >leading zeros were not permitted in various variable size KEY and SIG > fields. > >However, TIS asked for that restriction to be removed and these fields are > >printed to base64 in the text representation so the exact binary form should > >be preserved. > > I only asked for the restriction to be lifted on SIG records, KEY records > should never have leading 0 in modulus. The leading zeros are harmless in > SIG records and we found crypto systems that required that signature be > same size as modulus. Unless there is some objection, I'll change the part of the draft specifying the KEY RR to again prohibit leading zeros. > The main motivation for zero suppression in SIG records was to save space. > The savings are not significant. > Simple math: if key length is 8*n+m bits, where 0 somewhere between 1/2^m and 2^(m-1))signatures will have one leading zero > approximately 1/256 of these will have two leading zeros > etc. > > Thus the savings depend on the value of the modulus and what is the top bit > in the highest byte. > > Olafur 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 From owner-dns-security Tue Aug 5 15:15:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02426 for dns-security-outgoing; Tue, 5 Aug 1997 15:15:27 -0400 (EDT) Date: Tue, 5 Aug 1997 15:23:58 -0400 Message-Id: <199708051923.PAA24172@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: Donald E. Eastlake 3rd's message of Mon, 4 Aug 1997 21:31:04 -0400 (EDT), Subject: Re: Changes in DNSSEC specification, Request For Discussion Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk If we're going to be making changes, can we add support for an El Gamal signature type? If the fatest way to get things deployed is to have crypto support built in, and we given that we _still_ don't have an agreement with RSA, and the Diffie-Helman patent is about to expire, there's a really obvious solution..... - Ted From owner-dns-security Tue Aug 5 16:24:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02832 for dns-security-outgoing; Tue, 5 Aug 1997 16:24:27 -0400 (EDT) Date: Tue, 5 Aug 1997 16:27:14 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <199708051923.PAA24172@dcl.MIT.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Aren't there questions of exactly what El Gamal varient? But in general, there is no particular problem in producing a new draft like the dnssec Diffie Hellman key draft that is out but also having a SIG specification. This isn't a change, unless you want to make it the default. Adding a new KEY/SIG type is just allocating a algorithm number. Donald On Tue, 5 Aug 1997, Theodore Y. Ts'o wrote: > Date: Tue, 5 Aug 1997 15:23:58 -0400 > From: Theodore Y. Ts'o > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com > Subject: Re: Changes in DNSSEC specification, Request For Discussion > > If we're going to be making changes, can we add support for an El Gamal > signature type? If the fatest way to get things deployed is to have > crypto support built in, and we given that we _still_ don't have an > agreement with RSA, and the Diffie-Helman patent is about to expire, > there's a really obvious solution..... > > - Ted ===================================================================== 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 From owner-dns-security Tue Aug 5 16:27:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02855 for dns-security-outgoing; Tue, 5 Aug 1997 16:26:58 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Aug 1997 16:16:35 -0400 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: Secure resolution Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:13 PM -0400 8/4/97, Donald E. Eastlake 3rd wrote: >pretty good shape. If there are inconsistent data, the RFC and new draft >pretty much say to trust the shorter path over the longer one, but this gets Just this morning I realized you are allowing multiple signatures per set. Until then I didn't see what the hullabaloo about path lengths was all about. I'm still digesting the impact of multiple signatures in a set. >in the resolvers opinion). Further restrictions on the SIG-KEY-... path, >while not unreasonable, are a second order issue and I don't think too much >effort should be put into them if it delays deployment. In this instance, the more restrictions, the faster I get code out the door. I have a line in my verification-sanity routine which is: /* Is this name allowed to sign this set? */ The more stringent the rules, the shorter this question's answer becomes. >> The SOA might be helpful even as additional data. > >I don't have a problem in principle but including the SOA and SIG(SOA) makes >the reply substantially bigger. We really need to put through the bigger UDP Would you consider it as "data that should be sent, but if it doesn't fit, don't set the truncated bit"? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Tue Aug 5 16:56:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03044 for dns-security-outgoing; Tue, 5 Aug 1997 16:55:57 -0400 (EDT) Date: Tue, 5 Aug 1997 16:58:20 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Secure resolution In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 5 Aug 1997, Edward Lewis wrote: > Date: Tue, 5 Aug 1997 16:16:35 -0400 > From: Edward Lewis > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com > > At 10:13 PM -0400 8/4/97, Donald E. Eastlake 3rd wrote: > ... > > >in the resolvers opinion). Further restrictions on the SIG-KEY-... path, > >while not unreasonable, are a second order issue and I don't think too much > >effort should be put into them if it delays deployment. > > In this instance, the more restrictions, the faster I get code out the > door. I have a line in my verification-sanity routine which is: I don't see that. Restrictions take code to implement. Complex restrictions take complex code to implement. > /* Is this name allowed to sign this set? */ > > The more stringent the rules, the shorter this question's answer becomes. I think you mean the more likely the answer is no. The simpler the rules, the less code has to be written. Unfortuately the null rules (ie, always say yes), isn't very secure. The rule that the name has to be the same or shorter by dropping labels of the left is secure in my opinion and it doesn't take much to add restricitons on the root key. But restricting the signer to be in the same zone (or parent zone if it's a zone apex node) in general seems to me to add substantial complexity. Then if you want to permit some cross certification, things get really complicated and policy questions arise whose answers might be very different for different clients. > >> The SOA might be helpful even as additional data. > > > >I don't have a problem in principle but including the SOA and SIG(SOA) makes > >the reply substantially bigger. We really need to put through the bigger UDP > > Would you consider it as "data that should be sent, but if it doesn't fit, > don't set the truncated bit"? Then you have to specify realtive priority. Say you are retrieving an NS. You realy want the SIG(NS). But what is the relative priority of the KEY and SIG(KEY) for the subzone key and the SOA and SIG(SOA) for the superzone? > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > Opinions expressed are property of my evil twin, not my employer. 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 From owner-dns-security Tue Aug 5 17:22:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03215 for dns-security-outgoing; Tue, 5 Aug 1997 17:21:56 -0400 (EDT) Date: Tue, 5 Aug 1997 17:30:18 -0400 Message-Id: <199708052130.RAA24305@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: Donald E. Eastlake 3rd's message of Tue, 5 Aug 1997 16:27:14 -0400 (EDT), Subject: Re: Changes in DNSSEC specification, Request For Discussion Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Tue, 5 Aug 1997 16:27:14 -0400 (EDT) From: "Donald E. Eastlake 3rd" Aren't there questions of exactly what El Gamal varient? But in general, there is no particular problem in producing a new draft like the dnssec Diffie Hellman key draft that is out but also having a SIG specification. Yes, basically. There's certainly some issues that would have to get settled in the draft. This isn't a change, unless you want to make it the default. Adding a new KEY/SIG type is just allocating a algorithm number. What do you mean by default? I was thinking along the lines of making El Gamal a "MUST" implement, and making RSA a "SHOULD" (or optional) to implement. This would allow people to field dns-sec resolvers (with crypto!) without requiring that they make peace with RSADSI first. And in any case, given that El Gamal will be effectively free within a month, it seems natural to make it that the default MUST implement algorithm. And if it's true that we don't have any wide-scale deployment of the crypto code, "now's the time to make this change". - Ted From owner-dns-security Wed Aug 6 08:53:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08326 for dns-security-outgoing; Wed, 6 Aug 1997 08:50:53 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199708052130.RAA24305@dcl.MIT.EDU> References: Donald E. Eastlake 3rd's message of Tue, 5 Aug 1997 16:27:14 -0400 (EDT), Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Aug 1997 08:47:00 -0400 To: "Theodore Y. Ts'o" From: Edward Lewis Subject: Re: Changes in DNSSEC specification, Request For Discussion Cc: "Donald E. Eastlake 3rd" , dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 5:30 PM -0400 8/5/97, Theodore Y. Ts'o wrote: >What do you mean by default? Exactly this... >I was thinking along the lines of making El Gamal a "MUST" implement, >and making RSA a "SHOULD" (or optional) to implement. ... ;) Well, that's my interpretation. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Aug 6 08:56:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08384 for dns-security-outgoing; Wed, 6 Aug 1997 08:54:54 -0400 (EDT) Date: Wed, 6 Aug 1997 09:02:13 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708061302.JAA14467@argon.ncsc.mil> To: dns-security@tis.com Subject: Re: Secure resolution X-Sun-Charset: US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk > From: "Donald E. Eastlake 3rd" > > On Fri, 1 Aug 1997, John Gilmore wrote: > > > The DNSSEC specs never specify what a valid chain of signatures is. > > This might be fine for a certificate checker like Netscape, which can > > pop up a dialog box and ask the user if there's any doubt. But for a > > certificate checker embedded in a daemon, and in a library routine > > behind gethostbyname(), this is intolerable. There must be a > > specified algorithm that conclusively says Yea or Nay. > > I don't know that at the Proposed Standard stage we know all the things and > type of cross certification that are going to come up. Cross certification > is the real problem. The purpose of X.509 is to provide mechanisms that allow automated Yea or Nay answers in the face of varied trust models. The standard extensions allow restrictions on the number of issuers in a path, the namespace subsets that subordinate issuers are allowed to certify, the issuer's policy (with parameters), and equivalence mapping between different policies, among others. The benefit is that specific restrictions do not have to be hardwired into the software or the RFCs, they can be encoded at certificate generation time. Given that DNSSEC is not using the X.509 certificate format, it may still be useful to study the X.509 semantics for an idea of what sort of solutions are available. Netscape browsers don't require user interaction to make trust decisions - they provide an opportunity for (naive) users to modify their trust policies on the fly by installing new root certificates! (Imagine if the resolver were to pop up a dialog box asking if you want to configure a new DNS root.) This is a regrettable user interface "feature" of web browsers, but it is not tied to or required by any particular certification mechanism. From owner-dns-security Wed Aug 6 11:18:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09729 for dns-security-outgoing; Wed, 6 Aug 1997 11:16:59 -0400 (EDT) Date: Wed, 6 Aug 1997 11:19:35 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Global Name Spaces (was Re: Securing the root, in real life) In-Reply-To: <3.0.2.32.19970804093538.007bd8f0@mail.communities.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 4 Aug 1997, Jim McCoy wrote: > Date: Mon, 04 Aug 1997 09:35:38 -0700 > From: Jim McCoy > To: John Gilmore > Cc: dns-security@tis.com > > ..................... One of these days we are all going to learn that > global namespaces, any global namespace, does not work. Never has, never > will... > > jim Jim, Much of the rest of your message is good but above is nice souding nonsense. While nothing works perfectly, the global namespace of the world telephone system, the global namespace of ISO/UPS (Universal Postal Union) country codes, the global namespace of civil aircraft country identification prefixes, the global namespace of radio transmitter identification prefixes, the global namespace of Internet IP addresses, the global namespace of credit card numbers, the global namespace of ISBN book numbers, the global namespace of Internet domain names, the global names space of ISO Object Identifiers, and many others, work pretty well as far as I can tell. 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 WARNING, on 4 Sep 1997, +1-508 will change to +1-978. From owner-dns-security Wed Aug 6 11:49:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09920 for dns-security-outgoing; Wed, 6 Aug 1997 11:47:33 -0400 (EDT) Date: Wed, 6 Aug 1997 11:50:30 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <199708052130.RAA24305@dcl.MIT.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk This seems like a pretty big change. For El Gamal varients I know about, it would slow down verification substantially compared with RSA optimized for verification. I think this would also be the first IETF protocol mandating a public key scheme other than RSA. What do other people on the list think about it? Donald On Tue, 5 Aug 1997, Theodore Y. Ts'o wrote: > Date: Tue, 5 Aug 1997 17:30:18 -0400 > From: Theodore Y. Ts'o > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com > Subject: Re: Changes in DNSSEC specification, Request For Discussion > > Date: Tue, 5 Aug 1997 16:27:14 -0400 (EDT) > From: "Donald E. Eastlake 3rd" > > Aren't there questions of exactly what El Gamal varient? But in general, > there is no particular problem in producing a new draft like the dnssec > Diffie Hellman key draft that is out but also having a SIG specification. > > Yes, basically. There's certainly some issues that would have to get > settled in the draft. > > This isn't a change, unless you want to make it the default. Adding a > new KEY/SIG type is just allocating a algorithm number. > > What do you mean by default? > > I was thinking along the lines of making El Gamal a "MUST" implement, > and making RSA a "SHOULD" (or optional) to implement. This would allow > people to field dns-sec resolvers (with crypto!) without requiring that > they make peace with RSADSI first. And in any case, given that El Gamal > will be effectively free within a month, it seems natural to make it > that the default MUST implement algorithm. > > And if it's true that we don't have any wide-scale deployment of the > crypto code, "now's the time to make this change". > > - Ted > ===================================================================== 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 WARNING, on 4 Sep 1997, 1-508 will change to 1-978. From owner-dns-security Wed Aug 6 12:51:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10449 for dns-security-outgoing; Wed, 6 Aug 1997 12:49:03 -0400 (EDT) Date: Wed, 6 Aug 1997 12:56:20 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708061656.MAA14615@argon.ncsc.mil> To: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion X-Sun-Charset: US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk > For El Gamal varients I know about, it would slow down verification > substantially compared with RSA optimized for verification. Good point, but will CPU operations be an appreciable part of the total time required for DNS resolving? Won't network delays be far greater than cryptographic verification time? > I think this would also be the first IETF protocol mandating a > public key scheme other than RSA. > What do other people on the list think about it? > Donald You mean other than PKIX and TLS? :-) There are proposals under discussion in both lists to make DSA / DH the mandatory algorithms, where currently neither DSA nor RSA is required. If there is to be a required algorithm, it should be the least-encumbered one. From owner-dns-security Wed Aug 6 12:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10535 for dns-security-outgoing; Wed, 6 Aug 1997 12:57:32 -0400 (EDT) Message-Id: <3.0.1.32.19970806124211.00759a48@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 06 Aug 1997 12:42:11 -0400 To: "Donald E. Eastlake 3rd" From: Olafur Gudmundsson Subject: Re: NXT record proposed changes Cc: dns-security@tis.com In-Reply-To: References: <3.0.1.32.19970804235547.006e8b00@pop.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 03:12 PM 8/5/97 -0400, Donald E. Eastlake 3rd wrote: >On Mon, 4 Aug 1997, Olafur Gudmundsson wrote: > >> Date: Mon, 04 Aug 1997 23:55:47 -0400 >> From: Olafur Gudmundsson >> >> In this case we can use Elz's solution and the blocks can be present in any >> order. Or we specify that the 32 bit blocks MUST sorted be in increasing >> unsigned integer order. > >Whoa, if you go to any scheme with discontinuous blocks, you have to be >very persnickity to have a unique encoding. It would have to specify >something even more stringent than the blocks in order. For example, if >hypothetical RR types 110 and 120 were present, you could encode one of >several different blocks that encompass both bits or encode two blocks, >one of which encompassed 110 near its end and one of which encompassed >120 at its beginning. The protocol would have to specify exactly which >of these was the one unique correct encoding for all circumstances. In Elz's schema this is not applicable, the 64K bit space is divided into fixed 256 24bit blocks. the first byte identifies the block. type 110 is bit 14 in block 4, and type 120 is bit 0 in block 5. Thus these types along with NXT and SIG types would need at least 3 blocks. block 2 for SIG and NXT, block 4 for 110, block 5 for 120, a total of 12 bytes (96 bits). Your schema allows fancy encoding that may result in space savings if type numbers are scattered around 24 bit boundaries, as in your example above. > >> Elz's proposal is simpler than yours, and it maybe to complex anyway. > >True, but I think that, as shown above, for any of these more complex >schemes, the standard would have to basicly include a precise pseudo-code >algorithm. Given that, it probably does not make much difference. > >Based on all this, my inclination is to just change to the draft to clearly >reserve all "bit map"s that have the zero bit on for future specification. >And prohibit trailing zeros in the bit map. I can go along with this. The specification should say that bit 0 set to 0 indicates standard NXT bit map, bit 0==1 is reserved for future extension(s), where the other 7 bits indicate the version number of the extension. This allows up to 127 different extension mechanisms. I propose that the draft should say that NXT bit map is MUST be used if the max type number is less than n (My suggestions for n are 128 or 240). This gives us a breathing room for few years before extension mechanisms need to be widely deployed. Comments please ? From owner-dns-security Wed Aug 6 14:04:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11029 for dns-security-outgoing; Wed, 6 Aug 1997 14:04:03 -0400 (EDT) Message-Id: <3.0.2.32.19970806231519.0096abd0@mail.communities.com> X-Sender: mccoy@mail.communities.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 06 Aug 1997 23:15:19 -0700 To: dns-security@tis.com From: Jim McCoy Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: References: <199708052130.RAA24305@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald Eastlake wrote: [using El Gamal instead of RSA as the MUST algorithm] >This seems like a pretty big change. For El Gamal varients I know about, it >would slow down verification substantially compared with RSA optimized for >verification. The cost in CPU time is a lot cheaper than RSADSI licensing.... (sad but true) > I think this would also be the first IETF protocol mandating a >public key scheme other than RSA. And this is a bad thing? Next month, as in "less than sixty days from now", several public key methods will lose patent protection. Instead of giving users and designers the benefits of this we are thinking of specifying a system to use one of the methods which remains covered by a patent and needs to be licensed in some countries?!?!?! Why don't you try to justify using the patented method instead... jim From owner-dns-security Wed Aug 6 14:06:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11045 for dns-security-outgoing; Wed, 6 Aug 1997 14:06:02 -0400 (EDT) Message-Id: <33E8BEFE.4698@sunoco.nswc.navy.mil> Date: Wed, 06 Aug 1997 14:14:22 -0400 From: David Page X1566 Organization: Naval Surface Warfare Center Dahlgren Division X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: dns-security@tis.com Cc: davepage@juno.com Subject: List help References: <199708061656.MAA14615@argon.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk I need to remove my name for this list. Can someone tell me where the majordomo address is? I tried majordomo@tis.com but I didn't receive a response. --Dave Page From owner-dns-security Wed Aug 6 18:14:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12524 for dns-security-outgoing; Wed, 6 Aug 1997 18:11:34 -0400 (EDT) Date: Wed, 6 Aug 1997 18:14:47 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <199708061656.MAA14615@argon.ncsc.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 6 Aug 1997, David P. Kemp wrote: > Date: Wed, 6 Aug 1997 12:56:20 -0400 > From: David P. Kemp > > > For El Gamal varients I know about, it would slow down verification > > substantially compared with RSA optimized for verification. > > Good point, but will CPU operations be an appreciable part of the total > time required for DNS resolving? Won't network delays be far greater > than cryptographic verification time? I believe it will get a lot of initial deployment at high level ISP DNS servers that get banged on by a lot of resovlers for a lot of names. While net delays may account for most of the delay in answering any particular request, there will be many requests being processed in parallel and I believe that crypto calculations would be a serious problem. But I guess I don't necessarily mind giving a boost to sales of DEC Alpha chips and hardware crypto accelerators.... > > I think this would also be the first IETF protocol mandating a > > public key scheme other than RSA. > > What do other people on the list think about it? > > Donald > > You mean other than PKIX and TLS? :-) Have either of these been actually approved by the IESG yet? > There are proposals under discussion in both lists to make DSA / DH the > mandatory algorithms, where currently neither DSA nor RSA is required. So neither is an IETF standard mandating a public key algorithm other than TSA. > If there is to be a required algorithm, it should be the > least-encumbered one. No. That is clearly a strong factor but computational load, key/sig size, rate of improvement in breaking the fundamental algorithm, etc., are also considerations. Efforts are, I believe, still under way to get a release of the patent restrictions for RSA for DNSSEC. 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 WARNING, on 4 Sep 1997, +1-508 will change to +1-978. From owner-dns-security Wed Aug 6 18:25:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12624 for dns-security-outgoing; Wed, 6 Aug 1997 18:24:04 -0400 (EDT) Message-ID: <19970806152646.02697@bywater.songbird.com> Date: Wed, 6 Aug 1997 15:26:46 -0700 From: Kent Crispin To: dns-security@tis.com Subject: Re: How does DNSSEC handle multiple registrars in a domain? References: <3.0.1.32.19970805002746.006fb50c@pop.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.66 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, Aug 05, 1997 at 03:08:01PM -0400, Donald E. Eastlake 3rd wrote: > I don't mind speculating a bit but the operational exigencies of the new gTLD > scheme are many and dwarf the considerations that were taken into account in > designing DNSSEC. So far as the design has been considered, the "new gTLD scheme" has made no assumptions about DNSSEC whatsoever. I would say rather the reverse -- the gTLD design will almost certainly explictly avoid dependence on DNSSEC. [...] > > At 07:41 PM 8/1/97 -0700, John Gilmore wrote: > > >We are facing a situation where we shortly expect to have twenty to > > >fifty different organizations submitting RR's into new top-level > > And how do you know it won't be, say , 200 organization? Several thousand is a distinct possibility, some years down the road... > > >domains. In such an environment, how does Secure DNS work? I can > > >think of a few ways: > > > > > > * Each registrar submits unsigned records to a central point; > > >the central point signs all records with its key. The records are > > >unprotected until the central point signs them. > > > > This is a possibility, but I do not think this is a good idea as it is not > > possible to look at the signature and see what registration authority is > > responsible for this name. > > That the updates would be unprotected on the way to the central point > just seems patently absurd. But it does not follow that they need be > protected by DNSSEC SIGs In gTLD-speak there are registrars, and there are registries. A registry controls the data for a TLD. Registrars communicate with a registry using a protocol, the registry protocol (RP). The registry gets updates in RP, for a database for that TLD. This database includes whois data as well as DNS data. Periodically the registry generates zone file updates from the registry database, and updates the zone. The transactions between registrars and registries are signed, of course, but that signature validates transactions in RP, not DNS. In fact, the registrars do not have the ability to update DNS directly. Hence, as far as DNS is concerned, there is only one key per TLD to worry about, the registry key. All authentication of registrars is the concern of the registry, not DNS. Some indication of the registrar controlling the (SLD) name may appear in DNS, but it does not have to be a key -- it could just be a TXT entry that only the registry could update. [...] > I don't know what gTLD planning is going on but allowing any registry to sign > anything, which probably permits them to update anything and interfere with > another registries entries, seems like a bad idea. Yup. > Besides, having to know > 50 keys for the 7 new zones just seems like an unnecessary burden on > resolvers. Yup. [...] > > I would bet my money that the gTLD effort will end up using an off the > shelf commercial distributed database with symetric entryption on the > paths between the registrars and the coordianting point (likely with > public key set up of the symetric keys). If you assume success, you are > talking about a lot of traffick and doing it all with small datums > secured by RSA does not seem like a great design. However, you are overlooking the fact that a signature for each transaction (and a reply signed by the registry) gives non-repudiation. Remember that the registrars don't necessarily trust the registry, and the registry logs could be altered. However, a signed receipt from the registry gives the registrar undeniable proof of a transaction. > In any case, there may > be lots of whois like information involved, there will be billing by the > coordination point, there need to be dispute resolution mechanisms, etc. Yes. Lot's of etc etc etc. > We don't have any control over their design. I don't think we should impose > additional burdens on ourselves by guessing at it. As long as they can > secure the output of their system with DSNSEC, we have done enough in my > opnion. I agree totally. At one point I wanted to integrate shared registry mechanisms with DNSSEC, and in fact did a design sketch for such a thing. But I no longer believe it is desirable. > > >There's a similar question about how this interacts with Dynamic > > >Update. We'd presumably like it if new domain registrations were > > >reflected instantly via dynamic update. I don't know enough about > > >that topic to know how it would interact here, but I think dynamic > > >updates are being secured via DNSSEC... > > I'm not sure what the value of "instantly" is. The rate of changes to the > .com zone and related whois info probably over 5,000 a day by now. While we > should keep in mind possible requirements, I don't know that initial releases > of secure dynamic update need be engineered for .com. On the other hand, the > basic DNSSEC mechanisms really do need to have some way of working for big > zones, at least with a daily update cycle. Efficient update of big zones is a clear requirement. Bulk updates of zone files are probably the default case, with perhaps dynamic updates being done for emergency changes... -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html From owner-dns-security Wed Aug 6 19:05:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA12858 for dns-security-outgoing; Wed, 6 Aug 1997 19:04:34 -0400 (EDT) Message-Id: <3.0.2.32.19970807041533.00966c80@mail.communities.com> X-Sender: mccoy@mail.communities.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 07 Aug 1997 04:15:33 -0700 To: "Donald E. Eastlake 3rd" From: Jim McCoy Subject: Re: Global Name Spaces (was Re: Securing the root, in real life) Cc: dns-security@tis.com In-Reply-To: References: <3.0.2.32.19970804093538.007bd8f0@mail.communities.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk [skip this unless you want to read a rant on why global namespaces do not scale up to the sizes we are talking about] Donald Eastlake wrote: >On Mon, 4 Aug 1997, Jim McCoy wrote: [...] >> ..................... One of these days we are all going to learn that >> global namespaces, any global namespace, does not work. Never has, never >> will... >> [...] >Much of the rest of your message is good but above is nice souding nonsense. Which you completely fail to debunk because you seem to be missing the distinction between a range of addresses and a namespace. Global namespaces do not scale up beyond a several thousand entires (and generally start to become cumbersome at a few hundred entries) for a variety of reasons while address spaces scale to arbitrarily large sizes. The bitter truth is that my assertion is correct. One need only look at the ridiculous wrangling over the gTLDs to see the folly of pretending that if we create enough "global" namespaces then everyone will be happy. The failure of early X.500 and X.509 revs illustrates this point equally well. >While nothing works perfectly, the global namespace of the world telephone >system, the global namespace of ISO/UPS (Universal Postal Union) country >codes, the global namespace of civil aircraft country identification >prefixes, the global namespace of radio transmitter identification prefixes, >the global namespace of Internet IP addresses, the global namespace of credit >card numbers, the global namespace of ISBN book numbers, the global namespace >of Internet domain names, the global names space of ISO Object Identifiers, >and many others, work pretty well as far as I can tell. First of all the global namespace of Internet domain names has failed miserably in the task of scaling up to provide globally unique and easily identifiable network addressing. The mcdonalds.com example popularized by Wired and the money to be made in speculation in Internet names are two examples of how the Internet domain name system has failed at this task. In addition to failing to scale up the current top-down system is fragile and has a handful of points of failure which recent events have shown are pathetically vulnerable. The remaining examples are all global address spaces or are very small namespaces. A namespace is used by people to assign objects from the address space into information structures which work for their needs, usually in ways which are easily remembered or which are easy for the user to manipulate and traverse. An address space is usually designed to be compact, easy for a machine or algorithm to traverse, and the needs of human beings have little to do with these designs. No one actually uses address spaces if they can help it unless the data is only manipulated or communicated between computers. Please find me a single large namespace which is global, then try to find one which is both flexible and dynamic in the smallest amount (e.g. changes to the namespace do not require several months to accomplish and do not require the intervention of governmental or international agencies.) I have looked and not found one which is global and which works. The classic example is simply mapping personal names to phone numbers. If you were to try to find my phone number you cannot just call a central server and ask for Jim McCoy's phone number. You need to know what city I live in, and then you need to know which of the three James McCoy entries in Mountain View, CA correspond to the person you are trying to find. In fact, in most cases it is impossible to actually perform this simple mapping of a global address space to a namespace without requiring additional information or by _localizing_ the namespace and reducing the scope of the search. Now the namespace is no longer global. The same could also be true of Internet names. Why exactly does boeing.com need to be unique? Perhaps what is needed to make this system scale up and also traverse the social and political roadblocks which lie ahead is a few considerations for the concept that namespaces can be local or even personal and still accomplish the same tasks. The rush to centralize authority for namespaces under the blind assumption that what works now will scale up to ever larger sizes if absolute folly. Secure localized namespaces and flexible certificate systems (a la SPKI and some of x.509v3) make it possible to avoid this mistake, but I sincerely doubt it is possible to overcome the momentum behind "make it more of the same, and if that doesn't work just patch the big holes and we can pretend the others do not exist." Perhaps I am just an Internet decentralist but somehow the notion that everyone must see the exact same Internet from any point connected to this network of networks strikes me as fundamentally wrong. I am willing to wait for time to eventually prove me correct, but I stand by my claim that global namespaces do not work. jim From owner-dns-security Wed Aug 6 20:52:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13518 for dns-security-outgoing; Wed, 6 Aug 1997 20:50:33 -0400 (EDT) Message-Id: <199708070059.RAA01462@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: Re: DNSSEC RSA patent negotiations In-reply-to: Date: Wed, 06 Aug 1997 17:59:05 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > Efforts are, I believe, still under way to get a release of > the patent restrictions for RSA for DNSSEC. This is true, and I've been negotiating it. RSA is in general agreement with some form of license, and we have come a long way toward final agreement. The sticking point is in defining a contract that this community (DNSSEC WG, Security Area director, IESG, and IAB) would be happy with. I heard some comments after RSA sued PGP that said, "Even if we got a license, it would be hard to trust RSA not to renege on it". After all, PGP had a license too. I'm working with a lawyer to see how we can make such a license sufficiently bullet-proof that we can trust it for three years until the patent runs out. Nevertheless, I recommend that we define the key format, assign an algorithm identifier, and define a signature procedure and format for at least one alternative algorithm. Even if we don't define a new universal (required) algorithm, we should have a specified algorithm on hand in case of need. And it will tend to get implemented anyway, if it isn't limited by patents. > > If there is to be a required algorithm, it should be the > > least-encumbered one. > No. That is clearly a strong factor but computational load, key/sig size, > rate of improvement in breaking the fundamental algorithm, etc., are also > considerations. Not to mention general level of trustworthiness. I trust the RSA algorithm much more than I trust DSA, for example; not only because of its designers but because it's had more study. DSA has been shown to be a great host for covert channels. Each signature also requires a new random number, which might require hardware random numbers for TSIG's or for signing large zones. Availability of good hardware to accelerate the algorithm is also a factor. John From owner-dns-security Wed Aug 6 21:18:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA13692 for dns-security-outgoing; Wed, 6 Aug 1997 21:17:04 -0400 (EDT) Message-Id: <199708070124.SAA01869@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Jim McCoy , gnu@toad.com cc: "Donald E. Eastlake 3rd" , dns-security@tis.com Subject: Re: Global Name Spaces In-reply-to: <3.0.2.32.19970807041533.00966c80@mail.communities.com> Date: Wed, 06 Aug 1997 18:24:27 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > Why exactly does boeing.com need to be unique? Jim, the design of the DNS requires it to be unique, or the DNS will break. For a simple example, cacheing boeing.com RR's under the name "boeing.com" will produce wrong answers for some requesters if the name is not globally unique. DNS has no way to distinguish which "boeing.com" you are asking about, if there were more than one. I encourage you to research how to *engineer* a naming system that scales to global scope and also does not involve hierarchy or small numbers of points of failure. I agree that the hierarchical nature of DNS has required administrative and political solutions to problems that I'd rejoice to solve technically instead. But I fear that this is a research problem, just as a scalable global routing infrastructure is a research problem, requiring a breakthrough of insight (and a lot of attention to detail until the insight arrives). For short-term future use on today's Internet, and certainly for the DNSSEC effort, the rest of us must concentrate on improving the basic DNS design that we're already blessed/cursed with. John From owner-dns-security Wed Aug 6 22:56:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14223 for dns-security-outgoing; Wed, 6 Aug 1997 22:55:02 -0400 (EDT) Date: Wed, 6 Aug 1997 23:03:29 -0400 Message-Id: <199708070303.XAA27608@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: Donald E. Eastlake 3rd's message of Wed, 6 Aug 1997 18:14:47 -0400 (EDT), Subject: Re: Changes in DNSSEC specification, Request For Discussion Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Wed, 6 Aug 1997 18:14:47 -0400 (EDT) From: "Donald E. Eastlake 3rd" I believe it will get a lot of initial deployment at high level ISP DNS servers that get banged on by a lot of resovlers for a lot of names. While net delays may account for most of the delay in answering any particular request, there will be many requests being processed in parallel and I believe that crypto calculations would be a serious problem. But I guess I don't necessarily mind giving a boost to sales of DEC Alpha chips and hardware crypto accelerators.... Err... am I missing something? Why would the DNS servers need to be doing any crypto calculations when they're simply handing out SIG records? Sure, they'll have to do crypto when they create all of the various SIG records, but that should be it. How often a DNS server gets banged-on by resolvers shouldn't make a difference. So if using an El Gamal style signature is more expensive, that still only affects how long it takes to (a) make the zone file, and (b) have the resolver validate it. But that's not a problem which affects a centralized server. - Ted From owner-dns-security Thu Aug 7 03:28:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA15512 for dns-security-outgoing; Thu, 7 Aug 1997 03:28:03 -0400 (EDT) Message-Id: <199708070736.AAA07197@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Theodore Y. Ts'o" cc: dns-security@tis.com, gnu@toad.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-reply-to: <199708070303.XAA27608@dcl.MIT.EDU> Date: Thu, 07 Aug 1997 00:36:58 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > Err... am I missing something? > > Why would the DNS servers need to be doing any crypto calculations when > they're simply handing out SIG records? Any recursive query they do will require validating the RR's in order to determine whether to cache them and/or to pass them on to the original requester. Most sites configure a central recursive DNS server so that all users benefit from sharing its cache (and don't have to know how to transit a firewall, if any). This is more of an operational convenience issue for ISP's (all PPP lines are configured to use one DNS server run by the ISP). Jhon From owner-dns-security Thu Aug 7 06:56:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA16779 for dns-security-outgoing; Thu, 7 Aug 1997 06:56:01 -0400 (EDT) Date: Wed, 6 Aug 1997 17:20:20 -0700 (PDT) From: "Christian F. Tschudin" X-Sender: tschudin@crawdad To: Jim McCoy cc: dns-security@tis.com Subject: Re: Global Name Spaces In-Reply-To: <3.0.2.32.19970807041533.00966c80@mail.communities.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk [sorry for the deviation, but because mobile computing and computations may some day hit the DNS, this could be of general interest for this distribution list] On Thu, 7 Aug 1997, Jim McCoy wrote: > Donald Eastlake wrote: > >On Mon, 4 Aug 1997, Jim McCoy wrote: > [...] > >> ..................... One of these days we are all going to learn that > >> global namespaces, any global namespace, does not work. Never has, never > >> will... > >> > [...] > >Much of the rest of your message is good but above is nice souding nonsense. > > Which you completely fail to debunk because you seem to be missing the > distinction between a range of addresses and a namespace. > [...] > Perhaps I am just an Internet decentralist but somehow the notion that > everyone must see the exact same Internet from any point connected to this > network of networks strikes me as fundamentally wrong. I am willing to wait > for time to eventually prove me correct, but I stand by my claim that global > namespaces do not work. Dear Jim, Thanks a lot for your superb statement and arguments! Working in the area of mobile software agents I can also witness that a lot of people there too believe in the feasability of global namespaces. They simply assume that you will be able to address your mobile agent among the millions that may be crawling through the nets ... they dream about DNS like (but real time) locating functionality and certainly would be delighted if this would be secure ... I simply wanted to back up your statement - in our mobile code environment (messengers) we adhere to a strict locality principle: local names only, local currency, local protection etc. All other services have to be built on top of this basic functionality. When you start from this viewpoint (and you have to build all the nice "global" services by yourself), you quickly realize how partial, vulnerable and, most important, how expensive such attempts are. I would say that this is still basic research and unfortunately of no help for DNSSEC right now. christian. (another "internet decentralist" ;-) --- Christian F. Tschudin - International Computer Science Institute 1947 Center Street/Berkeley, CA 94704/(510) 643-9153/fax 643-7684 tschudin@icsi.berkeley.edu http://www.icsi.berkeley.edu/~tschudin From owner-dns-security Thu Aug 7 06:59:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA16857 for dns-security-outgoing; Thu, 7 Aug 1997 06:59:31 -0400 (EDT) Message-Id: <199708071059.GAA16857@portal.ex.tis.com> To: dns-security@tis.com From: "Matt Crawford" Subject: Re: NXT record proposed changes In-reply-to: Your message of Wed, 06 Aug 1997 12:42:11 EDT. <3.0.1.32.19970806124211.00759a48@pop.hq.tis.com> Date: Wed, 06 Aug 1997 20:34:04 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk How about a simple run-length encoding scheme? I'm no compression expert, but a scheme that tersely represents N1 uncompressed bits N2 zero bits N3 uncompressed bits ... would seem to cover the expected cases pretty well. Matt Crawford From owner-dns-security Thu Aug 7 10:33:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18578 for dns-security-outgoing; Thu, 7 Aug 1997 10:32:32 -0400 (EDT) Message-Id: <3.0.1.32.19970807103938.007420cc@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 07 Aug 1997 10:39:38 -0400 To: "Theodore Y. Ts'o" From: Olafur Gudmundsson Subject: Re: Changes in DNSSEC specification, Request For Discussion Cc: "Donald E. Eastlake 3rd" , dns-security@tis.com In-Reply-To: <199708070303.XAA27608@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:03 PM 8/6/97 -0400, Theodore Y. Ts'o wrote: >Err... am I missing something? > >Why would the DNS servers need to be doing any crypto calculations when >they're simply handing out SIG records? Sure, they'll have to do crypto >when they create all of the various SIG records, but that should be it. >How often a DNS server gets banged-on by resolvers shouldn't make a >difference. DNS server validates signatures in the following cases: 1. When loading a zone (from file or AXFR) 2. Before adding data to cache So you forgot about the second case. Also if the KEY validating the data is not available the server may request it and validate it, resulting in even more verifications. > >So if using an El Gamal style signature is more expensive, that still >only affects how long it takes to (a) make the zone file, and (b) have >the resolver validate it. But that's not a problem which affects a >centralized server. Wrong, server must validate the data in order to set the AD bit correctly. Given how hard it is to make sure about the final security status of DNS records it think that most resolvers will enter trust relationships with their DNS server and relay on the servers to do all the hard work. The speed of signature verification is crucial, DNS will perform many verifications than generations. > > - Ted > Olafur From owner-dns-security Thu Aug 7 13:37:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20011 for dns-security-outgoing; Thu, 7 Aug 1997 13:36:31 -0400 (EDT) Date: Thu, 7 Aug 1997 13:45:00 -0400 Message-Id: <199708071745.NAA27825@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: John Gilmore Cc: "Theodore Y. Ts'o" , dns-security@tis.com, gnu@toad.com In-Reply-To: John Gilmore's message of Thu, 07 Aug 1997 00:36:58 -0700, <199708070736.AAA07197@toad.com> Subject: Re: Changes in DNSSEC specification, Request For Discussion Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Thu, 07 Aug 1997 00:36:58 -0700 From: John Gilmore Any recursive query they do will require validating the RR's in order to determine whether to cache them and/or to pass them on to the original requester. Most sites configure a central recursive DNS server so that all users benefit from sharing its cache (and don't have to know how to transit a firewall, if any). This is more of an operational convenience issue for ISP's (all PPP lines are configured to use one DNS server run by the ISP). Ah, now I understand the original concern. I had thought people were worried about the top-level root servers, which get banged on by a lot of people, but which don't have recursive queries turned on.... I've actually never understood the appeal of running a centralized named server for a site; it's not like the root servers change *that* often (we tend to upgrade OS's more often than we need to update root servers), and it's not that much extra work to run a named on each Unix client. With DNS SEC, there are also end-to-end arguments why you'd want to run the named on your local machine. (Of course, if your PPP server is a hardware box that doesn't support name resolution, then you might have to use a central name server. But that's the only reason when I'd think it would make sense to do so. Oh well, I suspect this is more of a religious argument than anything else.) - Ted From owner-dns-security Thu Aug 7 16:35:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21329 for dns-security-outgoing; Thu, 7 Aug 1997 16:34:10 -0400 (EDT) Date: Thu, 7 Aug 1997 10:58:34 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <199708070303.XAA27608@dcl.MIT.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 6 Aug 1997, Theodore Y. Ts'o wrote: > Date: Wed, 6 Aug 1997 23:03:29 -0400 > From: Theodore Y. Ts'o > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com > Subject: Re: Changes in DNSSEC specification, Request For Discussion > > Date: Wed, 6 Aug 1997 18:14:47 -0400 (EDT) > From: "Donald E. Eastlake 3rd" > > I believe it will get a lot of initial deployment at high level ISP DNS > servers that get banged on by a lot of resovlers for a lot of names. While > net delays may account for most of the delay in answering any particular > request, there will be many requests being processed in parallel and I > believe that crypto calculations would be a serious problem. But I guess I > don't necessarily mind giving a boost to sales of DEC Alpha chips and > hardware crypto accelerators.... > > Err... am I missing something? > > Why would the DNS servers need to be doing any crypto calculations when > they're simply handing out SIG records? Sure, they'll have to do crypto > when they create all of the various SIG records, but that should be it. Creating the SIG RRs is likely an off line process so that does not make much difference. And really, really high level servers, like those authoritative for . and .com, will have caching and recursion turned off and basicly just need to check the SIGs when they load a new version of their zone(s). But what I was talking about were the chaching recursive servers maintained by most ISPs that their customers point their stub resolvers at. I just point the resolver on my machine to the caching rescursive DNS servers CyberCash maintains that also happen to serve up the cybercash.com domain. My son, who runs pothole.com, points his DNS servers at the DNS servers maintained by TerraNet, the ISP he gets service from, for his primary machine and to his primary machine from his other machines. > How often a DNS server gets banged-on by resolvers shouldn't make a > difference. These caching recursive servers will probably be the one doing almost all of the crypto. Stub resovlers on workstations and PCs and laptops will just use TSIG or transaction security to communicate securely with these crypto servers. This concentration of caching probably helps a lot today in net bandwidth (last I looked, DNS traffice was still about 5% of the packets) and latency by storing data closer to its users. Concentrating crypto will also save a lot of CPU cycles by not having every laptop have to crunch long chains of verification, even if it's looking up the same name as the adjacte laptop, from, say, foo.gnu.ai.mit.edu up through each zone to root and then down to, say, mumble.zeta.org.au. That could be seven El Gamal verifications. Hopfully the server will soon have cached verified KEYs for many high level zones, but it might still take a few verifications to be able to give an authenticated reply. And with, say, a few hundred or even a thousand web browsers surfing the net and feeding domain names to the server for resolution, the crypto load could be enormous. > So if using an El Gamal style signature is more expensive, that still > only affects how long it takes to (a) make the zone file, and (b) have > the resolver validate it. But that's not a problem which affects a > centralized server. > > - Ted 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 WARNING, on 4 Sep 1997, 1-508 will change to 1-978. From owner-dns-security Thu Aug 7 16:35:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21321 for dns-security-outgoing; Thu, 7 Aug 1997 16:34:06 -0400 (EDT) Date: Thu, 7 Aug 1997 12:34:11 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: NXT record proposed changes In-Reply-To: <3.0.1.32.19970806124211.00759a48@pop.hq.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 6 Aug 1997, Olafur Gudmundsson wrote: > Date: Wed, 06 Aug 1997 12:42:11 -0400 > From: Olafur Gudmundsson > To: "Donald E. Eastlake 3rd" > > ... > > I can go along with this. > > The specification should say that bit 0 set to 0 indicates standard NXT bit > map, bit 0==1 is reserved for future extension(s), where the other 7 bits > indicate the version number of the extension. This allows up to 127 > different extension mechanisms. > > I propose that the draft should say that NXT bit map is MUST be used if the > max type number is less than n (My suggestions for n are 128 or 240). > This gives us a breathing room for few years before extension mechanisms > need to be widely deployed. I think I like n = 128 (max = 127). > Comments please ? 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 WARNING, on 4 Sep 1997, 1-508 will change to 1-978. From owner-dns-security Thu Aug 7 17:36:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21726 for dns-security-outgoing; Thu, 7 Aug 1997 17:35:34 -0400 (EDT) Message-Id: <3.0.2.32.19970808024635.0097cd90@mail.communities.com> X-Sender: mccoy@mail.communities.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 08 Aug 1997 02:46:35 -0700 To: John Gilmore From: Jim McCoy Subject: Re: Global Name Spaces Cc: dns-security@tis.com In-Reply-To: <199708070124.SAA01869@toad.com> References: <3.0.2.32.19970807041533.00966c80@mail.communities.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk John wrote: >> Why exactly does boeing.com need to be unique? > >Jim, the design of the DNS requires it to be unique, or the DNS will >break. For a simple example, cacheing boeing.com RR's under the name >"boeing.com" will produce wrong answers for some requesters if the >name is not globally unique. DNS has no way to distinguish which >"boeing.com" you are asking about, if there were more than one. As it currently stands, yes. The way that a namespace directory can distinguish between entries which use the same name is by using a certificate or pubkey hash to distinguish between the two. The problem with the illusion provided by unique names in the existing DNS system is that to enforce uniqueness you compell those who did not get a particular name first to go with something vaguely similar. If my local DNS server finds several possible names for boeing.com perhaps it should ask me which one I want? If you want to know how to do this transparently to the application just ask... >For short-term future use on today's Internet, and certainly for the >DNSSEC effort, the rest of us must concentrate on improving the basic >DNS design that we're already blessed/cursed with. I agree. This originally started when I simply asked that solutions to secure the "root" of the DNS namespace not assume that everyone will use the same root. I did not particularly mean to go off on a rant, but I did want to point out that a few of the assumptions made here about how the internet should/will work in the future are not necessarily true... (the mobileIP stuff was something which started me initially thinking about this, but there are a lot of other reasons not to think so narrowly regarding the long-term effects of some design decisions.) jim From owner-dns-security Fri Aug 8 07:32:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA26339 for dns-security-outgoing; Fri, 8 Aug 1997 07:31:08 -0400 (EDT) Message-Id: <9708072120.AA29720@commanche.ca.boeing.com> To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: (Your message of Thu, 07 Aug 97 10:58:34 -0400.) Date: Thu, 07 Aug 97 14:20:05 -0700 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Donald Just a word of caution on planning for the resolvers to do "anything" new. We have reasonable luck getting new "named" implementations but I suspect that the vendors will more reluctant to change the resolver code. Hopefully we wouldn't have to touch 150,000+ resolvers with new code or configurations. Also just to confirm your thoughts, we deploy DNS caching on almost every "server" we have and many of our high end workstations, both to reduce load on the primary and secondary servers and to improve response on the servers. As you're probably aware, a workstation just doing listening to the net may do over a 1000 queries a day on a week- end. (number varies with listeners, logs, daemons, etc.) Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | Phone: 425-957-5325 | Bellevue, Washington, USA | | Email: terry.l.davis@boeing.com. | --------------- Thursday August 07,1997 02:18 PM PDT ------------- == As always, should the above be construed as representing BOEING, == == the COMPANY will dis-avow any knowledge of me or my actions. == From owner-dns-security Fri Aug 8 10:05:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27556 for dns-security-outgoing; Fri, 8 Aug 1997 10:04:16 -0400 (EDT) Date: Fri, 8 Aug 1997 10:07:19 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Cc: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <9708072120.AA29720@commanche.ca.boeing.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Ah, a message from the real boeing.com. While it would be better for your resolvers to use secure communications with your caching recursive servers, it would be a reasonable policy decision that your internal network is adequately secure that such a change is not urgent. And if you upgrade your servers to do DNSSEC on behalf of their client resolvers, you would gain most of the benefits of DNSSEC. Thanks, Donald On Thu, 7 Aug 1997, Terry L. Davis, Boeing Information & Support Services, Bellevue, WA wrote: > Date: Thu, 07 Aug 97 14:20:05 -0700 > From: Terry L. Davis, Boeing Information & Support Services, Bellevue, WA > > Donald > > Just a word of caution on planning for the resolvers to do "anything" > new. We have reasonable luck getting new "named" implementations but I > suspect that the vendors will more reluctant to change the resolver > code. Hopefully we wouldn't have to touch 150,000+ resolvers with > new code or configurations. > > Also just to confirm your thoughts, we deploy DNS caching on almost > every "server" we have and many of our high end workstations, both > to reduce load on the primary and secondary servers and to improve > response on the servers. As you're probably aware, a workstation just > doing listening to the net may do over a 1000 queries a day on a week- > end. (number varies with listeners, logs, daemons, etc.) > > Take care > > | Terry L. Davis, P.E. | Boeing Information & Support Services | > | Phone: 425-957-5325 | Bellevue, Washington, USA | > | Email: terry.l.davis@boeing.com. | > --------------- Thursday August 07,1997 02:18 PM PDT ------------- > == As always, should the above be construed as representing BOEING, == > == the COMPANY will dis-avow any knowledge of me or my actions. == ===================================================================== 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 WARNING, on 4 Sep 1997, 1-508 will change to 1-978. From owner-dns-security Fri Aug 8 10:48:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27898 for dns-security-outgoing; Fri, 8 Aug 1997 10:48:22 -0400 (EDT) X-Authentication-Warning: kgbvax.fv.com: uucp set sender to using -f Message-Id: <199708081452.KAA28474@mailrus.fv.com> X-Mailer: exmh version 1.6.9 8/22/96 To: dns-security@tis.com From: Steve Simmons Subject: Re: Changes in DNSSEC specification, Request For Discussion In-reply-to: Your message of "Thu, 07 Aug 1997 14:20:05 PDT." <9708072120.AA29720@commanche.ca.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 10:52:44 -0400 Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 07 Aug 1997 14:20:05 PDT, "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA"@ex.tis.com wrote: > Donald > > Just a word of caution on planning for the resolvers to do "anything" > new. We have reasonable luck getting new "named" implementations but I > suspect that the vendors will more reluctant to change the resolver > code. . . Agreed. The changes to DNS will get popularized the same way changes to sendmail have been -- improvements to security driven by enough folks getting bitten that everyone gets paranoid. We've started to see the first serious DNS fraud with items like the recent internic hijacking. I can think of some *really* interesting things you could do with DNS fraud. Someday real soon easy-to-use DNS defrauding tools will fall into the crackers toolkits, and a number of risks will move from theoretical to real. On that day, the drive to deploying secure DNS will accelerate sharply. Steve From owner-dns-security Sat Aug 9 21:39:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA07511 for dns-security-outgoing; Sat, 9 Aug 1997 21:36:17 -0400 (EDT) Message-Id: <199708100144.SAA13494@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: resolver upgrade strategy In-reply-to: Date: Sat, 09 Aug 1997 18:44:53 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk Let's move gently back toward reality here. VERY few sites are going to upgrade their resolvers manually. That involves replacing routines in the main system shared library, on most Unix/Linux machines. It's a lot more work, and a lot more dangerous, than installing a new named; if you screw it up, your system goes down hard and doesn't reboot any more. The way that 99% of the resolvers in the world will get upgraded is by their sysadmins installing new versions of the whole OS. That would only slow us down by the vendors' release cycle (about 1.5 years last time I looked), except for a software engineering problem. Due to increasingly arcane build procedures for the shared libraries on each Unix vendor's machines, most vendors can't just drop a new BIND into their source tree and have it upgrade their resolver. It requires human effort, which we will have to convince them to do. If the new resolver requires more configuration, that will also require vendor documentation and installation procedure changes. (I don't know what it takes to upgrade the resolvers in Windows TCP/IP stacks, but I bet it won't be a "drop-in" of BIND 8.x code.) The current proliferation of proposals on how to secure the data down to the resolver doesn't strike me as a good argument for anything but "wait and see which one wins". They all have drawbacks, whether it's manual configuration, or bignum operations, or whatever. (You already know that my prejudice is for burning quadrillions of increasingly cheap CPU cycles before asking an increasingly expensive human to configure something, so I won't mention that. ;-) John From owner-dns-security Tue Aug 12 18:40:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA29085 for dns-security-outgoing; Tue, 12 Aug 1997 18:36:28 -0400 (EDT) Date: Tue, 12 Aug 1997 18:39:20 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "Theodore Y. Ts'o" Cc: dns-security@tis.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-Reply-To: <199708071745.NAA27825@dcl.MIT.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 7 Aug 1997, Theodore Y. Ts'o wrote: > Ah, now I understand the original concern. > > I had thought people were worried about the top-level root servers, > which get banged on by a lot of people, but which don't have recursive > queries turned on.... > > I've actually never understood the appeal of running a centralized named > server for a site; it's not like the root servers change *that* often > (we tend to upgrade OS's more often than we need to update root > servers), and it's not that much extra work to run a named on each Unix > client. With DNS SEC, there are also end-to-end arguments why you'd > want to run the named on your local machine. There is a substantial savings in latency as it is to have a local server with a big cache. This will be grossly magnified with DNSSEC to the point where I fear that forcing smaller machines to chase down verfication chains and do all the crypto is very likely to cause people to turn off DNS security. I'm not saying which way is "right" but more and more of the world is in enclaves and places like MIT with thousands or tens of thousand of machines and no firewall are becoming increasingly unusual aberrations. The end-to-end argument only works for security if the ends are well administered and there are no organziation level policies. In most environments, the client machines are not well administered and there are organizational policies to enforce. 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 WARNING, on 4 Sep 1997, 1-508 will change to 1-978. From owner-dns-security Wed Aug 13 13:40:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05689 for dns-security-outgoing; Wed, 13 Aug 1997 13:38:29 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 13 Aug 1997 10:45:36 -0700 From: Jayakumar Ramalingam To: dns-security@tis.com Subject: Questions about chaining and secure aware resolvers Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-dns-security@ex.tis.com Precedence: bulk Could someone please clarify the following points? 1. Section 6.3 (Chaining through Zones) of RFC 2065 says that "Every authoritative secure zone server MUST also include the KEY RR for a super-one signed by the secure zone via a keyfile directive." So, a sub zone signs its super zone's KEY RR before inclusion. Is this interpretation right? In the TIS implementation, the sub zone does not seem to sign super zone's KEY RR. For a security aware resolver, starting from the sub zone, to move up the tree, it would need to get super zone's public key securely. How does this work? 2. How does an application, like ISAKMP trying to securely get a public key, know that the resolver it is using is security aware or not? Is it an implementational detail? When stub resolvers are not security aware, all the applications that are security conscious, need to do verification themselves. But then, even when stub resolvers are extended to do verification on behalf of applications, applications would be duplicating code and effort for verification. What am I missing here? Regards, jayakumar From owner-dns-security Wed Aug 13 15:21:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06294 for dns-security-outgoing; Wed, 13 Aug 1997 15:21:34 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Aug 1997 15:30:06 -0400 To: Jayakumar Ramalingam From: Edward Lewis Subject: Re: Questions about chaining and secure aware resolvers Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 1:45 PM -0400 8/13/97, Jayakumar Ramalingam wrote: >Could someone please clarify the following points? > >1. Section 6.3 (Chaining through Zones) of RFC 2065 says that "Every >authoritative secure zone server MUST also include the KEY RR for a >super-one signed by the secure zone via a keyfile directive." So, a sub zone >signs its super zone's KEY RR before inclusion. Is this interpretation >right? Seems like it - but what do you mean by "inclusion?" I haven't decided how to implement this. I suppose a zone could treat the parent KEY set and the zone's (child) SIG as hints at loading - but then you'd have to figure out how not to lose the child-generated SIG when the parent's KEYs are learned from the parent. (Imagine the parent storing its KEY set with the signatures of its parent and all its children. Imagine this for .COM. - the KEY for .COM and the signatures would always result in a truncated message.) >In the TIS implementation, the sub zone does not seem to sign super zone's >KEY RR. For a security aware resolver, starting from the sub zone, to move >up the tree, it would need to get super zone's public key securely. How does >this work? We've assumed (in our test cases to date) that the root keys are known, not some lower key, by the entity doing the resolution. We haven't yet tested any way of being able to resolve up the DNS tree. This issue is being discussed by folks at the IETF this week. (I am not at the meetings.) The issue is one of a few that we've been hammering away at in the past month. >2. How does an application, like ISAKMP trying to securely get a public key, >know that the resolver it is using is security aware or not? Is it an >implementational detail? This depends on how the application interacts with DNS. At the OS/POSIX API level, there is no current mechanism for returning the security status of the data (e.g., gethostbyname()). This may/will change - when someone (i.e., not me in the foreseeable future) does this. If the application uses the res_ library routines, res_send is a basic building block. The application gets the "as is" response, it is up to the application to interpret the security of the response by reading the response. I've spent the better part of 4 months (counting just since April) on doing an add-on to the res_ libraries to do this. A while back I posted to the list a matrix of return codes - I have since updated the matrix - as part of the output of the effort. (In the four months I had to write a significant amount of code to be able to read the new version of the secure resolv.conf and an IO manager for the query/response exchange. This has taken quite some time.) I am writing a routine "res_squery()" which will return an answer with the security status as part of the structure in the API. I'm trying to design this to be as easy to use for security ignorant uses as security vigilant uses. That's not easy. I don't see res_squery() being an easy drop-in replacement for a lot of the res_ uses today. Its more of an experiment in interpreting the security hints we're getting. It may have a more sigificant impact on the way in which the name servers do the resolution than the way in which end-hosts (i.e., personal computers) do it. >When stub resolvers are not security aware, all the applications that are >security conscious, need to do verification themselves. But then, even when >stub resolvers are extended to do verification on behalf of applications, >applications would be duplicating code and effort for verification. What am >I missing here? You are not missing anything. You are hitting the hammer right on the thumb. Applications using an API that is security ignorant need to do the security work, even if it has been done. When the API is swapped out to one that is security aware, the application will be able to know if it needs to do the resolution work (i.e., the API says the answer is unchecked) or if the API trusts the data. (The it is up to the application to trust the API to speak the truth.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "What's it say about me that you'd think I'd fall for that" James McMurtry - "Where'd You Hide the Body" (1995) Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Thu Aug 14 05:52:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA10630 for dns-security-outgoing; Thu, 14 Aug 1997 05:49:34 -0400 (EDT) Date: Thu, 14 Aug 1997 05:52:30 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Securing the root, in real life In-Reply-To: <199708020138.SAA25476@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Fri, 1 Aug 1997, John Gilmore wrote: > Date: Fri, 01 Aug 1997 18:38:48 -0700 > From: John Gilmore > > ... > > Clearly BIND and secure resolvers will have to come with some public > key(s) embedded in it for validating the root zone, just as today it > comes with a root.cache file so that the root servers can be located. > The alternative is that each sysadmin who installs a machine has to > manually configure at least one public key. I don't think people who > ship OS's and network appliances are going to ship products that way. I think it will be quite common within organizations to configure the internal resolvers to use a set of border caching servers and to configure these resolvers with that organization's DNS public key. > It would be a bad idea, though to ship the public key for the "." zone > in OS releases and BIND distributions. If the key ever needed to be > changed (e.g. because the private key had been lost or stolen), it > *would* require a manual administrative act at every DNS server or > secure resolver. This would throw the net into chaos, with many > machines unable to communicate (even if the manufacturer told the user > how to change the root public key, the user would probably lose the > instructions). It would mean that the act of changing the root key > might well be more disruptive to the net than letting a root-key thief > impersonate people at will. Not a pleasant thought. Most machines (probably in excess of 90%) which just have stub resolvers which point to some caching server. (Over time their communications with such servers, currently insecure, will become secured by DNSSEC transaction signatures and/or TSIG.) Of the caching resolvers, probably in excess of 90% will just point to a higher-level/enclave-border caching server and be configured with the key of the enclave zone. So, while it's still a hell of a lot of machines, I think that in the long run less than 1% of the resolvers in the world will be configured with the root public key. > Much of the design for securing the root belongs in a Best Current > Practice, but we need to look at it for the DNSSEC specs as well. If > we decide it's wise, the software will have to implement a > cryptovalidation algorithm that permits some key other than the root > key to be the "root" of the validation hierarchy. We've been assuming > that the cryptovalidation algorithm would terminate with the root key. I think that in fulfilling the task of securing the existing DNS system, we can probably trust IANA to take proper steps to implement signing root and securing the root private key. > The best solution I've come up with is to have a "proto-root" or > "root-signer" key embedded in the software, which could be used to > validate a signature on the root key. This would permit the root key > to be changed. I don't object too strongly to this but you have to avoid an infinite regress. People frequently get into these weird modes of developing very complex systems to try to account for all possible failures in key security, systems whose very complexity probably makes failures more likely. > The root private key needs to be used frequently, to sign the root > zone with a short validity period so that RR's can be canceled. What is very frequently? I think that under normal circumstances, a new and newly signed root zone would need not happen more frequently than once a week. Over five years, that's only 260 sessions of use of the private key. If this is all done on a non-networked machine, which could be a pretty dinky machine since root is not that big a zone and it is not that much work to sign it, how much danger is there? Just why would a root RR have to be cancelled quickly? Seems to me like changes in servers for TLDs shouldn't happen that often. And if some emergency does come up once a year, it doesn't add much to the number of uses. > (Active attackers can replay earlier SIG records if they have long > validity periods, even if those records are no longer distributed by > the zone itself. This results from not actively checking a CRL on > every signature - which I think is a good design decision.) The > result is that the root key has to be relatively accessible, and thus > relatively stealable. > > However, the proto-root key only needs to be used when the root key > changes. A set of signatures covering the next ten years can be > generated with it (to be gradually released over time), then it can go > into a vault, under vacuum seal and alarms, and not be withdrawn again > for ten years, or until a root key compromise is detected. Ten years strikes me as a time period over which we would have migrated to DNS-2 or some totally new way or handling the root, etc. It would probably be about as good to put these presigned things in the vault and destroy the root private key... :-) (just kidding) > ... > > A disadvantage of the proto-root proposal is that a procedure which > only happens every ten years is likely to be forgotten or fubar when > it is next needed. The hardware and software needed to use it might > also be unobtainable (have you tried to read an 800 BPI magtape > recently?). Even a once-a-year procedure would require some (there are probably good reasons why NSA is so into punched paper tape) > diligence. For example, the root's owner could always ensure that > they have three years' worth of proto-root signatures for the root key > in hand. Then if, at the minus-three-years point when they go to make > more, the proto-root key is discovered to be unavailable, we'd have > three years to propagate new resolver software (or reconfigure old > software) to include a new proto-root key. The operational section which is in RFC 2065 and I have removed to split out into a separate document says maximum key lifetime of 4 yaears with 1 year being a reasonable limit most of the time. > (The proto-root secret key could be stored by N-of-M secret-sharing, > but there is no standard software for secret-sharing. Such software > would have to be written and maintained, for once-a-year use. It > would of course be likely to be buggy. And the programmer who debugs > that software with live data -- the way it would fail -- would get to > see the proto-root private key, which no human should ever see.) Much as I hate to mention a specific commercial product, it is my impression that the BBN SafeKeeper does what you want, at least in terms of generation public keys, doing N of M key sharing, being a physically secure box, etc. It is what the IPRA, SET, etc. use. I suppose it might need some mods to do DNS sigs... > I could also see pluses and minuses of a design that distributed N > different alternative root keys or root-signer keys in BIND. Someone > else care to explore this option? > > Comments, please. I view this working group's charter as to secure things more or less as they are in DNS. I'd actually be reasonably entusiastic about working on a "root zone synchronization" protocol where they would not be any single point of control for the root, but I think that should be a separate follow on effort. > John 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 WARNING, on 4 Sep 1997, +1-508 will change to +1-978. From owner-dns-security Thu Aug 14 10:59:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA12588 for dns-security-outgoing; Thu, 14 Aug 1997 10:58:40 -0400 (EDT) Message-Id: <199708141507.IAA02893@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 14 Aug 97 08:07:01 -0700 To: "Donald E. Eastlake 3rd" Subject: Re: Securing the root, in real life cc: dns-security@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: X-No-Archive: : yes Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Thu, 14 Aug 1997 05:52:30 -0400 (EDT) From: "Donald E. Eastlake 3rd" > On Fri, 1 Aug 1997, John Gilmore wrote: > > > Date: Fri, 01 Aug 1997 18:38:48 -0700 > > From: John Gilmore > [snip] Because TSIG is based on a shared symmetric key then "inside" transactions are not secure from inside threats since the key is compromisable from any one of the inside hosts. It seems to me TSIG simply moves the problem from the Internet domain to the intranet domain and opens the intranet to internal attack, probably not really fixing anything. In a large corporate network or a university environment for example, does TSIG really make sense? If TSIG does not make sense in those environments then how are they to be secured? If the answer is each resolver works the same, then we have the original problem again: key management. -dpg From owner-dns-security Fri Aug 15 01:41:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA17671 for dns-security-outgoing; Fri, 15 Aug 1997 01:40:12 -0400 (EDT) Date: Thu, 14 Aug 1997 22:49:08 -0700 (PDT) Message-Id: <199708150549.WAA10254@servo.qualcomm.com> From: Phil Karn To: tytso@mit.edu CC: gnu@toad.com, dns-security@tis.com In-reply-to: <199708071745.NAA27825@dcl.MIT.EDU> (tytso@mit.edu) Subject: Re: Changes in DNSSEC specification, Request For Discussion Sender: owner-dns-security@ex.tis.com Precedence: bulk >I've actually never understood the appeal of running a centralized named >server for a site; it's not like the root servers change *that* often >(we tend to upgrade OS's more often than we need to update root >servers), and it's not that much extra work to run a named on each Unix >client. With DNS SEC, there are also end-to-end arguments why you'd Maybe it's just the versions of BIND that I've been using, but I have found that running a full named on each of my machines tends to generate a lot of superfluous network traffic, especially to the root servers. Ordinarily this isn't a big deal, but I do occasionally use some pretty slow networks where this *is* a big deal -- like CDPD. So I generally configure my local name servers into a loose hierarchy of caching forwarders, with fallback to full local resolution in case a forwarder dies. This seems to work well. Phil From owner-dns-security Fri Aug 15 11:04:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA20644 for dns-security-outgoing; Fri, 15 Aug 1997 11:01:46 -0400 (EDT) Message-Id: <3.0.3.32.19970815081528.006f3efc@200.180.159.10> X-Sender: wyu@200.180.159.10 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 15 Aug 1997 08:15:28 -0700 To: dns-security@tis.com From: Wayne Yu Subject: How come I can never get off this list? Cc: dns-security@tis.com In-Reply-To: <199708150549.WAA10254@servo.qualcomm.com> References: <199708071745.NAA27825@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk I tried and tried and still getting stuff from this list. At 10:49 PM 8/14/97 -0700, Phil Karn wrote: >>I've actually never understood the appeal of running a centralized named >>server for a site; it's not like the root servers change *that* often >>(we tend to upgrade OS's more often than we need to update root >>servers), and it's not that much extra work to run a named on each Unix >>client. With DNS SEC, there are also end-to-end arguments why you'd > >Maybe it's just the versions of BIND that I've been using, but I have >found that running a full named on each of my machines tends to >generate a lot of superfluous network traffic, especially to the root >servers. Ordinarily this isn't a big deal, but I do occasionally use >some pretty slow networks where this *is* a big deal -- like CDPD. > >So I generally configure my local name servers into a loose hierarchy >of caching forwarders, with fallback to full local resolution in case >a forwarder dies. This seems to work well. > >Phil > > > > > From owner-dns-security Fri Aug 15 15:20:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21988 for dns-security-outgoing; Fri, 15 Aug 1997 15:20:15 -0400 (EDT) Message-ID: <640796DB4262D0118D3300805FD4EFCF0249EE61@RED-32-MSG.dns.microsoft.com> From: Stuart Kwan To: "'dns-security@tis.com'" Subject: secure dynamic update and key exchange Date: Fri, 15 Aug 1997 12:28:54 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-dns-security@ex.tis.com Precedence: bulk I solicit your input on the direction of secure dynamic update. Microsoft is adopting DNS as our favored name service, and deprecating NetBIOS. Dynamic DNS figures prominently. Security is necessary, which brings us to RFC 2137, and in turn RFC 2065. Before we embrace RFC 2065, we have some concerns: - The lack of a standard key management framework. This is a hard problem since 2065 does not use an existing certificate format. - Complexity, performance, and maturity. Deployment experience in this area is limited. A large amount of code must be written and tested for each DNS server implementation. - Recent suggested changes to the specification. The spec may not be ready for full-steam deployment at this time. I believe that 2065 is the way to go in the long run. The short term alternative for dynamic update is TSIG. However, TSIG lacks (by design) a defined secret distribution mechanism. For the number of clients I must manage in a typical install, "sneaker-net" is not a viable mechanism. However, we are now presented with the opportunity to tackle both the TSIG secret distribution problem and the 2065 key management problem at the same time. I propose using the Generic Security Service API as specified in RFC 2078. Clients would use GSS API to create a secure channel and exchange or register keys with servers. The registration mechanism would be based on dynamic update semantics, thus GSS API could also be used to secure dynamic updates in general. A few advantages: - The caller is abstracted from the security implementation. - The system is modular. Security packages can be added and removed. Client and server negotiate acceptable packages on the fly. - GSS API is available on many platforms. Are there any authors out there who would like to collaborate with me on defining this mechanism? We need to solve the key management problem to make secure dynamic update a practical reality, and if we don't solve it in a standard way then we risk future incompatibility. Cheers, - Stuart Kwan Microsoft Corp. From owner-dns-security Wed Aug 20 10:08:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00271 for dns-security-outgoing; Wed, 20 Aug 1997 10:04:26 -0400 (EDT) Date: Wed, 20 Aug 1997 10:07:23 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: TSIG (was Re: Securing the root, in real life) In-Reply-To: <199708141507.IAA02893@imo.plaintalk.bellevue.wa.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I view TSIG as an efficiency measure. If you don't like it, you can use the DNSSEC public key signatures on requests and transactions and pay the added price in computer cycles. In cases of a strong bilateral connection, such as between a DHCP server giving out IP addresses and the primary DNS server for the corresponding in-addr part of the DNS tree, both of which are very likely under common management, TSIG makes a lot of sense to me. Donald On Thu, 14 Aug 1997, Dennis Glatting wrote: > Date: Thu, 14 Aug 97 08:07:01 -0700 > From: Dennis Glatting > > Date: Thu, 14 Aug 1997 05:52:30 -0400 (EDT) > From: "Donald E. Eastlake 3rd" > > > On Fri, 1 Aug 1997, John Gilmore wrote: > > > > > Date: Fri, 01 Aug 1997 18:38:48 -0700 > > > From: John Gilmore > > [snip] > > Because TSIG is based on a shared symmetric key then "inside" > transactions are not secure from inside threats since the key > is compromisable from any one of the inside hosts. It seems to me > TSIG simply moves the problem from the Internet domain to the > intranet domain and opens the intranet to internal attack, > probably not really fixing anything. In a large corporate > network or a university environment for example, does TSIG > really make sense? If TSIG does not make sense in those > environments then how are they to be secured? If the answer is > each resolver works the same, then we have the original > problem again: key management. > > -dpg ===================================================================== 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 WARNING, on 4 Sep 1997, +1-508 will change to +1-978. From owner-dns-security Thu Aug 21 02:38:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA05880 for dns-security-outgoing; Thu, 21 Aug 1997 02:37:29 -0400 (EDT) To: dns-security@tis.com Subject: Re: How does DNSSEC handle multiple registrars in a domain? In-Reply-To: Message from Kent Crispin dated "Wed, 06 Aug 97 15:26:46 PDT" <19970806152646.02697@bywater.songbird.com> References: <19970806152646.02697@bywater.songbird.com> <3.0.1.32.19970805002746.006fb50c@pop.hq.tis.com> Date: Thu, 21 Aug 1997 02:46:19 -0400 From: Rob Austein Message-ID: <9708210246.aa22633@rurha-pente.epilogue.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk It's not quite true that the DNSSEC WG has no control over the gTLD-MoU design. No direct control, but since there are at least two POC members who have at least some clue about what DNSSEC is, the DNSSEC WG's recommendations carry more weight than you might think. The interesting questions, to me, are: a) Should the CORE use DNSSEC, at least on a per-registry level? b) Should the CORE use DNSSEC at a per-registrar level, so that signed RRs can be traced back to a particular registrar? c) If the answer to (b) is "yes", is the potentially huge number of zone keys going to be a problem, eg when the number of zone keys exceeds the number of octets that we can put in a UDP packet? d) If the answer to (c) is "yes", is there a workable techno-fix? Would it help to use TCP when querying for the gTLD zone keys? Is there some useful way that we could name keys within the zone so that we don't have to keep them all in one huge bucket at the root of the zone? Is there some small modification to DNSSEC that we could make that would solve this problem? e) Should the POC try to make use of DNSSEC mandatory for CORE registries? (a) seems like a no-brainer. (b) seems desirable, if we can find acceptable answers to (c) and (d). (e) is at least partly a political question (and thus out of scope for this list), but recommendations on technical grounds still count here. --Rob From owner-dns-security Fri Aug 22 10:40:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16538 for dns-security-outgoing; Fri, 22 Aug 1997 10:37:06 -0400 (EDT) Date: Fri, 22 Aug 1997 10:40:11 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Stuart Kwan Cc: "'dns-security@tis.com'" Subject: Re: secure dynamic update and key exchange In-Reply-To: <640796DB4262D0118D3300805FD4EFCF0249EE61@RED-32-MSG.dns.microsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Fri, 15 Aug 1997, Stuart Kwan wrote: > Date: Fri, 15 Aug 1997 12:28:54 -0700 > From: Stuart Kwan > To: "'dns-security@tis.com'" > > I solicit your input on the direction of secure dynamic update. > Microsoft is adopting DNS as our favored name service, and deprecating > NetBIOS. Dynamic DNS figures prominently. Security is necessary, which > brings us to RFC 2137, and in turn RFC 2065. Before we embrace RFC > 2065, we have some concerns: > - The lack of a standard key management framework. This is a hard > problem since 2065 does not use an existing certificate format. > - Complexity, performance, and maturity. Deployment experience in this > area is limited. A large amount of code must be written and tested for > each DNS server implementation. > - Recent suggested changes to the specification. The spec may not be > ready for full-steam deployment at this time. On your three points: (1) There have been informal discussions about adding explicit support for a variety of traditional certificate formats, including X.509, to DNSSEC. A draft or two fill probably be out shorlty. (2) On "complexity, performance, and maturity", are not all distributed hierarchial/web security schemes somewhat complex? Is there some reason why performance should be significantly worse than any other scheme using the same algorithms and key sizes? As for maturity, if you want secure dynamic DNS update, some new code seems needed... (3) Based on feedback from John Gilmore and TIS on this list and elsewhere, I am backing out many of the minor changes that are in draft-ietf-dnssec-secext2-00.txt and plan to post a -01 draft later today. Your comments on what changes should/should-not be made would be welcome. I believe the spec will be ready for full-steam deployment very soon. > I believe that 2065 is the way to go in the long run. The short term > alternative for dynamic update is TSIG. However, TSIG lacks (by design) > a defined secret distribution mechanism. For the number of clients I > must manage in a typical install, "sneaker-net" is not a viable > mechanism. However, we are now presented with the opportunity to tackle > both the TSIG secret distribution problem and the 2065 key management > problem at the same time. As you say, the TSIG draft is deliberately limited to avoid trying to bite off too much at once. It is neutral as to how the keys are distributed. > I propose using the Generic Security Service API as specified in RFC > 2078. Clients would use GSS API to create a secure channel and exchange > or register keys with servers. The registration mechanism would be > based on dynamic update semantics, thus GSS API could also be used to > secure dynamic updates in general. A few advantages: > - The caller is abstracted from the security implementation. > - The system is modular. Security packages can be added and removed. > Client and server negotiate acceptable packages on the fly. > - GSS API is available on many platforms. There has been some informal discussion of a means for distributing symetric keys for use in TSIG within DNS. This would, I believe, solve the efficient secure dynamic update questions. While GSS API may be available on "many" platforms, it seems like what we need is something available on exaclty the set of platforms that have DNS resolvers and servers. These platforms are guaranteed to have DNS code on them so a solution within DNS is preferable. I'd be interested in a more explicit statement on exactly what you see as the "2065 key management problem". From what you say, it shoulds like you are worried about getting initial public keys into zone files or something. I don't really see how, for example, X.509 certificates would help much. It just pushes the questions of authorization off one level. You might locally trust some X.509 root like verisign or microsoft more than the DNS root but that can only be a local policy and it seems to me that for the general Internet wide question, throwing a whole additional authorization layer that does not naturally use domain names on top of the DNS authentication system in RFC 2065 just adds complexity and confusion. > ... > Cheers, > - Stuart Kwan > Microsoft Corp. 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 WARNING, on 4 Sep 1997, +1-508 will change to +1-978. From owner-dns-security Sat Aug 23 17:02:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24925 for dns-security-outgoing; Sat, 23 Aug 1997 16:59:44 -0400 (EDT) Message-Id: <199708232107.OAA11074@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Donald E. Eastlake 3rd" cc: Stuart Kwan , "'dns-security@tis.com'" , gnu@toad.com Subject: Re: secure dynamic update and key exchange In-reply-to: Date: Sat, 23 Aug 1997 14:07:18 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > > - The lack of a standard key management framework. This is a hard > > problem since 2065 does not use an existing certificate format. There isn't a standard certification hierarchy of any other kind, either. The DNSSEC one at least has the strong advantage that it directly follows the DNS hierarchy. It also doesn't require showing identification, getting anyone's approval, or paying a fee. People can self-publish their keys, and they don't *need* a third-party certification hierarchy. These all suggest that it will catch on quickly, once the code is available for production use. It's not clear why a cert hierarchy is needed for dynamic updates, anyway. The DNS server being updated will be authoritative for the zone being updated, so it will know, a priori, its public keys. The client doing the update will have to know the private key that matches. What more is needed? Why check with anyone else? > > - Complexity, performance, and maturity. Deployment experience in this > > area is limited. A large amount of code must be written and tested for > > each DNS server implementation. True. I actually expect more problems from the administration (rollout) than I do from the code. This would be true of all cert hierarchies, though; there appear to be few or none in serious use. I spoke with someone from NSA last week, who said NSA had never deployed a hierarchical public-key certification system until two or three years ago (MISSI). All of their previous systems had two levels: root, and all the users. None had more than a few hundred thousand users (e.g. STU-III). Apparently nobody has ever done this before. We're breaking new ground; of course lessons will be learned. Would you like to be part of that learning, or would you rather wait til it's shaken out and adopt it later? Your choice. The Internet was built by intelligent experimenting. Microsoft claims to want to be an integral part of Internet evolution (if not to subsume it totally). This is how it gets done. > > - Recent suggested changes to the specification. The spec may not be > > ready for full-steam deployment at this time. Don, the author, has realized the folly of making arbitrary changes at this point. We're working out a minimal set of changes now, for publication soon. If you started coding from RFC 2065, you wouldn't be wasting your time at all. > > I propose using the Generic Security Service API as specified in RFC > > 2078. Clients would use GSS API to create a secure channel and exchange GSS API looks to me like an attempt to "genericize" Kerberos. But it never caught on. (And I say that from the perspective of Kerberos product manager at my last company.) John Gilmore From owner-dns-security Mon Aug 25 01:19:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03038 for dns-security-outgoing; Mon, 25 Aug 1997 01:14:36 -0400 (EDT) Date: Mon, 25 Aug 1997 01:17:41 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Cc: "Donald E. Eastlake" Subject: draft-ietf-dnssec-secext2-01.txt Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk A new draft of the second version of the main DNS security document has been sent to internet-drafts and is available at . This is significantly closer to RFC 2065 that the -secext-00.txt draft was. It has no need for any new RR types and any existing KEY RR created under RFC 2065 should be fine under the new draft. It has a new section 6.3.1 concerning secure resolution and a new Appendix C giving how to calculate key footprints/tags for algorithms other than 1. It may be possible to target this revised draft at Draft Standard. 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 WARNING, on 4 Sep 1997, +1-508 will change to +1-978. From owner-dns-security Tue Aug 26 10:12:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14509 for dns-security-outgoing; Tue, 26 Aug 1997 10:07:49 -0400 (EDT) To: IETF-Announce@ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-01.txt Date: Tue, 26 Aug 1997 10:02:18 -0400 Message-ID: <9708261002.aa06323@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-01.txt Pages : 48 Date : 1997-08-25 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication 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 also be provided even through non-security aware DNS servers in many cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. 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 and requests. This document incorporates feedback from implementors and potential users to RFC 2065. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu 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-secext2-01.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. 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: <19970825171850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825171850.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Aug 27 07:39:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21703 for dns-security-outgoing; Wed, 27 Aug 1997 07:36:05 -0400 (EDT) Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-01.txt Date: Tue, 26 Aug 1997 10:02:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708261002.aa06323@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-01.txt Pages : 48 Date : 1997-08-25 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication 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 also be provided even through non-security aware DNS servers in many cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. 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 and requests. This document incorporates feedback from implementors and potential users to RFC 2065. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu 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-secext2-01.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. 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: <19970825171850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825171850.I-D@ietf.org> --OtherAccess-- --NextPart--