From atkinson@itd.nrl.navy.mil Tue Sep 7 05:13:26 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18300 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 10:12:49 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA10965 (InterLock SMTP Gateway 1.1 for ); Tue, 7 Sep 1993 09:57:20 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29637; Tue, 7 Sep 93 09:13:26 EDT Date: Tue, 7 Sep 93 09:13:26 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309071313.AA29637@itd.nrl.navy.mil> To: ipsec@ans.net, namedroppers@nic.ddn.mil Subject: [resend] Use of DNS to distribute keys [ This bounced from the IP Security list because of bad typing and so my apologies to the DNS folks for the resend.] For several years now I've been thinking that the DNS is probably a really good way to distribute keys (or key certificates). For example, if each host had a public key accessible via the DNS, one could more easily setup a secure session key between oneself and the remote host that one wished to communicate with. Also, one might be able to encrypt UDP packets using asymmetric encryption for the odd case where one only wanted to send one or two packets and thereby avoid the overhead of setting up a session key for extremely brief sessions. With all the current activity on an IPv4 Security Protocol and adding security to the DNS, I'm wondering what the DNS wizards think about this idea and whether anyone knows of any past experiments along this line. I've cross-posted this to the IPv4 Security Protocol list and the normal DNS list. Please edit reply addresses appropriately. Thanks, Ran atkinson@itd.nrl.navy.mil ----- End Included Message ----- From dcrocker@Mordor.Stanford.EDU Tue Sep 7 16:56:59 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17164 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 13:09:04 -0400 Received: from Mordor.Stanford.EDU by interlock.ans.net with SMTP id AA04624 (InterLock SMTP Gateway 1.1 for ); Tue, 7 Sep 1993 12:51:51 -0400 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23666; Tue, 7 Sep 93 09:57:00 -0700 Message-Id: <9309071657.AA23666@Mordor.Stanford.EDU> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: Use of DNS to distribute keys Date: Tue, 07 Sep 93 09:56:59 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: For several years now I've been thinking that the DNS is probably a really good way to distribute keys (or key certificates). Let me ask a related question: One of the marks of distinction about the DNS, relative to X.500, DEC's Name Service, OSF's Cell Directory Service, and most discussions about network use of directory service, is that is is used in very, very limited ways. I suspect that limiting the use to name/address mapping has been instrumental in making it feasible to rely on DNS access as part of the operational infrastructure. This is not to say that the broad range of other uses are not also interesting and important, merely that the narrow focus in functionality probably has helped operation of the system. Do others have similar feelings about this? If so, it leads me to wonder whether proposals for broadening the use of the DNS might actually want to consider construction of a parallel DNS for non-core operational use. (Where's the line? I don't know. With no hesitation, I'd guess that key distribution can be(come) a core service. But it isn't now. Mumble.) Thoughts? Dave From huntting@glarp.com Tue Sep 7 18:33:49 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12810 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 14:44:43 -0400 Received: from uswat.advtech.uswest.com by interlock.ans.net with SMTP id AA11803 (InterLock SMTP Gateway 1.1 for ); Tue, 7 Sep 1993 14:27:38 -0400 Received: from misc.glarp.com by uswat.advtech.uswest.com with SMTP id AA10820 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 12:33:51 -0600 Received: from localhost.glarp.com by misc.glarp.com with SMTP id AA01625 (5.65c/IDA-1.4.4); Tue, 7 Sep 1993 12:33:49 -0600 Message-Id: <199309071833.AA01625@misc.glarp.com> To: Dave Crocker Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of "Tue, 07 Sep 93 09:56:59 PDT." <9309071657.AA23666@Mordor.Stanford.EDU> Date: Tue, 07 Sep 1993 12:33:49 -0600 From: Brad Huntting > If so, it leads me to wonder whether proposals for broadening the > use of the DNS might actually want to consider construction of > a parallel DNS for non-core operational use. (Where's the line? > I don't know. With no hesitation, I'd guess that key distribution > can be(come) a core service. But it isn't now. Mumble.) I dont see anything wrong with putting more "host related information" in DNS. What's dangerous is to try to extend the idea "domain name" to include more than just "things with IP addresses", "things that appear after the @ in email addresses", and "administrative breakpoints". In other words, it might be risky to add PEM information to DNS, but it would probably not be risky to ad IP security information to DNS. brad From pmetzger@lehman.com Tue Sep 7 18:55:22 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06814 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 15:05:07 -0400 Received: from Lehman.COM by interlock.ans.net with SMTP id AA08923 (InterLock SMTP Gateway 1.1 for ); Tue, 7 Sep 1993 14:57:44 -0400 Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA21068; Tue, 7 Sep 93 14:55:25 EDT Received: from snark.lehman.com by shearson.com (4.1/LB-0.6) id AA23605; Tue, 7 Sep 93 14:55:24 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA18375; Tue, 7 Sep 93 14:55:23 EDT Message-Id: <9309071855.AA18375@snark.lehman.com> To: Dave Crocker Cc: namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of "Tue, 07 Sep 1993 09:56:59 PDT." <9309071657.AA23666@Mordor.Stanford.EDU> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Sep 1993 14:55:22 -0400 From: "Perry E. Metzger" Dave Crocker says: > > If so, it leads me to wonder whether proposals for broadening the > use of the DNS might actually want to consider construction of > a parallel DNS for non-core operational use. (Where's the line? > I don't know. With no hesitation, I'd guess that key distribution > can be(come) a core service. But it isn't now. Mumble.) > > Thoughts? A while back I thought about the unrelated issue of including faces in DNS and ran smack into the RR size limitation. Admitedly this was a silly use, but public keys share the problem of being large, especially when authentication information in the form of signatures on the keys gets kept. Either DNS needs bigger record sizes, or a parallel structure would have to be built, or someone would have to produce some sort of really disgusting kludge. Its a shame, because things like these do, in my opinion, properly belong in DNS. Why have a dozen distributed databases keyed on host name when one will do? Perry From dcrocker@Mordor.Stanford.EDU Tue Sep 7 20:28:34 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06882 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 16:35:33 -0400 Received: from Mordor.Stanford.EDU by interlock.ans.net with SMTP id AA08164 (InterLock SMTP Gateway 1.1 for ); Tue, 7 Sep 1993 16:26:17 -0400 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA27580; Tue, 7 Sep 93 13:28:37 -0700 Message-Id: <9309072028.AA27580@Mordor.Stanford.EDU> To: Brad Huntting Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: Use of DNS to distribute keys Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 07 Sep 93 12:33:49 -0600. <199309071833.AA01625@misc.glarp.com> Date: Tue, 07 Sep 93 13:28:34 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: In other words, it might be risky to add PEM information to DNS, but it would probably not be risky to ad IP security information to DNS. I believe that the 'keys' in question are generic public keys, rather than being tied to IP security levels. d/ From ho@cs.arizona.edu Tue Sep 7 06:53:55 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20568 (5.65c/IDA-1.4.4 for ); Tue, 7 Sep 1993 16:53:49 -0400 Received: from optima.CS.Arizona.EDU by interlock.ans.net with SMTP id AA13701 (InterLock SMTP Gateway 1.1 for ); Tue, 7 Sep 1993 16:47:41 -0400 Received: from umbra.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA21300; Tue, 7 Sep 1993 13:53:56 MST Date: Tue, 7 Sep 1993 13:53:55 MST From: "Hilarie Orman" Message-Id: <199309072053.AA01135@umbra.cs.arizona.edu> Received: by umbra.cs.arizona.edu; Tue, 7 Sep 1993 13:53:55 MST To: dcrocker@Mordor.Stanford.EDU Cc: ipsec@ans.net, namedroppers@nic.ddn.mil In-Reply-To: Your message <9309072028.AA27580@Mordor.Stanford.EDU> Subject: Re: Use of DNS to distribute keys Another floor wax or dessert topping ambiguity. I thought the information to be distributed was related to keys for communicating with an entity identified by an IP number. Certificate, RSA key, DES key, Diffie-Hellman, ... From huitema@mitsou.inria.fr Wed Sep 8 09:05:50 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05139 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 05:06:51 -0400 Received: from mitsou.inria.fr by interlock.ans.net with SMTP id AA14795 (InterLock SMTP Gateway 1.1 for ); Wed, 8 Sep 1993 04:59:12 -0400 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA05188; Wed, 8 Sep 1993 11:05:52 +0200 Message-Id: <199309080905.AA05188@mitsou.inria.fr> To: Brad Huntting Cc: Dave Crocker , atkinson@itd.nrl.navy.mil (Ran Atkinson), namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of "Tue, 07 Sep 93 12:33:49 MDT." <199309071833.AA01625@misc.glarp.com> Date: Wed, 08 Sep 93 11:05:50 +0200 From: Christian Huitema Brad, I have been chewing similar thoughts for some time now, and I think that there are at least two major problems for mapping "security info" (PEM certificates) directly inside the DNS: - First, security info is generally based on "descriptive naming" -- white page like, user friendly, etc. One could question the particular PEM choice of using X.509 formatting, object identifiers, ASN.1, rather than e.g. comma separated text strings; but the fact remains that security mandates "clear identification" rather than DNS like acronyms. Refer to any of Steve Kent's messages on this subject (e.g. recent communication to INET-93) for a complete discussion. - Second, security information, if seriously taken, requires long keys, e.g. 1024 bits. A certicate includes two full names, one key info and one signature; this is probably very often more than the canonical 512 octets payload limit of a datagram. As a side effect, this also poses some problems of "caching size" -- like letting it grow by two orders of magnitude. The idea of developing an application that would parallel the DNS is thus very appealing. In particular, it should be possible to build up on the particular nature of PEM certificates: they contain a complete naming information, and they are "sealed", thus enabling riskless duplication. We will indeed need "glue" between this application and the DNS, e.g. "domain certificates" linking a white page and a domain name, or maybe specific "security server" informations. Christian Huitema From atkinson@itd.nrl.navy.mil Wed Sep 8 04:50:23 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13776 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 08:50:59 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA14813 (InterLock SMTP Gateway 1.1 for ); Wed, 8 Sep 1993 08:44:16 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16996; Wed, 8 Sep 93 08:50:23 EDT Date: Wed, 8 Sep 93 08:50:23 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309081250.AA16996@itd.nrl.navy.mil> To: Christian.Huitema@sophia.inria.fr Subject: Re: Use of DNS to distribute keys Cc: ipsec@ans.net, namedroppers@nic.ddn.mil Christian has a number of good points in his note. I think that the certificates I'd most like to see would contain: 1) a fully qualified domain name of a host, 2) the public key for that host, and 3) an authenticating signature for the whole certificate. If the key certificates themselves are not in the DNS, it still might be useful to have a record (analagous to the MX record) which points to a host key certificate provider for a host or a subdomain. If not in the DNS, then I'd like for there to be some fairly automated way that my machine could reliably obtain the public key for the remote host so that I could use that remote public key for session key establishment and such like. This key certificate acquisition should not require human intervention. If I send data to machine N, my networking code will have to be able to make a call to get N's public key and then use some (mutually agreed upon) key management protocol along with the knowledge of N's public key and my public/private keys to setup a session key between my machine and N. I hope that some future working group will devise an Internet standard Key Management Protocol, possibly based on the SDNS Key Mgmt Protocol but not necessarily that one. Ran atkinson@itd.nrl.navy.mil From huitema@mitsou.inria.fr Wed Sep 8 13:36:18 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13543 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 09:37:30 -0400 Received: from mitsou.inria.fr by interlock.ans.net with SMTP id AA11804 (InterLock SMTP Gateway 1.1 for ); Wed, 8 Sep 1993 09:30:17 -0400 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA05776; Wed, 8 Sep 1993 15:36:19 +0200 Message-Id: <199309081336.AA05776@mitsou.inria.fr> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of "Wed, 08 Sep 93 08:50:23 EDT." <9309081250.AA16996@itd.nrl.navy.mil> Date: Wed, 08 Sep 93 15:36:18 +0200 From: Christian Huitema Ran, You will be facing two problems with the approach that you suggest: 1) If you want to attach a public key to a domain name, you will have to prove the authority of the certifier on the domain. The classic counter example is when you receive a certificate signed by "Al Capone, General trades, Chicago, US" for the domain "lcs.mit.edu". What is needed is what I called "the glue". There sure are solutions, but you will have to spell them out.. 2) The host identifier is not necessarily the "correct" thing to use, even for a firewall. I may want to grant access to our local network to "Christian Huitema, INRIA, FR", regardless of where his powerbook happens to be plugged. It would thus be better to assume that a "classic" certificate is used for establishing the IPSEC level "association context" and the associated key exchanges; using a domain name instead of a distinguished name should just be a special case. Christian Huitema PS. Regarding ASN.1 encodings, etc: once you start dealing with 1024 bits wide exponentiations, T-L-V tagging is pretty much in the noise, so not really worth discussing... From atkinson@itd.nrl.navy.mil Wed Sep 8 05:52:14 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18970 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 09:53:20 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA12924 (InterLock SMTP Gateway 1.1 for ); Wed, 8 Sep 1993 09:46:06 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18977; Wed, 8 Sep 93 09:52:14 EDT Date: Wed, 8 Sep 93 09:52:14 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309081352.AA18977@itd.nrl.navy.mil> To: Christian.Huitema@sophia.inria.fr Subject: Re: Use of DNS to distribute keys Cc: ipsec@ans.net, namedroppers@nic.ddn.mil % 1) If you want to attach a public key to a domain name, you will have to prove % the authority of the certifier on the domain. The classic counter example is % when you receive a certificate signed by "Al Capone, General trades, Chicago, % US" for the domain "lcs.mit.edu". What is needed is what I called "the glue". % There sure are solutions, but you will have to spell them out.. This is the general trust issue associated with the signing authority and is not substantially different from the PEM case. What you are calling the "glue" I had taken as implicit and I suspect that we can reuse some of the good work done by the PEM folks. % 2) The host identifier is not necessarily the "correct" thing to use, even for % a firewall. I may want to grant access to our local network to "Christian % Huitema, INRIA, FR", regardless of where his powerbook happens to be plugged. % It would thus be better to assume that a "classic" certificate is used for % establishing the IPSEC level "association context" and the associated key % exchanges; using a domain name instead of a distinguished name should just be % a special case. I have carefully never talked about access control or any other policy. Nor have I mentioned firewalls. I don't think this is the right forum to get deeply into matters of policy, but my experience is that there are many different policies in the world. I think that different sites and organisations have different threats, concerns, and objectives and so I don't think we will ever converge on a single policy as being appropriate for all sites. My goal is to be able to protect data at lower layers (e.g. IP) during transit between IP-capable hosts, where "protect" means some combination of integrity, authentication, and/or confidentiality. To achieve that goal, I seek to be able to establish shared secrets (keys) between communicating hosts. Having key certificates available for each host that I wish to communicate with/from makes this task easier. For my goal, I believe a domain name is probably the right object. For other goals, other objects might be more appropriate. I have tried to talk in terms of a mechanism to facilitate establishment of host-level session keys. % Regarding ASN.1 encodings, etc: once you start dealing with 1024 bits wide % exponentiations, T-L-V tagging is pretty much in the noise, so not really % worth discussing... I don't think I had raised issues of syntax or encoding, but I don't see any particularly good reason that a host key certificate should use radically different mechanisms than PEM certificates use. I believe there is some potential benefit from reusing technology that is believed to work reasonably well. Ran atkinson@itd.nrl.navy.mil From tardo@tardo.lkg.dec.com Wed Sep 8 18:09:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13315 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 14:10:57 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA11987 (InterLock SMTP Gateway 1.1 for ); Wed, 8 Sep 1993 14:03:46 -0400 Received: by inet-gw-2.pa.dec.com; id AA15221; Wed, 8 Sep 93 11:10:00 -0700 Received: by tardo.lkg.dec.com (5.65/cgg-100491); id AA20830; Wed, 8 Sep 1993 14:09:43 -0400 Message-Id: <9309081809.AA20830@tardo.lkg.dec.com> To: atkinson@itd.nrl.navy.mil, Christian Huitema Cc: ipsec@ans.net, tardo@tardo.lkg.dec.com Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of "Wed, 08 Sep 93 11:05:50 +0200." <199309080905.AA05188@mitsou.inria.fr> Date: Wed, 08 Sep 93 14:09:43 -0400 From: tardo@tardo.lkg.dec.com X-Mts: smtp Keeping certificates in a "lightweight, deployable now, architecture unburdened" parallel name service (to DNS) is a nice idea. So good, in fact, that it's been thought of, implemented, and distributed as freeware already by, in fact, us, as "SPX". Also, SPX uses essentially the same certificate format (modulo some recent signature details), as PEM. See the "DAS" internet drafts Charlie Kaufman authored a while back for certificate and policy models. SPX was based not on DNS but on the Kerberos/Athena model. The certificate server was really more like an "untrusted KDC" thing than a directory service. But, really, for on-line key distribution, by the very nature of the communication, you don't need a name service at all except to find the other guy's network address. Once you have it, just contact a well- known port at the destination and ask for their certificate - even finger would do the trick, as has been suggested before as well. For "DAS-like" policies, you can ask for particular chains of certificates down from those PCAs you trust, for example. If you can't get to their key server application, you can't get to them anyway, so there's no worry about disclosure. The Achilles heel is getting the certificates into the end systems, keeping them refreshed, and making sure they haven't been revoked. You would have this problem in all cases - you need to get the secret thingie into the target system so you know to whom you are talking. This requires some sort of authority infrastructure, mutually acceptable to policies of the particular communicants in question, and there you are, on the slippery slope, so to speak. Of course, you could just go with Diffie-Hellman for traffic key exchange and skip the system-to-system level authentication altogether, just use passwords for user account level access and be done with it. And, this is REALLY usable right now. Furthermore, any protocols that really need authentication, such as mobile-IP, will probably carry their own security exchange fields anyway, or at least will know to design them in. /Joe From dcrocker@Mordor.Stanford.EDU Wed Sep 8 21:25:53 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16561 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 17:27:21 -0400 Received: from Mordor.Stanford.EDU by interlock.ans.net with SMTP id AA06210 (InterLock SMTP Gateway 1.1 for ); Wed, 8 Sep 1993 17:19:37 -0400 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18335; Wed, 8 Sep 93 14:25:53 -0700 Message-Id: <9309082125.AA18335@Mordor.Stanford.EDU> To: ipsec@ans.net Subject: retry Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 Date: Wed, 08 Sep 93 14:25:53 -0700 From: Dave Crocker X-Mts: smtp ------- Forwarded Message Date: Wed, 08 Sep 93 07:35:56 PDT To: dcrocker cc: Postmaster From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: User unknown ----- Transcript of session follows ----- While talking to interlock.ans.net: >>> RCPT To: <<< 550 ... Invalid recipient - Not registered 550 ip-sec@ans.net... User unknown ----- Recipients of this delivery ----- Bounced, cannot deliver: ip-sec@ans.net Sent successfully: kasten@ftp.com atkinson@itd.nrl.navy.mil namedroppers@nic.ddn.mil ----- Unsent message follows ----- Return-Path: Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA14847; Wed, 8 Sep 93 07:35:56 -0700 Message-Id: <9309081435.AA14847@Mordor.Stanford.EDU> To: kasten@ftp.com Cc: atkinson@itd.nrl.navy.mil, ip-sec@ans.net, namedroppers@nic.ddn.mil Subject: Re: Use of DNS to distribute keys Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 08 Sep 93 09:51:12 -0400. <930908135 1.AA18228@ftp.com> Date: Wed, 08 Sep 93 07:35:55 -0700 From: Dave Crocker X-Mts: smtp Frank, ---- Included message: What are the alternatives? Either 1) We use the Domain Name Service protocol for these things or 2) We do not use the Domain Name Service protocol for these things. My intent was merely to suggest running the same software in parallel, listening to a different port. In reality, you see, I would expect the software to end up NOT being the same, since the new port/service would be considerably enhanced. You might actually want, instead, to view this as a transition plan to the new, improved DNS. I don't know. But I'm quite concerned that the current service be kept VERY stable and strongly suspect that the wide range of (very reasonable) uses that are being considered for addition could/will change it. d/ ------- End of Forwarded Message From zben@ni.umd.edu Thu Sep 9 15:23:24 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12550 (5.65c/IDA-1.4.4 for ); Thu, 9 Sep 1993 15:23:24 -0400 Received: from ni.umd.edu by interlock.ans.net with SMTP id AA16107 (InterLock SMTP Gateway 1.1 for ); Thu, 9 Sep 1993 15:15:02 -0400 Received: from zben-mac-ii.umd.edu by ni.umd.edu with SMTP id AA25845 (5.65c/IDA-1.4.4 for ); Thu, 9 Sep 1993 15:21:17 -0400 Date: Thu, 9 September 1993 15:21:16 -0500 From: Charles B Cranston To: ipsec@ans.net, namedroppers@nic.ddn.mi Subject: Re: Use of DNS to distribute keys Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Forgive the "undergraduate question", but why propose using the DNS for this when one could just contact the host in question and ASK for the key/certificate? As I understand it the choice is between: A1: Client asks DNS for IP address of server. A2: Client asks DNS for key/certificate of server. A3: Client does some client-server transaction with server. vs B1: Client asks DNS for IP address of server. B2: Client asks SERVER for key/certificate of server. B3: Client does some client-server transaction with server. For awhile I thought the point was relieving the server of maintaining its PUBLIC key (in the case of really dumb servers like laserprinters or something) but given the fact that the server has to maintain its PRIVATE key in order to evaluate any incoming transaction, it is not really much more expensive for it to maintain its PUBLIC key too, since in current implementations PRIVATE keys are usually somewhat longer than PUBLIC keys. Defining some kind of additional TCP or UDP based protocol by which a client can obtain a public key from a server would also have the advantage of putting control of key policy in the hands of the server. For example, a really high-security server might want to generate a completely new one-time public/private key pair on the fly for every new transaction. The only disadvantage I can see with this is that the server would have to be up and running in order for client to obtain the key information, as opposed to working with the expectation that the omnipresent DNS would "always" be able to give this information. But note: SMTP also requires the destination host to be up and running, we don't really have any store-and-forward protocols running on this network. Am I missing some key point in this? From zben@ni.umd.edu Thu Sep 9 15:29:25 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20241 (5.65c/IDA-1.4.4 for ); Thu, 9 Sep 1993 15:29:25 -0400 Received: from ni.umd.edu by interlock.ans.net with SMTP id AA15462 (InterLock SMTP Gateway 1.1 for ); Thu, 9 Sep 1993 15:22:33 -0400 Received: from zben-mac-ii.umd.edu by ni.umd.edu with SMTP id AA26128 (5.65c/IDA-1.4.4 for ); Thu, 9 Sep 1993 15:28:48 -0400 Date: Thu, 9 September 1993 15:28:46 -0500 From: Charles B Cranston To: ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: Use of DNS to distribute keys Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Please forgive the repost, somehow the "l" got left off of nic.ddn.mil in the first version. Ain't cut-and-paste wonnerful? ======== Forgive the "undergraduate question", but why propose using the DNS for this when one could just contact the host in question and ASK for the key/certificate? As I understand it the choice is between: A1: Client asks DNS for IP address of server. A2: Client asks DNS for key/certificate of server. A3: Client does some client-server transaction with server. vs B1: Client asks DNS for IP address of server. B2: Client asks SERVER for key/certificate of server. B3: Client does some client-server transaction with server. For awhile I thought the point was relieving the server of maintaining its PUBLIC key (in the case of really dumb servers like laserprinters or something) but given the fact that the server has to maintain its PRIVATE key in order to evaluate any incoming transaction, it is not really much more expensive for it to maintain its PUBLIC key too, since in current implementations PRIVATE keys are usually somewhat longer than PUBLIC keys. Defining some kind of additional TCP or UDP based protocol by which a client can obtain a public key from a server would also have the advantage of putting control of key policy in the hands of the server. For example, a really high-security server might want to generate a completely new one-time public/private key pair on the fly for every new transaction. The only disadvantage I can see with this is that the server would have to be up and running in order for client to obtain the key information, as opposed to working with the expectation that the omnipresent DNS would "always" be able to give this information. But note: SMTP also requires the destination host to be up and running, we don't really have any store-and-forward protocols running on this network. Am I missing some key point in this? From kent@BBN.COM Thu Sep 9 20:05:23 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03149 (5.65c/IDA-1.4.4 for ); Thu, 9 Sep 1993 16:06:10 -0400 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA12223 (InterLock SMTP Gateway 1.1 for ); Thu, 9 Sep 1993 15:59:38 -0400 Message-Id: <199309091959.AA12223@interlock.ans.net> To: Charles B Cranston Cc: ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of Thu, 09 Sep 93 15:21:16 -0500. Date: Thu, 09 Sep 93 16:05:23 -0400 From: Steve Kent Charles, There are several issues associated with certificate storage and retrieval. For realtime protocols, it is reasonable to assume that the target of a connection request is available and getting the target's certificate from the target seems reasonable. You may really need more than just the target's certificate, e.g., a full certification path to the target and CRLs for each CA along that path. Still, all of this could be storged by the target and provided to any requestor. However, for a protocol such as email, the sender's machine and the recipients' machines need not all be avilable at the same time, and this model is not quite so attractive. Also, because email is typically multicast (at the application level), having to retrieve certification paths and CRLs from all the recipient's hosts may be quite burdensome. So, in that circumstance, having a set of repositories, e.g., directories, for this data is more attractive. Moreover, if you had to connect to a directory for name->address mapping anyway, getting the certificate information at the same time seems fairly efficient. Finally, there is the question of how you search for the requisite certificate data. The DNS, as a directory system, is very restrictive and it requires you to know the precise name of the target of your request. This is adequate for its role in simple name/address mapping for computers, but only because people perform the harder task of mapping real world attributes into DNS names by external means. For an email system, where the targets are people, not machines, we use additional directory services like whois. One could argue that the right place to store certificates for email users in in their whois entries. Unfortunately the whois systems is not so comprehensive, so well distributed, or so well maintained as the DNS. I believe the question that precipitated this discussion came from someone who posed it in the context of certificates for machines, not for people, in which case DNS names are reasonable search indices and the DNS would be an ideal repository, except for the size limitation on UDP transactions cited earlier. Steve From tardo@tardo.lkg.dec.com Fri Sep 10 13:51:02 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07729 (5.65c/IDA-1.4.4 for ); Fri, 10 Sep 1993 10:11:20 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA11085 (InterLock SMTP Gateway 1.1 for ); Fri, 10 Sep 1993 10:01:14 -0400 Received: by inet-gw-2.pa.dec.com; id AA03078; Fri, 10 Sep 93 06:51:16 -0700 Received: by tardo.lkg.dec.com (5.65/cgg-100491); id AA23476; Fri, 10 Sep 1993 09:51:02 -0400 Message-Id: <9309101351.AA23476@tardo.lkg.dec.com> To: Steve Kent Cc: Charles B Cranston , ipsec@ans.net, namedroppers@nic.ddn.mil, tardo@tardo.lkg.dec.com Subject: Re: Use of DNS to distribute keys In-Reply-To: Your message of "Thu, 09 Sep 93 16:05:23 EDT." <199309091959.AA12223@interlock.ans.net> Date: Fri, 10 Sep 93 09:51:02 -0400 From: tardo@tardo.lkg.dec.com X-Mts: smtp Steve: >>I believe the question that precipitated this discussion came >>from someone who posed it in the context of certificates for machines, >>not for people Actually, the context was in setting up end-end (rather than store-and- forward) data protection keys, in which case not storing certificates in the DNS seems to make more sense. One very big advantage, by the way, is that there is less state in directory services to keep accurate and synchronized, the most difficult part of a nameserver-based certificate distribution scheme being the practical one of ongoing maintenance. Note that DNS has no notion of self-administration, as X.500 access controls support, even if your policy would accommodate this sort of thing. Now, how about simply defining a (publicly readable, usually) MIB for this so that keys could be accessed (and even remotely managed) without inventing new protocol, using SNMP? /Joe From zben@ni.umd.edu Fri Sep 10 14:59:40 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07715 (5.65c/IDA-1.4.4 for ); Fri, 10 Sep 1993 14:59:40 -0400 Received: from ni.umd.edu by interlock.ans.net with SMTP id AA12366 (InterLock SMTP Gateway 1.1 for ); Fri, 10 Sep 1993 14:32:36 -0400 Received: from zben-mac-ii.umd.edu by ni.umd.edu with SMTP id AA05136 (5.65c/IDA-1.4.4 for ); Fri, 10 Sep 1993 14:38:49 -0400 Date: Fri, 10 September 1993 14:38:49 -0500 From: Charles B Cranston To: Steve Kent Subject: Re: Use of DNS to distribute keys Cc: ipsec@ans.net, namedroppers@nic.ddn.mil Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Steve: As pointed out earlier, the DNS UDP size limitation and the largeish and growing size of modern certificates probably make it unrealistic to support DNS-based certificate distribution, at least with current implementations. Perhaps throwing in email has been a complicating factor, not only because of the MX driven store-and-forward stuff, but because now we are authenticating people rather than net hosts. It has been obvious for some time that the Internet canonical "user@host.domain" paradigm for person-identification is breaking down. This scheme made a great deal of sense when there were a few dozen well-known large mainframes with many users on each, but it gets strained when we move to personal machines where the "host.domain" part identifies the owner as well as the machine and if "user" is used at all it is used to identify functional entities within that personal machine. As a consequence we have "kluged" it by making the "host.domain" part of email addresses specify an entire community of users (like BBN.COM) and we use the MX mechanism to store-and-forward the mail to the appropriate workstation or repository. A byproduct of this is that we can deal nicely with workstations being turned off at night and with people reading their mail from more than one workstation. While this is a Good Thing (and I use both these features myself) the fact remains that "user@host.domain" might not be the best email addressing paradigm for the current network environment. We might need to generalize the identifier problem to the idea of a Network Visible Entity (NVE) and then define new protocols in order to extract things like email routing information from them. If we do this, obtaining any needed email certificates would more correctly be a function of these new protocols than patching it into a database keyed on host name like the DNS. Unfortunately this is beginning to sound like X.500... From mohta@necom830.cc.titech.ac.jp Sat Sep 11 09:58:35 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21136 (5.65c/IDA-1.4.4 for ); Sat, 11 Sep 1993 09:58:35 -0400 Received: from necom830.cc.titech.ac.jp by interlock.ans.net with SMTP id AA13630 (InterLock SMTP Gateway 1.1 for ); Sat, 11 Sep 1993 09:51:07 -0400 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 11 Sep 93 22:53:17 +0900 From: Masataka Ohta Return-Path: Message-Id: <9309111353.AA08282@necom830.cc.titech.ac.jp> Subject: Re: Use of DNS to distribute keys To: zben@ni.umd.edu (Charles B Cranston) Date: Sat, 11 Sep 93 22:53:16 JST Cc: kent@BBN.COM, ipsec@ans.net, namedroppers@nic.ddn.mil In-Reply-To: ; from "Charles B Cranston" at Sep 10, 93 2:38 pm X-Mailer: ELM [version 2.3 PL11] > As pointed out earlier, the DNS UDP size limitation and the > largeish and growing size of modern certificates probably make > it unrealistic to support DNS-based certificate distribution, > at least with current implementations. Though a single 1024 bit entity will fit in a UDP packet, use TCP with current DNS implementations, if it will be much larger. TCP is not so heavy compared to the modern complex certificate. It's only as heavy as TCP SMTP connection. > Perhaps throwing in email has been a complicating factor, > not only because of the MX driven store-and-forward stuff, but > because now we are authenticating people rather than net hosts. Authentication of mail receiving people will be done by each mail server host if hosts are authenticated. > It has been obvious for some time that the Internet canonical > "user@host.domain" paradigm for person-identification is > breaking down. This scheme made a great deal of sense when > there were a few dozen well-known large mainframes with many > users on each, but it gets strained when we move to personal > machines where the "host.domain" part identifies the owner as > well as the machine and if "user" is used at all it is used to > identify functional entities within that personal machine. So, the public key of the "user@host.domain" for mail will be asked to the MX pointee of "host.domain" outside of SMTP or during the SMTP connection. > As a consequence we have "kluged" it by making the "host.domain" > part of email addresses specify an entire community of users > (like BBN.COM) and we use the MX mechanism to store-and-forward > the mail to the appropriate workstation or repository. By asking the public key of the user only to the host of least MX preference value, or only to hosts with MX preference values of less than, say, 100 or by having a new RR type to point to authentication host, the store-and-forward will still work. > "user@host.domain" > might not be the best email addressing > paradigm for the current network environment. I disagree. > We might need to generalize the identifier problem to the > idea of a Network Visible Entity (NVE) and then define new > protocols in order to extract things like email routing > information from them. If we do this, obtaining any needed > email certificates would more correctly be a function of > these new protocols than patching it into a database keyed > on host name like the DNS. Wrong. The key of DNS is a domain name not necessarily a host name. It is MX which points to the mail server hosts for the domain name. Masataka Ohta From mohta@necom830.cc.titech.ac.jp Mon Sep 13 05:46:24 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16344 (5.65c/IDA-1.4.4 for ); Mon, 13 Sep 1993 05:46:24 -0400 Received: from necom830.cc.titech.ac.jp by interlock.ans.net with SMTP id AA12382 (InterLock SMTP Gateway 1.1 for ); Mon, 13 Sep 1993 05:38:42 -0400 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 13 Sep 93 18:06:37 +0900 From: Masataka Ohta Return-Path: Message-Id: <9309130906.AA13576@necom830.cc.titech.ac.jp> Subject: Re: Use of DNS to distribute keys To: tardo@tardo.lkg.dec.com Date: Mon, 13 Sep 93 18:06:36 JST Cc: kent@BBN.COM, zben@ni.umd.edu, ipsec@ans.net, namedroppers@nic.ddn.mil In-Reply-To: <9309101351.AA23476@tardo.lkg.dec.com>; from "tardo@tardo.lkg.dec.com" at Sep 10, 93 9:51 am X-Mailer: ELM [version 2.3 PL11] > Actually, the context was in setting up end-end (rather than store-and- > forward) data protection keys, > Now, how about simply defining a (publicly readable, usually) MIB for this > so that keys could be accessed (and even remotely managed) without inventing > new protocol, using SNMP? Why we need encryption here for the end-end communication? Because the IP layer is unreliable. Some malicious intermediate host may pretend to be the end host. The problem with MIB is that the public key obtained through MIB through malicious intermediate hosts is just as unreliable as the IP layer. What we need for the globaly authenticated communication is an authenticated tree structure of servers to provide reliable public keys, which could be a variation of DNS. Masataka Ohta From dee@skidrow.lkg.dec.com Tue Sep 14 19:46:58 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17693 (5.65c/IDA-1.4.4 for ); Tue, 14 Sep 1993 16:21:23 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA05045 (InterLock SMTP Gateway 1.1 for ); Tue, 14 Sep 1993 16:09:32 -0400 Received: by inet-gw-2.pa.dec.com; id AA19479; Tue, 14 Sep 93 12:46:59 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA11187 for namedroppers@nic.ddn.mil; Tue, 14 Sep 93 15:46:58 -0400 Message-Id: <9309141946.AA11187@skidrow.lkg.dec.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: Your message of "Tue, 07 Sep 93 09:13:26 EDT." <9309071313.AA29637@itd.nrl.navy.mil> Date: Tue, 14 Sep 93 15:46:58 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net, namedroppers@nic.ddn.mil > For several years now I've been thinking that the DNS is >probably a really good way to distribute keys (or key certificates). >For example, if each host had a public key accessible via the DNS, one >could more easily setup a secure session key between oneself and the >remote host that one wished to communicate with. Also, one might be >able to encrypt UDP packets using asymmetric encryption for the odd >case where one only wanted to send one or two packets and thereby >avoid the overhead of setting up a session key for extremely brief >sessions. This is a great idea I have also had myself. Key certificates are generally too big and clunky to be in DNS but public keys would work fine. There is no reason for the keys stored in DNS to be embedded in a certificate because you can use secure communication with the DNS server based on the key from the next highest level in the DNS hierarchy. Caching these keys is kind of like caching IP address info. All you need to complete the picture is to magicly know (or get via an e-mailed certificate or something) the public keys of the root DNS servers. Its not clear to me that UDP and similar datagram protocols are so rare and some such packets (consider ICMP, IGMP, etc) are very important to be able to at least authenticate.. Furthermore, it would be very useful to authenticate the source of multicast messages where a negotiated "session" key is impractical. The most obvious extention to encrypting multicast traffic would require putting the multicast IP address in DNS (are number are in there already) and all the receivers authorized to get the traffic knowing the private key. Assume you have an IP security protocol with SAIDs (security association IDs). Mostly these would be for negotiated TCP like exchanges with a session key, etc. But you should permantently allocate some "global" SAIDs to mean a particular algorithm family with particular non-negotiated keys such as from DNS. Note that you might even want to use such global SAID authenticated/encrypted packects as the initial packets in setting up a negoitated SAID so that *none* of your packets are in the clear. >... >Thanks, >Ran >atkinson@itd.nrl.navy.mil >To: atkinson@itd.nrl.navy.mil (Ran Atkinson) >Subject: Re: Use of DNS to distribute keys >Date: Tue, 07 Sep 93 09:56:59 -0700 >From: Dave Crocker > > ---- Included message: > > For several years now I've been thinking that the DNS is > probably a really good way to distribute keys (or key certificates). > >Let me ask a related question: > >One of the marks of distinction about the DNS, relative to X.500, DEC's >Name Service, OSF's Cell Directory Service, and most discussions about >network use of directory service, is that is is used in very, very >limited ways. I suspect that limiting the use to name/address >mapping has been instrumental in making it feasible to rely on >DNS access as part of the operational infrastructure. It is also used for name/name mapping but I agree entirely that the success of DNS, like many IETF protocols, is based on aiming at a relatively narrow goal. But it seems to me that for secure host-to-host communications via a public key system, DNS is on target. A 1024 bit RSA key, which most people consider secure, is only 128 bytes. An appropriate RSA digital signature is going to be about the same size. I guess I should do the detailed arithmetic but it seems to me like a public key containing DNS response should fit into the DNS 512 bytes UDP limit. >... >Dave >To: Dave Crocker >Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), namedroppers@nic.ddn.mil, > ipsec@ans.net >Subject: Re: Use of DNS to distribute keys >Date: Tue, 07 Sep 1993 12:33:49 -0600 >From: Brad Huntting > >I dont see anything wrong with putting more "host related information" >in DNS. What's dangerous is to try to extend the idea "domain >name" to include more than just "things with IP addresses", "things >that appear after the @ in email addresses", and "administrative >breakpoints". > >In other words, it might be risky to add PEM information to DNS, >but it would probably not be risky to ad IP security information >to DNS. I agree. >brad Donald From Russ_Housley.McLean_CSD@xerox.com Tue Sep 14 10:54:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21068 (5.65c/IDA-1.4.4 for ); Tue, 14 Sep 1993 20:55:16 -0400 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA08201 (InterLock SMTP Gateway 1.1 for ); Tue, 14 Sep 1993 20:48:19 -0400 Received: from XNS-XDMS_Gateway.XSIS.Xerox.xns by alpha.xerox.com via XNS id <12081(5)>; Tue, 14 Sep 1993 17:54:19 PDT X-Ns-Transport-Id: 0000AA00499C5E793001 Date: Tue, 14 Sep 1993 17:54:05 PDT From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: <9309141946.AA11187@skidrow.lkg.dec.com> To: dee@skidrow.lkg.dec.com Cc: ipsec@ans.net, namedroppers@nic.ddn.mil Message-Id: <"14-Sep-93 17:53:59".*.Russ_Housley.McLean_CSD@Xerox.com> Donald: >Assume you have an IP security protocol with SAIDs (security >Association IDs). Mostly these would be for negotiated TCP like >exchanges with a session key, etc. But you should permantently >allocate some "global" SAIDs to mean a particular algorithm family >with particular non-negotiated keys such as from DNS. Note that you >might even want to use such global SAID authenticated/encrypted >packects as the initial packets in setting up a negoitated SAID so >that *none* of your packets are in the clear. IEEE Std 802.10-1992 defines the Secure Data Exchange (SDE) protocol. The SAIDs defined in this standard use the high order bit to to distinguish between pairwise and multicast security associations. Personally, I would like to see this convention adopted everywhere so that one securiy association manager (or cryptographic key manager) can be used regardless of the lower layer security protocol that is using the security association. Russ From ipsec-request@ans.net Thu Sep 16 09:23:34 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18080 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 09:23:34 -0400 Received: by interlock.ans.net id AA14332 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 09:12:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 09:12:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 09:12:48 -0400 From: Masataka Ohta Return-Path: Message-Id: <9309161314.AA28609@necom830.cc.titech.ac.jp> Subject: Re: [resend] Use of DNS to distribute keys To: dee@skidrow.lkg.dec.com (Beast) Date: Thu, 16 Sep 93 22:14:39 JST Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, namedroppers@nic.ddn.mil In-Reply-To: <9309141946.AA11187@skidrow.lkg.dec.com>; from "Beast" at Sep 14, 93 3:46 pm X-Mailer: ELM [version 2.3 PL11] > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > To: ipsec@ans.net, namedroppers@nic.ddn.mil > > For several years now I've been thinking that the DNS is > >probably a really good way to distribute keys (or key certificates). > >For example, if each host had a public key accessible via the DNS, one > >could more easily setup a secure session key between oneself and the > >remote host that one wished to communicate with. Also, one might be > >able to encrypt UDP packets using asymmetric encryption for the odd > >case where one only wanted to send one or two packets and thereby > >avoid the overhead of setting up a session key for extremely brief > >sessions. > > This is a great idea I have also had myself. Key certificates are > generally too big and clunky to be in DNS but public keys would work > fine. There is no reason for the keys stored in DNS to be embedded in > a certificate because you can use secure communication with the DNS > server based on the key from the next highest level in the DNS > hierarchy. Caching these keys is kind of like caching IP address > info. This, obviously, is the way to go. So I have surprised to have received private mails saying that we don't need secure DNS because we have key certificate mechanism. Some people does not understand that key certificate mechanism does not scale unless a tree of servers are formed. > All you need to complete the picture is to magicly know (or get > via an e-mailed certificate or something) the public keys of the root > DNS servers. And, as we need public keys to construct the DNS tree, we don't need any key certificates of servers. > A 1024 bit RSA key, which most people consider secure, is only 128 > bytes. An appropriate RSA digital signature is going to be about the > same size. I guess I should do the detailed arithmetic but it seems > to me like a public key containing DNS response should fit into the > DNS 512 bytes UDP limit. I have found a exception. A reply packet for NS query will contain, as glue information, addresses AND public keys of multiple name servers. Thus the 512 bytes limit does matter if there is three name servers with glue information (quite common). It should be noted that the NS reply for the root name servers has once exceeded the UDP limit even without any public keys. So, if we must extend UDP size limit or must use TCP. Masataka Ohta From ipsec-request@ans.net Thu Sep 16 05:23:53 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19805 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 10:43:45 -0400 Received: by interlock.ans.net id AA15799 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 10:32:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Sep 1993 10:32:38 -0400 Return-Path: Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 10:32:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 10:32:38 -0400 Message-Id: <9309161418.AA19936@smiley.mitre.org.sit> Date: Thu, 16 Sep 93 10:23:53 EST From: shirey@smiley.mitre.org (Robert W. Shirey) To: atkinson@itd.nrl.navy.mil Subject: Re: [resend] Use of DNS to distribute keys Cc: dee@skidrow.lkg.dec.com (Beast), ipsec@ans.net, namedroppers@nic.ddn.mil, pem-dev@tis.com, Masataka Ohta Until now, the following message thread has not been copied to pem-dev. It should be, I think, because it calls into question the need for certificates to distribute public keys in the Internet. In the following message from Masatak Ohta, there is included a quote from, I believe, Ran Atakinson: > > Key certificates are > > generally too big and clunky to be in DNS but public keys would work > > fine. There is no reason for the keys stored in DNS to be embedded in > > a certificate because you can use secure communication with the DNS > > server based on the key from the next highest level in the DNS > > hierarchy. ... Caching keys is kind of like caching IP address info. Unless I entirely misunderstand this thread, he is saying that the DNS can be trusted to maintain the binding between my host's public key and my host's name--WITHOUT using a signed certificate. Before I die choking on my morning coffee, I would like to know something: What assurance features and mechanisms does Ran propose to use to make us trust all the servers in the worldwide DNS system that much? ------------------------------------------------------------------------------------------ > From: Masataka Ohta > Return-Path: > Subject: Re: [resend] Use of DNS to distribute keys > To: dee@skidrow.lkg.dec.com (Beast) > Date: Thu, 16 Sep 93 22:14:39 JST > Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, namedroppers@nic.ddn.mil > In-Reply-To: <9309141946.AA11187@skidrow.lkg.dec.com>; from "Beast" at Sep 14, 93 3:46 pm > X-Mailer: ELM [version 2.3 PL11] > X-Mdf: Mail for shirey sent to shirey@smiley.mitre.org > > > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > > To: ipsec@ans.net, namedroppers@nic.ddn.mil > > > For several years now I've been thinking that the DNS is > > >probably a really good way to distribute keys (or key certificates). > > >For example, if each host had a public key accessible via the DNS, one > > >could more easily setup a secure session key between oneself and the > > >remote host that one wished to communicate with. Also, one might be > > >able to encrypt UDP packets using asymmetric encryption for the odd > > >case where one only wanted to send one or two packets and thereby > > >avoid the overhead of setting up a session key for extremely brief > > >sessions. > > > > This is a great idea I have also had myself. Key certificates are > > generally too big and clunky to be in DNS but public keys would work > > fine. There is no reason for the keys stored in DNS to be embedded in > > a certificate because you can use secure communication with the DNS > > server based on the key from the next highest level in the DNS > > hierarchy. Caching these keys is kind of like caching IP address > > info. > > This, obviously, is the way to go. So I have surprised to have received > private mails saying that we don't need secure DNS because we have key > certificate mechanism. > > Some people does not understand that key certificate mechanism does not > scale unless a tree of servers are formed. > > > All you need to complete the picture is to magicly know (or get > > via an e-mailed certificate or something) the public keys of the root > > DNS servers. > > And, as we need public keys to construct the DNS tree, we don't need > any key certificates of servers. > > > A 1024 bit RSA key, which most people consider secure, is only 128 > > bytes. An appropriate RSA digital signature is going to be about the > > same size. I guess I should do the detailed arithmetic but it seems > > to me like a public key containing DNS response should fit into the > > DNS 512 bytes UDP limit. > > I have found a exception. A reply packet for NS query will contain, as > glue information, addresses AND public keys of multiple name servers. > Thus the 512 bytes limit does matter if there is three name servers with > glue information (quite common). > > It should be noted that the NS reply for the root name servers has > once exceeded the UDP limit even without any public keys. > > So, if we must extend UDP size limit or must use TCP. > > Masataka Ohta > > From ipsec-request@ans.net Thu Sep 16 07:17:49 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13202 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 11:19:01 -0400 Received: by interlock.ans.net id AA15941 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 11:11:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 11:11:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 11:11:45 -0400 Date: Thu, 16 Sep 93 11:17:49 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309161517.AA01563@itd.nrl.navy.mil> To: shirey@smiley.mitre.org Subject: Re: Use of DNS to distribute keys Cc: ipsec@ans.net, namedroppers@nic.ddn.mil, pem-dev@tis.com Rob, Before you choke on your morning coffee, the quote you cite is NOT from me. I want to use Key Certificates rather than raw keys and I see a number of infrastructure/deployment problems with building trust mechanisms into each and every DNS server. From my very first note *I* have been talking about key certificates. I believe the quote you cite is from Ohta-san. Rest confident that I am VERY worried about assurance in information systems. I work in the Center for High Assurance Computing Systems at NRL and we at NRL are basically sceptics about anything less than B3 kinds of assurance in trusted systems. Our running comment when vendors visit us is "it might be trusted but is it really TRUSTWORTHY ?". I have pondered the deployment of authentication into an internet in some previous research. I do see the approach Ohta-san advocates as one that is interesting. Based on my research and some experimentation, I have concluded that key certificates are the only way to get reasonable kinds of assurance and to make widespread deployment practical. In particular, I would like to try to reuse the key certificate infrastructure being developed and deployed for PEM if at all possible. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Sep 16 17:53:00 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18659 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 12:56:20 -0400 Received: by interlock.ans.net id AA04803 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 12:48:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Sep 1993 12:48:04 -0400 Return-Path: Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 12:48:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 12:48:04 -0400 Message-Id: <9309161647.AA29200@smiley.mitre.org.sit> Date: Thu, 16 Sep 1993 12:53:00 -0500 To: ipsec@ans.net, namedroppers@nic.ddn.mil, pem-dev@tis.com From: shirey@mitre.org (Robert W. Shirey) X-Sender: shirey@128.29.140.20 Subject: Re: [resend] Use of DNS to distribute keys I said: >Unless I entirely misunderstand this thread, he is saying that the >DNS can be trusted to maintain the binding between my host's public >key and my host's name--WITHOUT using a signed certificate. Before I >die choking on my morning coffee, I would like to know something: >What assurance features and mechanisms [are proposed] to >make us trust all the servers in the worldwide DNS system that much? Someone replied privately to me: >If I read him correctly, he's assuming a trusted connection to a server >which has been vouched for by some other trusted server, over a trusted >connection. That setup is equivalent to a certificate hierarchy but with >trusted, encrypted channels over which you learn keys substituting for >signatures of those keys. ... >I'm not pushing this system -- just trying to read his message and answer >your question. That was not my question. My question was What assurance features or mechanisms are going to be used throughout the DNS that will make all of us trust all of those servers for all of our applications? Are we going to mandate that all DNS nodes must satisfy TCSEC Class B3; be locked in ISOC certified, inspected, and bonded rooms; receive keys only via notary publics and registered mail; have all mass storage encrypted for integrity; etc.? No, we aren't. The only reasonable way to guarantee the integrity of public keys stored in the heterogeneous systems of untrusted DNS servers, or in any other distributed directory system, is to have them stored in unforgeable signed certificates, as defined, for example, in X.509. Regards, -Rob- Robert W. Shirey, The MITRE Corporation, Mail Stop Z202 7525 Colshire Drive, McLean, Virginia 22102-3481 USA shirey@mitre.org * tel 703.883.7210 * fax 703.883.1397 From ipsec-request@ans.net Thu Sep 16 09:20:22 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18156 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 13:26:11 -0400 Received: by interlock.ans.net id AA04017 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 13:14:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 13:14:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 13:14:11 -0400 Date: Thu, 16 Sep 93 13:20:22 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309161720.AA05642@itd.nrl.navy.mil> To: ipsec@ans.net, namedroppers@nic.ddn.mil, pem-dev@tis.com, shirey@mitre.org Subject: Re: Use of DNS to distribute keys Again, please note that the "he" in Rob Shirey's note is NOT me. :-) I would propose that we consider distributing key certificates for host computers using the normal DNS without adding any special mechanisms to the DNS other than maybe a new resource record. In my discussions, I place trust in the cryptographic mechanisms behind the key certificates and not in the network or the end computer systems or the DNS servers. Someone has pointed out a potential problem with size of a key certificate being possibly larger than the DNS is currently setup to handle. This potential problem should be explored further with the DNS experts. I'd also like to note that my discussion has been deliberately limited to key certificates for hosts, not for persons. The key certificates for people is properly handled using the PEM approach. The value in host key certificates is for the case where one deploys some kind of IP Security Protocol (e.g. SP3) or some kind of IP authentication mechanism. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Sep 16 10:59:14 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19314 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 15:06:35 -0400 Received: by interlock.ans.net id AA12411 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 14:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Sep 1993 14:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 14:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 14:53:09 -0400 Message-Id: <9309161859.AA14776@toxicwaste.MEDIA.MIT.EDU> To: "Robert W. Shirey" Cc: ipsec@ans.net, namedroppers@nic.ddn.mil, pem-dev@tis.com Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: Your message of Thu, 16 Sep 93 12:53:00 -0500. <9309161647.AA29200@smiley.mitre.org.sit> Date: Thu, 16 Sep 93 14:59:14 EDT From: Derek Atkins > That was not my question. My question was > > What assurance features or mechanisms are going to be used > throughout the DNS that will make all of us trust all of > those servers for all of our applications? It doesn't matter. You take the certificate you get back from the server and do a cryptographic check back to the root key. That is a known problem (How do you trust a key that someone sends to you in the mail anyways? Same method!) The biggest problem, currently, is getting DNS to deliver such large pieces of data. That seems to be the more pressing problem. We solved certificate verification in the creation of certificates. -derek Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Secretary, MIT Student Information Processing Board (SIPB) warlord@MIT.EDU PP-ASEL N1NWH From ipsec-request@ans.net Fri Sep 17 00:13:15 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03149 (5.65c/IDA-1.4.4 for ); Thu, 16 Sep 1993 20:15:27 -0400 Received: by interlock.ans.net id AA15180 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Sep 1993 20:09:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Sep 1993 20:09:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Sep 1993 20:09:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Sep 1993 20:09:04 -0400 Message-Id: <199309170013.AA03291@misc.glarp.com> To: Derek Atkins Cc: "Robert W. Shirey" , ipsec@ans.net, namedroppers@nic.ddn.mil, pem-dev@tis.com Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: Your message of "Thu, 16 Sep 1993 14:59:14 EDT." <9309161859.AA14776@toxicwaste.MEDIA.MIT.EDU> Date: Thu, 16 Sep 1993 18:13:15 -0600 From: Brad Huntting > [....] You take the certificate you get back from the server and do a > cryptographic check back to the root key. That is a known problem (How > do you trust a key that someone sends to you in the mail anyways? Same > method!) > The biggest problem, currently, is getting DNS to deliver such large > pieces of data. That seems to be the more pressing problem. We solved > certificate verification in the creation of certificates. An IP security protocol will (in some cases) facilitate trusted communications between host pairs. Since the traffic between host pairs is typically identified by address pairs in the IP header, it makes sense to authenticate based on IP address. So when the time comes to obtain a remote hosts certificate for IPSP, the local host as already obtained it's address Just ask the remote host for it's IP certificate, certificate chain, or partial certificate chain as part of an IP security negotiation. Key management is another issue. The process of address allocation on the Internet is generally one where network providers or administrators glom large chunks of address space and parcel them out to smaller administrators and finally to individual hosts. A certificate chain for an IP addresses should follow similar lines with each subnet authority vouching for the addresses directly below it. For this to work, each IP certificate will need to reference it's parent address space and each host should be prepared to offer a (partial) certificate chain. For example: Host A [130.13.16.5] wishes to establish an authenticated confidential communications channel with Host B [128.138.240.1]. It composes a message which says something like this: Hi 128.138.240.1, I'm 130.13.16.5 I will do these IPSP methods (in order of preference): RSA IDEA EDE2 MD5 (integrity check using shared key) Here's my RSA certificate chain: 130.13.16.5/32 [public key] expires 1/12/1993 - signed by 130.13.16.0/24 130.13.16.0/24 [public key] expires 1/10/1995 - signed by 130.13.0.0/16 130.13.0.0/16 [public key] expires 1/1/2001 - signed by 0.0.0.0/0 The remote machine also supports RSA and so verifies the first hosts certificate chain. It picks one of the shared key/integrity check methods supported by the first host and responds with something like this: Hi 130.13.16.5, I'm 128.138.240.1 Here is an RSA encrypted random number (for you): [random key] Do this IPSP method: IDEA From here on, all data is encrypted using IDEA with the least significant 128 bits of the "random key". It may be beneficial to break out the negotiation into separate parts (key exchange methods, shared key methods, digital signature methods), but care should be taken to avoid unnessesary chit chat since this will drastically impact TCP setup time. For a performance boost, systems could piggy back the TCP SYN and ACK/SYN packets along with the IPSP negotiation messages for faster TCP setup. This would suggest using an IP option as opposed to an encapsulation method. On the other hand, encapsulation would seem to be a better way to link subnet's together. Comments? brad From ipsec-request@ans.net Fri Sep 17 20:30:10 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18250 (5.65c/IDA-1.4.4 for ); Fri, 17 Sep 1993 16:49:54 -0400 Received: by interlock.ans.net id AA06758 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Sep 1993 16:25:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 17 Sep 1993 16:25:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Sep 1993 16:25:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Sep 1993 16:25:34 -0400 Message-Id: <9309172030.AA22224@abyss.zk3.dec.com> To: pem-dev@tis.com, ipsec@ans.net, namedroppers@nic.ddn.mil Cc: kaufman@zk3.dec.com Subject: Re: [resend] Use of DNS to distribute keys Date: Fri, 17 Sep 93 16:30:10 -0400 From: kaufman@zk3.dec.com X-Mts: smtp This discussion came late to pem-dev, and it could be I'm missing some crucial context. But let me throw in some thoughts: 1) There is little to be gained by storing certificates of on-line entities in DNS because it is just as easy to ask the entity for its certificate(s). Part of the process of upgrading a system to support authentication could be to install a simple little service (or modifying some existing one) to return certificates on demand. but... 2) If you wanted to store certificates in DNS and were concerned about their length, be aware that certificates are big only because their designers had no motivation to make them small. The critical information in a certificate is a public key (which for 512 bit RSA and a fixed public exponent could be 64 bytes), a signature (also 64 bytes), and an expiration (which could be two bytes if people were ambitious). The signature must be computed over the name being certified but since that is encoded elsewhere need not be stored as part of the certificate. This encoding excludes ASN.1 encodings and object identifiers for compatibility for future designs. DNS could handle 130 bytes and even a few more for some measure of future migration and additional features. As noted in (1), I don't think this is necessary, but if this were all that were standing in the way of an otherwise sound scheme, it could be done. --Charlie (kaufman@zk3.dec.com) From ipsec-request@ans.net Fri Sep 17 21:24:57 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13784 (5.65c/IDA-1.4.4 for ); Fri, 17 Sep 1993 17:42:46 -0400 Received: by interlock.ans.net id AA08389 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Sep 1993 17:19:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 17 Sep 1993 17:19:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Sep 1993 17:19:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Sep 1993 17:19:27 -0400 Message-Id: <199309172124.AA04963@misc.glarp.com> To: ipsec@ans.net Subject: draft spec and pilot implementation Date: Fri, 17 Sep 1993 15:24:57 -0600 From: Brad Huntting From the ipsec charter on nic.ddn.mil: > Jul 93 Post as an Interenet-Draft the specification for Internet Key > Management. Was this completed? If so, where can I find it? > Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update > Protocol as needed. Who is workig on this, and how far are you? thanx, brad From ipsec-request@ans.net Fri Sep 17 21:40:52 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05250 (5.65c/IDA-1.4.4 for ); Fri, 17 Sep 1993 18:02:07 -0400 Received: by interlock.ans.net id AA11815 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Sep 1993 17:37:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 17 Sep 1993 17:37:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 17 Sep 1993 17:37:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Sep 1993 17:37:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Sep 1993 17:37:35 -0400 Message-Id: <9309172140.AA24688@snark.lehman.com> To: pem-dev@tis.com, ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: Your message of "Fri, 17 Sep 1993 16:30:10 EDT." <9309172030.AA22224@abyss.zk3.dec.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 17 Sep 1993 17:40:52 -0400 From: "Perry E. Metzger" kaufman@zk3.dec.com says: > This discussion came late to pem-dev, and it could be I'm missing some > crucial context. But let me throw in some thoughts: > > 1) There is little to be gained by storing certificates of on-line > entities in DNS because it is just as easy to ask the entity for its > certificate(s). But HOW do you ask the entities for their certificates? DNS is a nice existing mechanism by which you can do the asking. > 2) If you wanted to store certificates in DNS and were concerned about > their length, be aware that certificates are big only because their > designers had no motivation to make them small. The critical > information in a certificate is a public key (which for 512 bit RSA and > a fixed public exponent could be 64 bytes), a signature (also 64 > bytes), and an expiration (which could be two bytes if people were > ambitious). Make it into a 1024 bit key, the minimum you need for real security, add a signature, add IDENTITY information on the key and signature, and you are pushing over the line. Perry From ipsec-request@ans.net Sun Sep 19 09:56:35 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19049 (5.65c/IDA-1.4.4 for ); Sun, 19 Sep 1993 14:23:27 -0400 Received: by interlock.ans.net id AA17708 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 19 Sep 1993 13:51:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 19 Sep 1993 13:51:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 19 Sep 1993 13:51:45 -0400 Date: Sun, 19 Sep 93 13:56:35 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309191756.AA21783@itd.nrl.navy.mil> To: huntting@glarp.com, ipsec@ans.net Subject: Re: draft spec and pilot implementation There is no consensus on what the IP Security Protocol should look like. There are at least 3 serious contenders. I am told that part of the US DoD is funding development of IP/NLSP implementations. A trio of researchers in the private sector have already developed a prototype called "swIPe". The SP3 security protocol is commercially available now (as in the US Navy uses SP3 daily to protect sensitive traffic). There are no known Internet Drafts of any sort relating to the IP Security work, at least to my knowledge/recollection. This is clearly a serious standards process problem in this working group because lack of I-Ds (and the de facto reliance on sundry NIST and ISO specs) makes the process less open to peer review on the Internet and is not normal IETF procedure. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Sep 20 14:01:59 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13146 (5.65c/IDA-1.4.4 for ); Mon, 20 Sep 1993 10:16:09 -0400 Received: by interlock.ans.net id AA13819 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Sep 1993 10:06:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Sep 1993 10:06:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Sep 1993 10:06:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Sep 1993 10:06:39 -0400 Message-Id: <9309201402.AA02037@abyss.zk3.dec.com> To: pmetzger@lehman.com Cc: pem-dev@tis.com, ipsec@ans.net, namedroppers@nic.ddn.mil, kaufman@zk3.dec.com Subject: Re: [resend] Use of DNS to distribute keys Date: Mon, 20 Sep 93 10:01:59 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >Make it into a 1024 bit key, the minimum you need for real security, I couldn't let this pass. With our current knowledge, 1024 is about the maximum useful RSA key size, not the minimum. 512 bits is plenty for most uses. It is roughly where DES was 15 years ago: perhaps NSA can afford to break it but no one else can. If you're worried about NSA, 640 bits is entirely adequate unless they know some mathematics the rest of us don't. 1024 bits has the nice properties that it is a round number and that even if machines continue to get exponentially faster it will be secure beyond the lifetimes of anyone alive today. It is not immune to advances in mathematics, but there is no modulus size that is safe from such advances; we sort of have to wait for them and then decide what modulus size is required or even whether RSA is useful anymore. --Charlie (kaufman@zk3.dec.com) From ipsec-request@ans.net Mon Sep 20 14:42:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20470 (5.65c/IDA-1.4.4 for ); Mon, 20 Sep 1993 11:01:06 -0400 Received: by interlock.ans.net id AA14947 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Sep 1993 10:51:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 20 Sep 1993 10:51:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Sep 1993 10:51:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Sep 1993 10:51:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Sep 1993 10:51:19 -0400 Message-Id: <9309201442.AA15155@snark.lehman.com> To: kaufman@zk3.dec.com Cc: pem-dev@tis.com, ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: Your message of "Mon, 20 Sep 1993 10:01:59 EDT." <9309201402.AA02037@abyss.zk3.dec.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 20 Sep 1993 10:42:05 -0400 From: "Perry E. Metzger" kaufman@zk3.dec.com says: > >Make it into a 1024 bit key, the minimum you need for real security, > > I couldn't let this pass. With our current knowledge, 1024 is about > the maximum useful RSA key size, not the minimum. 512 bits is plenty > for most uses. I would suggest that you have not been reading the crypto literature of late. I will gladly provide references if you insist. I know people who are using keys larger than 1024 bits -- they have no trouble with them, since the RSA keys are only used to encrypt a conventional key. I can't see a "maximum" useful size below about 5kbit, and that maximum will only rise. Rumor I hear has it that the military uses 1024 bit keys and larger, which makes me think that the open literature isn't wrong. Perry From ipsec-request@ans.net Mon Sep 20 06:56:44 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19199 (5.65c/IDA-1.4.4 for ); Mon, 20 Sep 1993 11:01:52 -0400 Received: by interlock.ans.net id AA06751 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Sep 1993 10:51:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Sep 1993 10:51:09 -0400 Message-Id: <199309201451.AA20571@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Sep 1993 10:51:09 -0400 To: kaufman@zk3.dec.com Cc: pmetzger@lehman.com, pem-dev@tis.com, ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: [resend] Use of DNS to distribute keys Date: Mon, 20 Sep 93 10:56:44 EDT >Make it into a 1024 bit key, the minimum you need for real security, I couldn't let this pass. With our current knowledge, 1024 is about the maximum useful RSA key size, not the minimum. 512 bits is plenty for most uses. It is roughly where DES was 15 years ago: perhaps NSA can afford to break it but no one else can. If you're worried about NSA, 640 bits is entirely adequate unless they know some mathematics the rest of us don't. I think it's safe to assume that NSA does indeed know more math. Remember that they'll permit 512-bit RSA to be exported easily. That, to me, speaks volumes... Where the cutoff is, I couldn't say, but I assume they left themselves some margin. From ipsec-request@ans.net Mon Sep 20 18:23:52 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13211 (5.65c/IDA-1.4.4 for ); Mon, 20 Sep 1993 14:29:06 -0400 Received: by interlock.ans.net id AA08576 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Sep 1993 14:17:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Sep 1993 14:17:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Sep 1993 14:17:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Sep 1993 14:17:57 -0400 Message-Id: <9309201823.AA10089@skidrow.lkg.dec.com> To: kaufman@zk3.dec.com Cc: pmetzger@lehman.com, pem-dev@tis.com, ipsec@ans.net Subject: Re: [resend] Use of DNS to distribute keys In-Reply-To: Your message of "Mon, 20 Sep 93 10:01:59 EDT." <9309201402.AA02037@abyss.zk3.dec.com> Date: Mon, 20 Sep 93 14:23:52 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: kaufman@zk3.dec.com To: pmetzger@lehman.com >>Make it into a 1024 bit key, the minimum you need for real security, >I couldn't let this pass. With our current knowledge, 1024 is about >the maximum useful RSA key size, not the minimum. 512 bits is plenty >for most uses. It is roughly where DES was 15 years ago: perhaps NSA >can afford to break it but no one else can. ... If 1024 is the maximum useful RSA key size, they obviously it would be a good idea to design a system that could accomodate it, as well as\ smaller sizes. >... > --Charlie Donald From ipsec-request@ans.net Tue Sep 21 04:01:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05181 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 00:06:59 -0400 Received: by interlock.ans.net id AA11532 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Sep 1993 23:55:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 20 Sep 1993 23:55:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Sep 1993 23:55:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Sep 1993 23:55:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Sep 1993 23:55:43 -0400 To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net Reply-To: Subject: Re: draft spec and pilot implementation In-Reply-To: Your message of "Sun, 19 Sep 1993 13:56:35 EDT." References: <9309191756.AA21783@itd.nrl.navy.mil> Date: Tue, 21 Sep 1993 13:01:43 +0900 Message-Id: <10043.748584103@yamato.ibm.com> From: "Takashi Tazawa" On Sun, 19 Sep 93 13:56:35 EDT , atkinson@itd.nrl.navy.mil (Ran Atkinson) writes: > There is no consensus on what the IP Security Protocol should look > like. There are at least 3 serious contenders. I am told that part > of the US DoD is funding development of IP/NLSP implementations. A I read K.Robert Glenn's mail in this ML that I-D of I-NLSP would come. It isn't yet submitted past 8/30/93, but I expect it will come soon... > trio of researchers in the private sector have already developed a > prototype called "swIPe". The SP3 security protocol is commercially I also expect I-D of "swIPe" will come soon. Two of above researchers will publish a paper of swIPe in the Proceedings of USENIX 4th Security Symposium. I obtained the PostScript version and found [6] in reference might be I-D. Is this right? > available now (as in the US Navy uses SP3 daily to protect sensitive > traffic). Is there a person working to write the I-D of SP3, or the I-D of SP3 will continue to be unavailable? > There are no known Internet Drafts of any sort relating to the IP > Security work, at least to my knowledge/recollection. This is clearly > a serious standards process problem in this working group because lack > of I-Ds (and the de facto reliance on sundry NIST and ISO specs) makes > the process less open to peer review on the Internet and is not normal > IETF procedure. Agreed. -- Takashi Tazawa INTERNET: tazawa@vnet.ibm.com From ipsec-request@ans.net Tue Sep 21 05:04:03 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18596 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 15:04:06 -0400 Received: by interlock.ans.net id AA20206 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Sep 1993 14:56:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 21 Sep 1993 14:56:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Sep 1993 14:56:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Sep 1993 14:56:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 14:56:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 14:56:18 -0400 Message-Id: <00112.2831457960.47498@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 21 Sep 1993 12:04:03 MST Subject: Re: > draft spec and pilot i Reply to: RE>> draft spec and pilot im Ran, You have brought up some important organizational points about our IPSEC work that we need to solve. >Date: 19 Sep 93 13:56:35 -0400 >From: Ran Atkinson > > There is no consensus on what the IP Security Protocol should look >like. There are at least 3 serious contenders. I am told that part >of the US DoD is funding development of IP/NLSP implementations. A >trio of researchers in the private sector have already developed a >prototype called "swIPe". The SP3 security protocol is commercially >available now (as in the US Navy uses SP3 daily to protect sensitive >traffic). I was not able to attend the last meeting in Amsterdam, but I heard that significant progress was made on the resolving some of the outstanding IPSP issues. However, I have not seen any minutes yet from this meeting. It is hard to develop a consensus when we do not record our work. > There are no known Internet Drafts of any sort relating to the IP >Security work, at least to my knowledge/recollection. This is clearly >a serious standards process problem in this working group because lack >of I-Ds (and the de facto reliance on sundry NIST and ISO specs) makes >the process less open to peer review on the Internet and is not normal >IETF procedure. > >Ran I agree that the lack of Internet Drafts pertaining to our work is a problem. Having the various NIST and ISO specifications in paper form has served as a useful starting point, but we should find a way to post these references to this mailing list. Ran, would you like to type or scan them into an ASCII format? There will be an NLSP I-D soon that will hopefully will serve as fodder to keep the group moving. I would also encourage the swIPe advocates to post any work that they are pursuing. The minutes are still a serious problem. I will attempt to track them down and get something posted. Paul From ipsec-request@ans.net Tue Sep 21 11:42:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13796 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 15:45:14 -0400 Received: by interlock.ans.net id AA20431 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Sep 1993 15:36:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 15:36:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 15:36:39 -0400 Date: Tue, 21 Sep 93 15:42:43 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309211942.AA25195@itd.nrl.navy.mil> To: Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: IPSEC stuff Cc: ipsec@ans.net Paul, One of the differences between the IETF and other groups is that consensus is most normally determined by email discussions on the list. There is no rule or requirement that people attend any IETF meetings -- meeting consensus is not sufficient, there must also be a consensus on the email list. I have seen nothing even close to consensus on the ipsec list, so the Amsterdam meeting must not have reached consensus. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Sep 21 06:10:38 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14366 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 16:15:50 -0400 Received: by interlock.ans.net id AA17985 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Sep 1993 16:06:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 21 Sep 1993 16:06:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Sep 1993 16:06:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Sep 1993 16:06:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 16:06:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 16:06:26 -0400 Message-Id: <00112.2831462091.47520@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: tazawa@vnet.IBM.COM (tazawa) Cc: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 21 Sep 1993 13:10:38 MST Subject: Re: >draft spec and pilot im Reply to: RE>>draft spec and pilot imp Takashi, > I also expect I-D of "swIPe" will come soon. >Two of above researchers will publish a paper of swIPe in the >Proceedings of USENIX 4th Security Symposium. I obtained the >PostScript version and found [6] in reference might be I-D. >Is this right? Is the PostScript draft you refer to readily available? Who were the authors? Thanks, Paul A. Lambert From ipsec-request@ans.net Tue Sep 21 20:53:10 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13800 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 16:51:39 -0400 Received: by interlock.ans.net id AA18591 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Sep 1993 16:43:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 16:43:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 16:43:30 -0400 Date: Tue, 21 Sep 1993 15:53:10 -0500 From: chrisg@lobby.ti.com (Chris Gorsuch) Message-Id: <199309212053.AA25698@lobby.ti.com> To: ipsec@ans.net Subject: IETF meeting This may have already been asked, but: Will the ipsec group be meeting during the November IETF meetings or is the swIPe proposal the only IPSEC related item on the docket? A cursory examination of the itinerary does not seem to mention one. Thanks for the information, Chris Gorsuch chrisg@lobby.ti.com From ipsec-request@ans.net Tue Sep 21 10:47:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19030 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 18:11:26 -0400 Received: by interlock.ans.net id AA14551 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Sep 1993 17:57:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 17:57:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 17:57:31 -0400 Date: Tue, 21 Sep 93 14:47:05 EDT From: "William Allen Simpson" Message-Id: <1403.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Bidding In view of the "per-packet bidding" proposed by an economist on the main IETF discussion list, is there any interest in specifically endorsing or eliminating such fields in the security headers? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Sep 22 08:49:14 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18625 (5.65c/IDA-1.4.4 for ); Wed, 22 Sep 1993 04:53:12 -0400 Received: by interlock.ans.net id AA11890 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Sep 1993 04:43:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Sep 1993 04:43:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Sep 1993 04:43:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Sep 1993 04:43:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Sep 1993 04:43:14 -0400 To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: ipsec@ans.net (ip security mailing list) Subject: Re: >draft spec and pilot im In-Reply-To: Your message of "Tue, 21 Sep 1993 13:10:38 MST." References: <00112.2831462094.47521@poncho.phx.sectel.mot.com> Date: Wed, 22 Sep 1993 17:49:14 +0900 Message-Id: <16567.748687754@yamato.ibm.com> From: "Takashi Tazawa" Paul, On Tue, 21 Sep 1993 13:10:38 MST , Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) writes: > Is the PostScript draft you refer to readily available? The paper I refer to is not itself the Internet Draft. It presents the architecture, design philosophy and performance of an implementation of swIPe. It is described in that paper that Reference [6] is the authoritative protocol description. I think this paper is a good introduction to swIPe. It is available by anonymous ftp from cs.columbia.edu:/pub/ji. Slides from 26th IETF meeting seems to be also available. > Who were the authors? John Ioannidis at Columbia University and Matt Blaze at AT&T Bell Laboratories. Regards, -- Takashi Tazawa INTERNET: tazawa@vnet.ibm.com From ipsec-request@ans.net Fri Sep 24 10:29:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16962 (5.65c/IDA-1.4.4 for ); Fri, 24 Sep 1993 14:41:08 -0400 Received: by interlock.ans.net id AA11869 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Sep 1993 14:23:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Sep 1993 14:23:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Sep 1993 14:23:10 -0400 Date: Fri, 24 Sep 93 14:29:43 EDT From: K. Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9309241829.AA26168@sloth.ncsl.nist.gov> To: Subject: I-NLSP Specification Status Cc: Rob_Glenn Hello all, I've gone ahead and started the I-D submission process with I-NLSP (Integrated Network Layer Security Protocol). There seems to be some confusion between what that process is, but hopefully that will be straightened out quickly. If I-NLSP seems overly complex, please realize that I tried *not* to change the functionality of ISO 11577, so I-NLSP will contain most of the technical complexity and perceived technical "problems" of ISO 11577. The steps in producing I-NLSP existed of 1) Obtaining an on-line ISO 11577 and converting it to ascii; 2) Eliminating any perceived Connection Oriented parts (some of this was interpretation); 3) Massaged text and reorganized sections to improve readability (some of this was also interpretation); and 4) Pointed out areas of technical concerns (TLV encoding, QOS problems,etc) and recommended fixes in Editorial Notes. I've received several comments from people on technical issues that deal primarily with the ISO 11577 functionality that is also in I-NLSP. I hope to follow up I-NLSP with a specification that addresses these concerns, the concerns that I've already pointed out in the Editorial Notes, and any concerns which this group will come up with. This document is meant as a *starting point* not a finished specification. It is my hope that the finished product will be established by a consensus from this group. Enough said. The document should be available sometime next week from the normal IETF sources (as long as the confusion can be straightened out quickly). If you would like to get a copy of it before it becomes officially available, it can be obtained by anonymous ftp on osi.ncsl.nist.gov (129.6.48.100) in /pub/security/draft-i-nlsp1.txt. Sincerely, Rob G. From ipsec-request@ans.net Fri Sep 24 11:20:32 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17825 (5.65c/IDA-1.4.4 for ); Fri, 24 Sep 1993 15:31:59 -0400 Received: by interlock.ans.net id AA17700 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Sep 1993 15:14:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Sep 1993 15:14:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Sep 1993 15:14:29 -0400 Date: Fri, 24 Sep 93 15:20:32 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309241920.AA11843@itd.nrl.navy.mil> To: glenn@sloth.ncsl.nist.gov Subject: Re: I-NLSP Specification Status Cc: ipsec@ans.net This is most helpful and much appreciated. Ran From ipsec-request@ans.net Sat Sep 25 09:46:57 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13146 (5.65c/IDA-1.4.4 for ); Sat, 25 Sep 1993 09:46:57 -0400 Received: by interlock.ans.net id AA08236 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 25 Sep 1993 09:29:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 25 Sep 1993 09:29:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 25 Sep 1993 09:29:10 -0400 From: Masataka Ohta Return-Path: Message-Id: <9309251331.AA00673@necom830.cc.titech.ac.jp> Subject: Re: [resend] Use of DNS to distribute keys To: pmetzger@lehman.com Date: Sat, 25 Sep 93 22:30:43 JST Cc: pem-dev@tis.com, ipsec@ans.net, namedroppers@nic.ddn.mil In-Reply-To: <9309172140.AA24688@snark.lehman.com>; from "Perry E. Metzger" at Sep 17, 93 5:40 pm X-Mailer: ELM [version 2.3 PL11] > kaufman@zk3.dec.com says: > > This discussion came late to pem-dev, and it could be I'm missing some > > crucial context. But let me throw in some thoughts: > > > > 1) There is little to be gained by storing certificates of on-line > > entities in DNS because it is just as easy to ask the entity for its > > certificate(s). > > But HOW do you ask the entities for their certificates? DNS is a nice > existing mechanism by which you can do the asking. It should also be noted that, in doing so, the entire DNS tree need not be so secure. If some leaf host needs some security level, only the upper level name servers of the DNS tree needs to be as secure as the leaf host. Masataka Ohta From ipsec-request@ans.net Mon Sep 27 04:42:18 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19735 (5.65c/IDA-1.4.4 for ); Mon, 27 Sep 1993 08:49:13 -0400 Received: by interlock.ans.net id AA08335 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Sep 1993 08:35:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Sep 1993 08:35:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Sep 1993 08:35:46 -0400 Date: Mon, 27 Sep 93 08:42:18 EDT From: K. Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9309271242.AA28718@sloth.ncsl.nist.gov> To: Subject: Houston, November 1-5 Paul & Al (or anyone else, "in-the-know"), I was just preparing to send out the November IETF Registration and noticed that the IPSEC is not on the current agenda. Is the group meeting in Houston in November? If so, any idea what the agenda might be? Are the minutes available yet from the last meeting? Thanks, Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Mon Sep 27 09:42:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19737 (5.65c/IDA-1.4.4 for ); Mon, 27 Sep 1993 10:45:35 -0400 Received: by interlock.ans.net id AA09115 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Sep 1993 10:36:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Sep 1993 10:36:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Sep 1993 10:36:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Sep 1993 10:36:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Sep 1993 10:36:44 -0400 Message-Id: <9309271442.AA20911@TIS.COM> Cc: ipsec@ans.net Subject: Re: Houston, November 1-5 In-Reply-To: Your message of "Mon, 27 Sep 93 08:42:18 EDT." <9309271242.AA28718@sloth.ncsl.nist.gov> Date: Mon, 27 Sep 93 10:42:05 +0100 From: Stephen D Crocker Per conversation I had with Paul, I've asked for two slots for IPSEC meetings. I dont know how tight the schedule is; we should have this resolved this week. Steve > From: K. Robert Glenn > To: > Date: Mon, 27 Sep 93 08:42:18 EDT > Subject: Houston, November 1-5 > > > Paul & Al (or anyone else, "in-the-know"), > > I was just preparing to send out the November > IETF Registration and noticed that the IPSEC is > not on the current agenda. Is the group meeting in > Houston in November? If so, any idea what > the agenda might be? Are the minutes available > yet from the last meeting? > > > Thanks, > > Rob G. > glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Wed Sep 29 18:58:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18255 (5.65c/IDA-1.4.4 for ); Wed, 29 Sep 1993 15:01:29 -0400 Received: by interlock.ans.net id AA17830 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 29 Sep 1993 14:52:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 29 Sep 1993 14:52:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Sep 1993 14:52:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Sep 1993 14:52:38 -0400 Date: Wed, 29 Sep 1993 14:58:43 -0400 From: Steve Lunt Message-Id: <199309291858.AA04625@shadow.secure.bellcore.com> To: ipsec@ans.net Subject: Re: Integrated Network Layer Security Protocol IPSEC WG, What is the relation of this work to the efforts of the IPSEC working group? -- Steve > From: Internet-Drafts@CNRI.Reston.VA.US > Subject: ID ACTION:draft-glenn-layer-security-00.txt > Date: Wed, 29 Sep 93 13:06:44 -0400 > > A New Internet Draft is available from the on-line Internet-Drafts > directories. > > Title : Integrated Network Layer Security Protocol > Author(s) : K. Robert Glenn > Filename : draft-glenn-layer-security-00.txt > Pages : 24 > > The Internet has been moving towards a more standardized and open > infrastructure to cope with its growing requirements. One requirement of > particular interest and importance is that of network security. With the > possible addition of CLNP [ISO8473] as a connectionless network protocol > for the Internet the most useful solution is an integrated network security > protocol that will provide security services and mechanisms for both > IP and CLNP. > > The protocol defined by this Internet Draft is used to provide security > services in support of an instance of communication between network layer > entities for either IP or CLNP. An attempt is made to keep the > functionality as close as possible to [ISO11577]. As a result this > specification contains all of the technical complexities and problems > of [ISO11577]. Editorial comments are included to address certain > technical issues, such as headers ending on word boundaries, > type-length-value encoding problems, etc. that may be outside the scope > of [ISO11577]. This specification should be viewed as an initial attempt > at identifying a protocol that can provide a set of security services > for both IPV4 and CLNP. > From ipsec-request@ans.net Wed Sep 29 08:56:26 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14482 (5.65c/IDA-1.4.4 for ); Wed, 29 Sep 1993 18:56:47 -0400 Received: by interlock.ans.net id AA12391 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 29 Sep 1993 18:50:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 29 Sep 1993 18:50:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 29 Sep 1993 18:50:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 29 Sep 1993 18:50:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Sep 1993 18:50:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Sep 1993 18:50:30 -0400 Message-Id: <00112.2832163221.48464@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: lunt@ctt.bellcore.com (Steve Lunt), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 29 Sep 1993 15:56:26 MST Subject: Re: >Integrated Network Laye Reply to: RE>>Integrated Network Layer >IPSEC WG, > > What is the relation of this work to the efforts of >the IPSEC working group? > >-- Steve > >> From: Internet-Drafts@CNRI.Reston.VA.US >> Subject: ID ACTION:draft-glenn-layer-security-00.txt >> Date: Wed, 29 Sep 93 13:06:44 -0400 >> >> A New Internet Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Integrated Network Layer Security Protocol >> Author(s) : K. Robert Glenn >> Filename : draft-glenn-layer-security-00.txt >> Pages : 24 etc. Steve, The draft-glenn-layer-security-00.txt document is one of three IPSEC related Internet-Drafts that should be published before the next meeting. Paul From ipsec-request@ans.net Thu Sep 30 10:44:17 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14513 (5.65c/IDA-1.4.4 for ); Thu, 30 Sep 1993 15:24:48 -0400 Received: by interlock.ans.net id AA12594 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 30 Sep 1993 15:16:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 30 Sep 1993 15:16:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 30 Sep 1993 15:16:39 -0400 Date: Thu, 30 Sep 93 14:44:17 EDT From: "William Allen Simpson" Message-Id: <1444.bill.simpson@um.cc.umich.edu> To: Steve Lunt Cc: ipsec@ans.net Cc: internet-drafts@cnri.reston.va.us Reply-To: bsimpson@MorningStar.Com Subject: Re: Integrated Network Layer Security Protocol > What is the relation of this work to the efforts of > the IPSEC working group? > It is one of the 3 proposals being considered. It should have been draft-ietf-ipsec-inlsp-00. Bill.Simpson@um.cc.umich.edu