From owner-dns-security Thu Jul 16 14:03:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23015 for dns-security-outgoing; Thu, 16 Jul 1998 13:59:53 -0400 (EDT) Date: Thu, 16 Jul 1998 11:02:01 -0700 (PDT) From: Gene Tsudik Message-Id: <199807161802.LAA22566@pollux.usc.edu> To: dns-security@tis.com Subject: ACM CCCS'98: Preliminary Program and Call for Participation Sender: owner-dns-security@ex.tis.com Precedence: bulk Subject: ACM CCCS'98: Preliminary Program and Call for Participation Preliminary Program Fifth ACM Conference on Computer and Communications Security San Francisco, California November 2-5, 1998 Sponsored by ACM SIGSAC For more information visit http://www.research.att.com/~reiter/ccs5 Launched in 1993, ACM CCCS is the ACM's flagship security conference. CCCS covers a wide range of topics in computer/information security and offers a technical as well as a tutorial program. Presentation topics are diverse, addressing state-of-the-art results of both practical and theoretical nature (and everything in between). ================================= DAY 0 =================================== Monday, November 2, 1998: Tutorials Core Topics Emerging Topics 9:00-12:30 Cryptography: Theory and Programming Languages and Security Applications Martin Abadi (DEC Systems Research Dan Boneh (Stanford Center, USA) and George Necula University, USA) (Carnegie Mellon University, USA) 12:30-13:30 Lunch 13:30-17:00 To Be Determined Authentication Protocol Verification and Analysis Jon Millen (SRI International, USA) ================================= DAY 1 =================================== Tuesday, November 3, 1998: Technical sessions 9:00-10:00 Keynote address Risks and challenges in computer-communication infrastructures Peter G. Neumann (SRI International, USA) 10:00-10:30 Break 10:30-12:00 Group key management Communication complexity of group key distribution Klaus Becker (R^3 Security Engineering, Switzerland) and Uta Wille (IBM Zurich Research Laboratory, Switzerland) Key management for encrypted broadcast Avishai Wool (Bell Labs, USA) Authenticated group key agreement and related protocols Giuseppe Ateniese (USC Information Sciences Institute, USA), Michael Steiner (IBM Zurich Research Laboratory, Switzerland), and Gene Tsudik (USC Information Sciences Institute, USA) 12:00-13:30 Lunch 13:30-15:30 Anonymity The design, implementation and operation of an email pseudonym server David Mazie`res and M. Frans Kaashoek (Massachusetts Institute of Technology, USA) Panel: Anonymity on the Internet Moderator: Paul Syverson (Naval Research Lab, USA) 15:30-16:00 Break 16:00-17:00 Mobile code security History-based access-control for mobile code Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of California, Santa Barbara, USA) A specification of Java loading and bytecode verification Allen Goldberg (Kestrel Institute, USA) ================================= DAY 2 =================================== Wednesday, November 4, 1998: Technical sessions 9:00-10:30 Cryptography A new public key cryptosystem based on higher residues David Naccache (Gemplus, France) and Jacques Stern (Ecole Normale Superieure, France) An efficient non-interactive statistical zero-knowledge proof system for quasi-safe prime products Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele Micciancio (Massachusetts Institute of Technology, USA), and Tal Rabin (IBM T.J. Watson Research Center, USA) Communication-efficient anonymous group identification Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni Di Crescenzo (University of California, San Diego, USA) 10:30-11:00 Break 11:00-12:00 Invited talk The development of public key cryptography Martin Hellman 12:00-13:30 Lunch 13:30-15:00 Systems A security architecture for computational grids Ian Foster (Argonne National Laboratory, USA), Carl Kesselman, Gene Tsudik (USC Information Sciences Institute, USA), and Steven Tuecke (Argonne National Laboratory, USA) Design of a high-performance ATM firewall Jun Xu and Mukesh Singhal (Ohio State University, USA) A practical secure physical random bit generator Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs, USA) and Ari Juels (RSA Labs, USA) 15:00-15:30 Break 15:30-16:30 Invited talk Trust in cyberspace? A research roadmap Fred Schneider (Cornell University, USA) ================================= DAY 3 =================================== Thursday, November 5, 1998: Technical sessions 9:00-10:30 Protocol design and analysis A probabilistic poly-time framework for protocol analysis Pat Lincoln (SRI International, USA), John Mitchell, Mark Mitchell (Stanford University, USA), and Andre Scedrov (University of Pennsylvania, USA) On using public-key cryptography in password protocols Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo Krawczyk (Technion, Israel) Cryptanalysis of Microsoft's point-to-point tunneling protocol Bruce Schneier (Counterpane Systems, USA) 10:30-11:00 Break 11:00-12:00 System monitoring How to prove where you are Eran Gabber and Avishai Wool (Bell Labs, USA) Temporal sequence learning and data reduction for anomaly detection Terran Lane and Carla E. Brodley (Purdue University, USA) ================== Worst paper award and author lampooning =================== Steering committee chair: Ravi Sandhu, George Mason University General chair: Li Gong, JavaSoft Program chair: Mike Reiter AT&T Labs, Room A269, 180 Park Avenue Florham Park, NJ 07932-0971 USA phone: +973-360-8349 Awards chair: Jacques Stern, ENS/DMI Publication chair: Stuart Stubblebine, AT&T Labs Publicity chair: Gene Tsudik, USC ISI Program committee: Martin Abadi, DEC SRC David Naccache, Gemplus Bill Cheswick, Lucent/Bell Labs Hilarie Orman, DARPA/ITO Carl Ellison, Cybercash Avi Rubin, AT&T Labs--Research Ed Felten, Princeton University Pierangela Samarati, Universita di Milano Paul Karger, IBM T.J. Watson Gene Tsudik, USC ISI Steve Kent, BBN Corporation Paul Van Oorschot, Entrust Technologies Ueli Maurer, ETH Zurich Bennet Yee, UCSD Cathy Meadows, Naval Res. Lab Moti Yung, CertCo For more information, visit http://www.research.att.com/~reiter/ccs5 From owner-dns-security Thu Jul 16 14:03:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23018 for dns-security-outgoing; Thu, 16 Jul 1998 13:59:54 -0400 (EDT) Date: Thu, 16 Jul 1998 11:02:01 -0700 (PDT) From: Gene Tsudik Message-Id: <199807161802.LAA22566@pollux.usc.edu> To: dns-security@tis.com Subject: ACM CCCS'98: Preliminary Program and Call for Participation Sender: owner-dns-security@ex.tis.com Precedence: bulk Subject: ACM CCCS'98: Preliminary Program and Call for Participation Preliminary Program Fifth ACM Conference on Computer and Communications Security San Francisco, California November 2-5, 1998 Sponsored by ACM SIGSAC For more information visit http://www.research.att.com/~reiter/ccs5 Launched in 1993, ACM CCCS is the ACM's flagship security conference. CCCS covers a wide range of topics in computer/information security and offers a technical as well as a tutorial program. Presentation topics are diverse, addressing state-of-the-art results of both practical and theoretical nature (and everything in between). ================================= DAY 0 =================================== Monday, November 2, 1998: Tutorials Core Topics Emerging Topics 9:00-12:30 Cryptography: Theory and Programming Languages and Security Applications Martin Abadi (DEC Systems Research Dan Boneh (Stanford Center, USA) and George Necula University, USA) (Carnegie Mellon University, USA) 12:30-13:30 Lunch 13:30-17:00 To Be Determined Authentication Protocol Verification and Analysis Jon Millen (SRI International, USA) ================================= DAY 1 =================================== Tuesday, November 3, 1998: Technical sessions 9:00-10:00 Keynote address Risks and challenges in computer-communication infrastructures Peter G. Neumann (SRI International, USA) 10:00-10:30 Break 10:30-12:00 Group key management Communication complexity of group key distribution Klaus Becker (R^3 Security Engineering, Switzerland) and Uta Wille (IBM Zurich Research Laboratory, Switzerland) Key management for encrypted broadcast Avishai Wool (Bell Labs, USA) Authenticated group key agreement and related protocols Giuseppe Ateniese (USC Information Sciences Institute, USA), Michael Steiner (IBM Zurich Research Laboratory, Switzerland), and Gene Tsudik (USC Information Sciences Institute, USA) 12:00-13:30 Lunch 13:30-15:30 Anonymity The design, implementation and operation of an email pseudonym server David Mazie`res and M. Frans Kaashoek (Massachusetts Institute of Technology, USA) Panel: Anonymity on the Internet Moderator: Paul Syverson (Naval Research Lab, USA) 15:30-16:00 Break 16:00-17:00 Mobile code security History-based access-control for mobile code Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of California, Santa Barbara, USA) A specification of Java loading and bytecode verification Allen Goldberg (Kestrel Institute, USA) ================================= DAY 2 =================================== Wednesday, November 4, 1998: Technical sessions 9:00-10:30 Cryptography A new public key cryptosystem based on higher residues David Naccache (Gemplus, France) and Jacques Stern (Ecole Normale Superieure, France) An efficient non-interactive statistical zero-knowledge proof system for quasi-safe prime products Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele Micciancio (Massachusetts Institute of Technology, USA), and Tal Rabin (IBM T.J. Watson Research Center, USA) Communication-efficient anonymous group identification Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni Di Crescenzo (University of California, San Diego, USA) 10:30-11:00 Break 11:00-12:00 Invited talk The development of public key cryptography Martin Hellman 12:00-13:30 Lunch 13:30-15:00 Systems A security architecture for computational grids Ian Foster (Argonne National Laboratory, USA), Carl Kesselman, Gene Tsudik (USC Information Sciences Institute, USA), and Steven Tuecke (Argonne National Laboratory, USA) Design of a high-performance ATM firewall Jun Xu and Mukesh Singhal (Ohio State University, USA) A practical secure physical random bit generator Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs, USA) and Ari Juels (RSA Labs, USA) 15:00-15:30 Break 15:30-16:30 Invited talk Trust in cyberspace? A research roadmap Fred Schneider (Cornell University, USA) ================================= DAY 3 =================================== Thursday, November 5, 1998: Technical sessions 9:00-10:30 Protocol design and analysis A probabilistic poly-time framework for protocol analysis Pat Lincoln (SRI International, USA), John Mitchell, Mark Mitchell (Stanford University, USA), and Andre Scedrov (University of Pennsylvania, USA) On using public-key cryptography in password protocols Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo Krawczyk (Technion, Israel) Cryptanalysis of Microsoft's point-to-point tunneling protocol Bruce Schneier (Counterpane Systems, USA) 10:30-11:00 Break 11:00-12:00 System monitoring How to prove where you are Eran Gabber and Avishai Wool (Bell Labs, USA) Temporal sequence learning and data reduction for anomaly detection Terran Lane and Carla E. Brodley (Purdue University, USA) ================== Worst paper award and author lampooning =================== Steering committee chair: Ravi Sandhu, George Mason University General chair: Li Gong, JavaSoft Program chair: Mike Reiter AT&T Labs, Room A269, 180 Park Avenue Florham Park, NJ 07932-0971 USA phone: +973-360-8349 Awards chair: Jacques Stern, ENS/DMI Publication chair: Stuart Stubblebine, AT&T Labs Publicity chair: Gene Tsudik, USC ISI Program committee: Martin Abadi, DEC SRC David Naccache, Gemplus Bill Cheswick, Lucent/Bell Labs Hilarie Orman, DARPA/ITO Carl Ellison, Cybercash Avi Rubin, AT&T Labs--Research Ed Felten, Princeton University Pierangela Samarati, Universita di Milano Paul Karger, IBM T.J. Watson Gene Tsudik, USC ISI Steve Kent, BBN Corporation Paul Van Oorschot, Entrust Technologies Ueli Maurer, ETH Zurich Bennet Yee, UCSD Cathy Meadows, Naval Res. Lab Moti Yung, CertCo For more information, visit http://www.research.att.com/~reiter/ccs5 From owner-dns-security Fri Jul 17 16:42:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28277 for dns-security-outgoing; Fri, 17 Jul 1998 16:39:36 -0400 (EDT) Message-Id: <199807171853.OAA12896@ietf.org> To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: dns-security@tis.com From: The IESG SUBJECT: Last Call: Domain Name System Security Extensions to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 17 Jul 1998 14:53:08 -0400 Sender: owner-dns-security@ex.tis.com Precedence: bulk The IESG has received a request from the Domain Name System Security Working Group to consider publication of the following documents as Proposed Standards: o Domain Name System Security Extensions o DSA KEYs and SIGs in the Domain Name System o RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) o Storing Certificates in the Domain Name System (DNS) o Storage of Diffie-Hellman Keys in the Domain Name System (DNS) The IESG will also consider publication of the following as Experimental: o Indirect KEY RRs in the Domain Name System o Detached Domain Name System (DNS) Information and the publication of DNS Operational Security Considerations as an Informational document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 31, 1998. Files can be obtained via: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-secext2-05.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-dss-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-rsa-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-certs-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-dhk-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-indirect-key-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-ddi-05.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-secops-01.txt From owner-dns-security Tue Jul 21 02:21:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06377 for dns-security-outgoing; Tue, 21 Jul 1998 02:18:40 -0400 (EDT) Message-Id: <199807210634.CAA03045@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: Jerry Scharf cc: dns-security@tis.com, namedroppers@internic.net Subject: Re: draft-lewis-dnskey-referral-00.txt (part 2) In-reply-to: Your message of "Tue, 30 Jun 1998 11:52:26 PDT." <199806301852.LAA21328@bb.rc.vix.com> Date: Tue, 21 Jul 1998 02:34:54 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-dns-security@ex.tis.com Precedence: bulk From: Jerry Scharf To: dns-security@TIS.COM cc: namedroppers@internic.net }Don, } }Now on to the other part of your message. I found truly unfortunate your whole }discussion about DNSSEC/DNS interactions. I will not even address what parts }of it I agree or disagree at this time, other than to clarify that we were }never discussing anything other than the AA bit in a DNS response. From my }understanding, 2181 was done at least in part to address the specification }issues in DNS that were damaged by DNSSEC. To now say that there were key }pieces missing and you think that 2181's ideas are wrong is to say that 2181 }failed to do what was needed to clarify DNS so that DNSSEC can work "right". }This in itself is not a problem, the next part is the problem. If you were just discussing the AA bit in DNS responses, I don't see what the problem is. Both RFC 2181 and the current dnssec-secext2 draft say that the AA bit is on only for the zone cut RRs served from the child. RFC 2181 is a wide ranging omnibus clarification RFC for DNS. It covers eight major areas. DNSSEC is only a part of a couple of these areas. RFC 2181 contains what is pretty much a very brief rephrasing of parts of RFC 2065 and in fact specificly and frequently references RFC 2065. The date of RFC 2065 is January 1997. The date of RFC 2181 is July 1997. The date of draft-ietf-dnssec-secext2-05 is April 1998. Why would you look at older RFCs when there is a more recent draft? To quote RFC 2181: "It should be noted that DNS Security is still very new, and there is, as yet, little experience with it. Readers should be prepared for the information related to DNSSEC contained in this document to become outdated as the DNS Security specification matures." }The ISC and TIS have made hard commitments to funders to deliver a fully }functional version of of BIND/DNSSEC with specific deadlines. This will be }widely distributed and will be the basis of all future BIND development. We }have worked quite hard forging this agreement and have worked with many of the }people who deliver BIND to the end users to prime them for this delivery. We }can not wait for the IETF to take another n months to hash this out. It's not }that the implementation defines the spec, but the implementation has to take a }snapshot of the spec and code to that. If you don't like what 2181 says, it }had better get it fixed and fixed fast or you will live with it for a long }time. It's great that you have funding! Maybe you should announce some of this and something about the schedules, if they are not confidential? I had the impression that DNSSEC was being given the back burner while TSIG got the most emphasis and so I had no idea that production DNSSEC development was imminent. It's certainly your decision what you implement, but I can't see why you wouldn't implement the latest version unless it presented difficulties in meeting your schedule. Especially since the latest version is even more helpful in aleviating your concerns over zone bloat, UDP overflow, etc. And I don't know why you are embaressed about the implementation possibly influencing the spec. The spec is just a Proposed Standard and the latest draft is intended to recycle at Proposed, which means that major changes can occur. It's normally not until you have interoperable implementations (a bit hard when DNS is just BIND, but maybe easier now with Microsoft doing their own) that you can go to Draft Standard and things are supposed to stay stable. I can't understand what "hasing out in the IETF" you are talking about. There have only been very minor changes in the secext2 draft and this part of it hasn't changed for months. I was not aware of any controvery or that anyone thought that the latest version still required signed child keys in the parent until I read the referral key draft. I don't understand your constant refernces to 2181. Are you saying that if DNSSEC delegation point KEY RR provisions move on at all from RFC 2065, then you think RFC 2181 has to be rewritten and re-issued as a new RFC even though the changes effect only a tiny part of 2181? (It is a good point that the current draft should perhaps say "UPDATES RFC 2181".) }We believe this is the right thing to do, because we believe getting DNSSEC }successfully deployed is the only reason for doing all this work in the first }place. I'm extremely interested in DNSSEC getting successfully deployed myself. I had no idea that additional development effort was imminent. I hope that I can help. }jerry Thanks, Donald ============================================================ Donald E. Eastlake 3rd +1 978-287-4877 dee3@torque.pothole.com 318 Acton Street +1 978-371-7148 (fax) Carlisle, MA 01741 USA From owner-dns-security Tue Jul 21 02:21:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06376 for dns-security-outgoing; Tue, 21 Jul 1998 02:18:40 -0400 (EDT) Message-Id: <199807210634.CAA03034@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: Jerry Scharf cc: dns-security@tis.com, namedroppers@internic.net Subject: Re: draft-lewis-dnskey-referral-00.txt In-reply-to: Your message of "Tue, 30 Jun 1998 11:45:10 PDT." <199806301845.LAA21244@bb.rc.vix.com> Date: Tue, 21 Jul 1998 02:34:04 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-dns-security@ex.tis.com Precedence: bulk From: Jerry Scharf To: dns-security@TIS.COM cc: namedroppers@internic.net }This is a response to the parts that impact only secext2 and this proposal. }There is a second part that covers the whole discussion of authority and 2181. } }Justification issues: } }My understanding of why we "needed" the key in the parent was as follows: If }you have a parent zone secured and a child zone secured, you have to be able }to tell the query source whether to reject unsigned responses from the child. }The original system did this, but at the expense of the parent having to do }key management for the child. If I understand the new proposal right, there is }no requirement that the parent return anything other than the delegation glue }if the parent and child are both secured. Is the parent still required to }return null records for unsecured children? Our proposal was to keep the logic }of the parent always returning a signed key, but removing the content and only }having it be a consistent flag, the negation of the null key. The motivation }for this was to allow large registries to more easily/quickly deploy secure }DNS. There are several point in the above paragraph: Yes, the query source needs to know in a cryptogrpahically secure way whether or not the child of a secure parent is a secure child or an insecure child. But the cryptographic security of the data indicating this (NULL or non-NULL KEYs) is independent of where it is stored. Of course for a practical system you need to be able to find it. Yes, the early version of DNSSEC documented in RFC 2065 requires the secure parent to have the signed key (possibly NULL) for the child in the parent zone. The storage and supplying of this data in response to queries is just a data publication service, not a security service. The first sentence of 2.3.4 mandating this was removed. I do not claim that the current draft language is clear on this point, which is my fault. You ask if the parent is still required to return null records for an unsecure child. The answer is no. The signed NULL key must be accessible, but it could just be in the child. As it says in the current draft the *ONLY* case where the child key signed by the parent *MUST* be in the parent is when you have a secure parent of an insecure child where the child can't easily be modified to include the NULL child key signed by the parent. This provision could have been left out but it was thought that in the transition to DNSSEC, early on at least, there would be many (perhaps millions) of cases where a newly secured parent wanted to provide delegations and allow its insecure children to be accessed by secure resolvers but where the logistic problems of getting the insecure children modified quickly to have a NULL key at its apex were just insurmountable. In order for secure resovlers to believe in data from the insecure child, they need to cryptographically verify a NULL KEY for the insecure child signed by the parent. If the child is a stick in the mud, then the only other findable place for the NULL child KEY signed by the parent is in the parent zone. Thus secure DNS servers that are incapable of holding a signed NULL key for an insecure child are prohibited by this "MUST" requirement. >From what I understand of the motivation for the referral key draft, the motives are better satisfied by the elimination of the general requirement that the parent zone have the signed child keys in it. }Partly I am confused because you have argued for this in the past. Yes, long ago I argued for what is in RFC 2065. But I revised the language due to what I believe is growth in my understanding and due to requests I received, based on arguments of parent zone bloat similar to yours. }If I read your new text for 2.3.4, it does not say at all what you said you }wanted it to say. This is a major change in functional logic from 2065, and to }kind of slide it in with a subtle interpretation in a text rewrite is bad. I }have talked to the other authors and they strongly believe that this new view }of delegation logic is bad and shold not be done. I do not find an argument that says X should not be done because it is "bad", without any further explanation, convincing, although I guess three knowledgable people saying that is more convincing than, say, one knowledgable person or three less knowledgable people.... }If it is decided that removing the requirement for any security related glue }in the case of a secure parent and child, then this whole proposal becomes }moot and the registries can simply go the route of least resistance. Again, }the authors do not believe that this change in delegation logic is well }considered and thus continue to believe that this proposal is needed to allow }secure chlidren to be flags without dealing with key management. Sorry but, if you are still requiring the child key to be signed by the parent, I just don't see what's gained by the referal key proposal. I don't know why you think the change that has been in the secext2 draft for months is not "well considered". I certainly thought about it a lot. In my opinion, strong security must be based on a clear theory, not vague intuition. The security of authenticated data in DNSSEC is based on a chain running from the data to a staticly configured key where the chain meets cryptographic, validity interval, and policy requirements. The physical source of the data is of no security importance (in the secured case). Of course, in general you have to find the data, but it's not like there are very many places cut point data can be. For most data, it's in the servers for the zone. For cut point data, sometimes there are two sets of servers you can go to. Is the concept that, where the parent has chosen not to provide the data publicaton service of having the singed keys in its zone, that requiring two parent signatures, one on the referral key and one on the signature in the child, is somehow more secure? If not, exactly how does the referral key improve security? It certainly makes the parent zone bigger, with the attendent problems you point out, and it just generally makes things more complex. }Your assumptions about how many keys people keep are different than mine. The }idea of a 5-10% rollover time seems ludicrous to me if I'm talking about an }action that requires communicating with a registry. The whole reason for this }proposal is to allow registry/user situations to work with DNSSEC in place. I }know mark kosters and I like mark and there is no way I am going to trust the }Internic to never miss a submission on a 30 day rollover key for my .com zone. }The whole idea of explicit start and stop times in keys is that I can stay }safe by sending the key in long enough ahead of time that I can handle the }problems. The reason for DNS protocol KEYs in DNS is to verify SIGs. If there are no SIGs corresponding to the KEY, the KEY is not necessary (for DNS, I'm ignoring KEYs in DNS for other protocols here). Lets say that you want monthy key roll over. To provide overlap, you want a child KEY RRset signed by the parent that includes ChildKey(N), one that includes both ChildKey(N) and ChildKey (N+1) and one that is just ChildKey (N+1). Say the child zone is signed by key N. At the end of the month, you reload the zone signed by N+1 and the double size rollover KEY RRset. How long do you have to wait before you can update the KEY RRset to the single size one with just KEY N+1? It is exactly as long as there are old SIGs floating around. Now the SIGs have an expiration time and if DNSSEC were universally deployed, and all clocks were synchronized, etc., in theory you would never have to serve up the double size KEY RRset. So the question is how many DNS servers and applications of DNSSEC are going to cache SIGs that might require a KEY retrieval for verification and how long are they going to do so? (Presumably applications that are doing their own DNS SIG verification outside of DNSSEC are rare, but who knows..) If you assume SIGs might hang around for two days, then the double size KEY RRset need only be available for about 2/30th of the month or about 6.7%. That was what my 5-10% was about. For a huge zone like .com, it would be reasonable to limit KEY rollover (at least without an extra charge) to, perhaps, quarterly. This would bring you down to 2% or 3% and maybe under 1% if you only need the double size KEY RRset for, say, 20 hours. Of course, if the keys are just in the child, this percentage really not of much concern to the parent... By the way, I like Mark Kosters also. And I remember speaking with him in the hall at a recent IETF meeting and specifically re-assuring him that, while RFC 2065 required child keys in the parent, the then current draft didn't and the child keys could be in the child only (except, of course, for the NULL KEY for an insecure child where it was impractical to get the child zone modified to include a NULL KEY for itself). As I recall, he seemed pretty happy about it. }I'll admit that some of the numbers are abitrary, but there will be a whole }bunch of dual key records. Speaking as an operator of a root nameserver, }"specifically the working group consensus not to worry too much about UDP }overflow" is very scary. The UDP size increase for DNS will take many years to }deploy, so it's not going to save me. The idea that the roots would suddenly }shift a significant percentage of their traffic to TCP after having fully }processed the request once and not be extremely negatively impacted is silly }and not the right thing if you care about the internet working when we try to }deploy DNSSEC. There are two reasons why this is less of a problem in the }child. The children are less of a hot spot than the roots, and since the }person who controls the master can make the change, there is less need to have }dual keys. I am keeping dual keys to protect myself from registry snafus. I care a lot about the Internet working. In our original proposal, Charlie Kaufman and I busted a gut packing in bits to minimize RR size. And I've submitted and been updating a draft for a simple and, I think, reasonably quickly deployable bigger UDP proposal (draft-ietf-dnsind-udp-size-02.txt). And I've been pushing a bit in private (and perhap[s should have been pushing even harder) for a specification of Elliptic Curve crypto for DNSSEC because it is more compact. I would think you would be happy that there isn't any reason to clutter the parent with referral keys as this further reduces the burden on parents. I don't quite understand what you say above about "dual keys". It seem to me that you are keeping future signed KEY RRsets (assuming the parent will oblige) to protect yourself "from registry snafus". Dual keys for a brief time are simply necessary for smooth key rollover and I don't see that they have anything to do with protecting yourself from a registry. I think such protection primarily invovles "future" keys, not "dual" keys. }I agree that the issue of SOA counts is weak, but the rate of }installed/changed }data for secured subzones is not. Speaking as someone who dabbles in the }registry world, casually saying that there might be a factor of 10 or 20 }increase in change requests that need to be installed in the advertised zone }scares me. Since I already know that I am facing exponential growth as a base, }this hurts all the more. If the child key signing is an offline process }independent of the zone generation, the scaling problem can be handled more }easily. My main poinst was that the statement that the SOA had to be incremented for every KEY update was incorrect becasue they can (and would for a huge zone) be batched with other updates. (And even the believe that the SOA has to be incremented for every batch update is not logically necessary since you only need to increment it on processing a retrieval which includes the SOA in the response where the zone has changed since the previous such retrieval.) There is no question that no matter how you slice it, security involves work and DNSSEC is no exception. The requirement to securely receive the child KEY RRsets and sign them seems like the overwhelming requirment in terms of risk, amount of computation, senstivity, etc. Once you have done that, communicating the parent signed child keys back to the child and putting them in the next update batch for the parent zone if you have chosen to also publish them from the parent zone don't really see like that much. If you have a giant zone, you would presumably choose not to publish them in the parent. All these ratios are rough and I don't think anyone knows what the increase in the parent zone update rate would be if the parent chooses to publish the child key also. And if it did, the parent could have some control over this by limiting the rate of child key udpates or charging for that service etc. (I would think most parents that have an arms length relationship with their child would *definitely* charge for signing future KEYs. If the didn't and the child terminated DNS service from the parent, it could use its future signed keys to authenticatably spoof good DNS data for that future unless the parent went to the big hassle of rolling over the parent key and re-signing every still good child's KEYs...) }I agree that stopping advertisement of a key does not solve the attack, since }the key can be used in many situations even after the key has been pulled from }the parent zone. It is again a sympathy for the legal departments of a }registry that it is unpleasant to not react with the desired speed of the }customer. As a registry, I just want to never be involved with this. Your }complete dismissal of the liability issue is at odds with what I have seen in }the registry world. People like to sue registries, and this is trying to }remove one opportunity. Waiving away the legal exposure of doing someone }else's key management for them is not going to aid in getting secure DNS }deployed. Data publicatyion services are not security services. There are obviously possibly liabilities as a registry. Some are increased with DNSSEC and some are decreased. *Security* liability of the parent comes, outside of running a secure parent zone, comes entirely from signing the child KEY RR(s) and releasing this to any party outside the parents control (such as the child). The instant it does this, there is a KEY RRset and parent SIG floating around in the world that could bring some sort of liability just as the instant an X.509 CA releases a certificate there is a key plus additional info signed by the CA floating around in the world. CA's seems to worry a lot about the liability this creates. They don't seem to worry nearly as much about publishing the certs and when they do, it seems to be mostly a privacy concern rather than a security concern (after all that's why they call them *public* key certificates). Such privacy concerns do not appply to DNS KEY RRs. Data *publication* liability of the registry always exists in the form of the NS and A RRs it servers as well as whatever other infomration it publishes about the child. If anything, DNSSEC reduces the stringencies here. Things are unchanged for insecure resolvers but secure resolvers will check signatures so publishing incorrect data can not mislead them (although it would probably lead to denial of sevice) only *signing* incorrect data can mislead secure resovlers. Thus, while I see very little change in registry liability for data publication, the effects of DNSSEC, such as they are, are to reduce registry liability. And registry liability for security services, which consist of signing the child RRset and releasing this signature, are, in my opinion, not affected by whether the parent chooses to publish the signed child KEY RRset and well as giving it back to the child. }One key point of doing the key in the child only is that you do not need }super secure communications from the child to the parent and back. Since the }real key is only advertised by the child, and the child will only advertise it }after it has checked that what it got back was what it sent signed by the }parent, this removes the risk of forgery. You can still forge the }secure/unsecure my zone messages, but that's a simpler attack to detect/solve. If the parent signs the child key, which you keep saying you meant all along, then you absolutely *do* need super secure communications from the child to the parent for the child to send its keys to the parent so the parent can sign them or if you are going to be dependent on the child checking that it was the correct child KEY RRset that the parent signed, then you absolutley *do* need super secure communications from the parent to the child so no one can oversee some bad parent signed KEY RRset going by, grab it, and use it for nefarious purposes. Otherwise the bad guy corrupts the request from the child to the parent to have the RRset the bad guy wants (for which they have the private key) and grabs the returned parentally signed RRset and they are off to the races. }Specification issues: } }I have removed all the specific comments that are restatements of issues }brought up in the justification area. } }3.0 } }> The paragraph above and below both seem to hint that the child KEY }> might only be signed by itself. } }That was not our intent. We can add a sentence to the first paragraph making }it clear that then signature chain of child key signed by parentis still }required. I think you may need more than adding one sentence to turn around the draft so it no longer implies non-parent-signed child keys. Take the following paragraph as just one example: If the public key set is in the parent zone, and the parent zone is not able to make the change quickly, the public key cannot be revoked quickly. If the parent only refers to there being a key at the child zone, then the child has the agility to change the keys - even issue a NULL key, which will force all signatures in the zone to become suspect. First of all, there isn't any revocation in DNSSEC. A bad guy may have grabbed the parent signed child KEY RRset for one of which the private key has been compromised, in which case the parent ceasing publication, if it was publishing the key, while a good idea, may not help. But more imporant, this talk of the child being able to change keys is very misleading. It is the parent which has the ability to give the child overlapping different KEY RRsets, including one with a NULL key, that the child could start publishing at the apex of its zone. If the parent does not do this, the child has no agility whatsoever. And the above is certaily true if the parent signed child KEY RRsets are only published in the child. }> Since you shouldn't use the name type field to indicate this sort of }> indirect key, you need to use something else in the KEY RR. In }> draft-ietf-dnssec-indirect-key-*.txt, it proposes to use a special }> algorithm field value. Alternatively, you could use some other flag }> bit. } }This idea is much different that indirect keys as decribed in the i-d you }mentioned. This is a strict parent child relationship with the sole goal of }removing the requirements on the parent to do key management for the child. }Since this is directly comparable to the NULL key for an unsecure child zone, }we consider a design that uses the same mechanism as the NULL key, ie. flags, }makes the most sense. OK. Using a flag bit for the referral key is fine if it is decided to burden DNSSEC with the referral key. I consider using the "name type" field for something this isn't a "name type" to be an unnecessary violation of the current use of the field. }4.0 } }> You also keep conveniently overlooking that the sort of insecure }> indirect key you propose *throws* *away* all cryptographic security }> for the data in the child. You not longer have data origin }> authentication. You no longer have integrity. You are now totally }> spoofable with only a tiny constant increment in effort over spoofing }> a child zone for which the parent has a NULL KEY. Sure, the parent }> is no longer performing the security service that was really }> important, signing the child KEY, so as a result, you don't have any }> security. } }Don, this is simply not true. Given that we believed that there needed to be }some key, we chose to create a key that never validates and signals the }resolver to get the valid key from the child. There is no loss in }cryptographic security at all. The child still needs to offer a key that has a }parent sig on it for it to be accepted, and the keys in the parent are still }signed so they can not be forged by someone not capable of generating a parent }sig. } }You managed to leap to an assumption that we had changed the entire logic of }DNSSEC such that we are no longer requiring the parent to sign the child key, }then used it to go on and on about the proposal. You even later in the }response get that fact and still don't say what's needed is a clarification of }1 paragraph. Well, I suppose everything is subject to interpretation. But I sure don't think I leapt to any assumption. I just took the plain implications of the plain wording of the draft. Almost everywhere, that strong implication is that child keys are not signed by the parent. I think that changing that impression will require more than a clarification in 1 paragraph. For example, as I mention above, you say "If the parent only refers to there being a key at the child zone, then the child has the agility to change the keys -" and similar statements without qualification. But that would only be true if the parent didn't have to sign the child's keys. If the parent does, then the child can only change keys if the parent has been willing to sign alternate sets of child key and the child can do this only for as long as the parent SIGs are valid (i.e., it is between their inception and expiration time and the parent key(s) used to sign are still valid). (And the parent had better transmitted these alternate KEY RRset, particularly any parent signed NULL KEY RR, super securely, or a bad guy could get it and successfully spoof an insecure child.) And since, as far as I can tell, all the parental liability for security services stems for signing the child key and then releasing the signature out of parental control, all of the statements about eliminating liability in the draft meant to me that you were dispensing with parental signatures on child keys. As exaplained above, I can't see how whether or not the current parent signed child key is published in the parent zone has any security effects or liability effects as long as this parent signed child key is published in the child zone. }jerry I had though you would be happy about my remarks. They mean even less parental zone bloat. Thanks, Donald ============================================================ Donald E. Eastlake 3rd +1 978-287-4877 dee3@torque.pothole.com 318 Acton Street +1 978-371-7148 (fax) Carlisle, MA 01741 USA From owner-dns-security Fri Jul 24 17:14:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22971 for dns-security-outgoing; Fri, 24 Jul 1998 17:11:45 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199807210634.CAA03034@torque.pothole.com> References: Your message of "Tue, 30 Jun 1998 11:45:10 PDT." <199806301845.LAA21244@bb.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 17:27:03 -0400 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: draft-lewis-dnskey-referral-00.txt Cc: Jerry Scharf , dns-security@tis.com, namedroppers@internic.net Sender: owner-dns-security@ex.tis.com Precedence: bulk At 2:34 AM -0400 7/21/98, Donald E. Eastlake 3rd wrote: Regarding the determination of whether a particular zone is secure or not... >insecure child. But the cryptographic security of the data indicating >this (NULL or non-NULL KEYs) is independent of where it is stored. Of >course for a practical system you need to be able to find it. 1) I disagree that the location of the data used to determine this is unimportant. In particular: My resolver is querying an authoritative name server for a zone. I discover the information I desire is below a delegation point. If I know, based on data available above the delegation, whether or not the next zone is either secure, experimental, or unsecure, I can approach the next zone with confidence. Without knowing, it is possible that a masquerading name server may be able to convince me the next zone is unsecured or experimental, when in fact the zone is secured. Restricting the discussion to departing from a secured zone, if there is a NULL key indication I know to expect an unsecured zone(*). If there is a zone key, I expect signatures - and there is the liability issue (et.al.) raised by the draft. If, as you {Donald) now state is in secext2, the parent is not required to hold the key of the next zone, then you are setting up a decision based on the absence of information to determine security. IMHO, using the absence of information as an explicit indication of a security state is a bad idea. (*) = For given algorithm(s). Further, in reading secext2, it is not clear that you have removed the requirement that the parent hold child keys. This is my (Ed) personal opinion. 2) I think that denegrating "practical" issues to "of course" clauses is understating the importance of practicality in a security system. (Perhaps this is a poorly communicated point.) >The first sentence of 2.3.4 mandating this was removed. I do not I admit, this is a cheap shot - but please edit your messages before you send them. You have a tendency to repeat ideas which makes timely response difficult. I apologize for this comment. >You ask if the parent is still required to return null records for an >unsecure child. The answer is no. The signed NULL key must be ... >the parent zone. Thus secure DNS servers that are incapable of >holding a signed NULL key for an insecure child are prohibited by this >"MUST" requirement. Wow. Yes, in theory, dropping this requirement may be possible, but I believe that you are introducing something that will make DNSSEC impractical. The relationship of delegator/delegatee is complicated by DNSSEC, I think the "cost" of the parent holding a NULL key or a referral is too neglibile to have an inconsistency among delegations that are secured and those that are (quoting you) "stuck in the mud." >Sorry but, if you are still requiring the child key to be signed by >the parent, I just don't see what's gained by the referal key proposal. The key referral allows the explicit statement that the child zone is secured without the messy liability or memory/bandwidth concerns. >data publicaton service of having the singed keys in its zone, that >requiring two parent signatures, one on the referral key and one on >the signature in the child, is somehow more secure? If not, exactly I apologize for not being more clear. Please see the above comment for the answer to this question. The performance gain is claimed against the RFC2065 requirements. We are promoting a performance *loss* against what you are claiming secext2 says - but recall, to us, your interpretation of what you wrote in secext2 is news to us. Yes, you did issue it a while ago, but 1) we missed the change and 2) when we read the changed text, we still did not get your point. What do I mean by "determining a zone's security status?" Well, when I get data and I run the crypto checks on it, I may get a totally valid chain of trust (and I'm done). If I don't - then I need to seek the true answer. To find this answer I want to go to the authoritative server, and to do this throughly I need to successively traverse zones (and discovering the security level of each). There was a draft on this a while back - draft-lewis-dnssig-authorization. >Jerry Said: >}...I like mark... >By the way, I like Mark Kosters also. Honestly, I don't know who Mark Kosters is (outside of employer and role), but if Donald and Jerry say he's a nice guy, then I like him too. Now that I'm at the end of the reply, I'd like to know who, beyond myself, Jerry, and Donald, is following this issue. I'm simply curious, because there seems to me that there has been no other traffic on DNSSEC in many months. Has this become a debate between me (&Jerry) and Donald? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Network Associates/TIS Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Sat Jul 25 09:14:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24436 for dns-security-outgoing; Sat, 25 Jul 1998 09:12:46 -0400 (EDT) Date: Sat, 25 Jul 1998 06:28:50 -0700 (PDT) From: Jerry Scharf Message-Id: <199807251328.GAA02136@bb.rc.vix.com> To: dee3@torque.pothole.com, lewis@tis.com Subject: Re: draft-lewis-dnskey-referral-00.txt Cc: dns-security@tis.com, namedroppers@internic.net, scharf@vix.com Sender: owner-dns-security@ex.tis.com Precedence: bulk thank you, thank you. jerry From owner-dns-security Sat Jul 25 11:28:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24599 for dns-security-outgoing; Sat, 25 Jul 1998 11:27:46 -0400 (EDT) Message-ID: <35B9B72B.48EE4166@fc.net> Date: Sat, 25 Jul 1998 10:44:59 +0000 From: William King Organization: Mount Bonnell Inc. X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: Edward Lewis CC: dns-security@tis.com Subject: Re: draft-lewis-dnskey-referral-00.txt References: Your message of "Tue, 30 Jun 1998 11:45:10 PDT." <199806301845.LAA21244@bb.rc.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward Lewis wrote: > > Now that I'm at the end of the reply, I'd like to know who, beyond myself, > Jerry, and Donald, is following this issue. I'm simply curious, because > there seems to me that there has been no other traffic on DNSSEC in many > months. Has this become a debate between me (&Jerry) and Donald? I have recently joined this list in order to understand what you folks are doing in this area and why and to help me define some testing requirements for a DNS/BIND test suite. These discussions are useful to me and I'd encourage you to continue to attempt to resolve these issues in a spirit of full and frank discussion. William King http://www.bonnell.com/mbi/mbi.html From owner-dns-security Wed Jul 29 11:27:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08354 for dns-security-outgoing; Wed, 29 Jul 1998 11:23:17 -0400 (EDT) X-Authentication-Warning: askew.hq.tis.com: bwelling owned process doing -bs Date: Wed, 29 Jul 1998 11:32:30 -0400 (EDT) From: Brian Wellington X-Sender: bwelling@askew.hq.tis.com To: dns-security@tis.com cc: dee3@torque.pothole.com Subject: General comments on last call DNSSEC drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I read through all of the drafts last week, and have a few minor comments on several of them. None of these are critical (and definitely should not prevent recycling at Proposed Standard or movement to Informational), but I'd like to discuss them anyway. Without further ado: General question: - The "Current DNS implementations are optimized for small transfers" paragraph is present is all of the drafts. Yes, this is an important cpnsideration, but is such repitition necessary? draft-ietf-dnssec-certs-02.txt: - The CERT record contains a "key tag" field to allow the CERT to be more easily paired with a KEY record. Are multiple CERT with the same name and key tag allowed, and are there special considerations? - Is the matching key required to have the same name as the certificate? There could be cases where this is undesirable. draft-ietf-dnssec-ddi-05.txt - Except for the fact that the example scenario uses KEY records, this draft has nothing to do with DNSSEC. Why is it associated with DNSSEC? draft-ietf-dnssec-dhk-02.txt - In section 2: > If "prime length" field is 1 or 2, then the "prime" field is actually > an unsigned index into a table of up to 65,536 predefined > prime/generator pairs to be defined in which case the generator length > should be zero. I believe this has been brought up before, but this is unimplementable until this table is specified, and any attempt to implement would lead to incompatibility between vendors. draft-ietf-dnssec-dss-02.txt - The DSS KEY record contains a 'T' field, from which the key length can be determined. Since the key length can be determined from the RR size, this is not necessary. Also, the meaning is reserved if T > 8. If the reserved values are designed to allow longer keys, T is still not necessary; if it some other reason, then a new algorithm identifier should be specified for those cases. As mentioned in the draft, T is irrelevant for SIG records. draft-ietf-dnssec-rsa-00.txt - The European equivalent of RSAREF is called RSAEURO, not EuroRef. draft-ietf-dnssec-secops-01.txt - A small addition to Section 4.2, DSS Key Sizes. DSS signatures are not only smaller than RSA sigs, they are a fixed size regardless of key size (41 octets currently, 40 if T is removed). draft-ietf-dnssec-secext2-05.txt - Transaction signatures have a flaw. There is no way for a resolver to specify that the response to a query MUST be signed. A resolver is not required to drop a response with no transaction signature when it expects the response to have one. Thus, the signature is useful when present, but if not present, it could be the result of an attacker stripping off the signature and modifying the payload. Comments? Brian