Received: from relay.tis.com by neptune.TIS.COM id aa14054; 1 May 96 8:40 EDT Received: by relay.tis.com; id IAA13760; Wed, 1 May 1996 08:41:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013733; Wed, 1 May 96 08:40:43 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24227; Wed, 1 May 96 08:41:03 EDT Received: by relay.tis.com; id IAA13723; Wed, 1 May 1996 08:40:41 -0400 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1) id xma013716; Wed, 1 May 96 08:40:39 -0400 Received: from (JimMac.jhughes.gofast.net) by nsco.network.com (4.1/1.34) id AA23957; Wed, 1 May 96 07:45:31 CDT Message-Id: <3187158A.18EB@hughes.network.com> Date: Wed, 01 May 1996 07:40:59 +0000 From: Jim Hughes Reply-To: hughes@hughes.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b3 (Macintosh; I; PPC) Mime-Version: 1.0 To: Bill Sommerfeld Cc: pau@watson.ibm.com, hughes@nsco.network.com, ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-des-md5-00.txt References: <199604302201.AA121881684@relay.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk I think Paul has raised a significant point that may be obvious to some, but is not obvious to me and is also not obvious from reading this document or from reading Oakley. Paul@Watson.ibm.com wrote > James, I would suggest in the esp-DES-HMAC-RP transform, the source and > destination addresses of the IP packet (which will carry the IPSEC payload) > be included in the HMAC computation to provide a sense of direction. These > addresses do not have to appear in the actual packet transmitted. > > This is to provide some defense against reflection attacks. I think this > is necessary since it is likely the same set of keys will be used in > both directions. I agree that reflection attacks need to be considered. Including the IP address is something that seems to be version forward dangerous (IPv7). I would suggest that different keys for each irection would be a better way to defend reflection attacks. My assumption has been that there will be different keys in each direction, and... Bill Sommerfeld wrote: > All of the proposed key mgmt protocols I've looked at in any detail > generate different keys (and different SPI's) in each direction. in reading Oakley again, this did not seem to be discussed. I would really hope that we do not need to do two complete sets of D-H/RSA to set up a FDX connection? If Oakley creates one key and the esp is to create a FDX session, then we should be deriving 2 sets of keys, one for each direction. This would also require the esp to know which end of the connection that it is so that the derivation can be inversely symetrical. I need some comments here? Hillary? Received: from relay.tis.com by neptune.TIS.COM id aa15023; 1 May 96 9:55 EDT Received: by relay.tis.com; id JAA15404; Wed, 1 May 1996 09:56:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015396; Wed, 1 May 96 09:56:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27655; Wed, 1 May 96 09:56:28 EDT Received: by relay.tis.com; id JAA15389; Wed, 1 May 1996 09:56:06 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xmaa15383; Wed, 1 May 96 09:56:04 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15098; 1 May 96 9:44 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-00.txt Date: Wed, 01 May 96 09:44:42 -0400 Message-Id: <9605010944.aa15098@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC-SHA IP Authentication with Replay Prevention Author(s) : S. Chang, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-sha-00.txt Pages : 7 Date : 04/30/1996 This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-sha-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960430143310.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-sha-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960430143310.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa15022; 1 May 96 9:55 EDT Received: by relay.tis.com; id JAA15403; Wed, 1 May 1996 09:56:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015397; Wed, 1 May 96 09:56:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27656; Wed, 1 May 96 09:56:28 EDT Received: by relay.tis.com; id JAA15388; Wed, 1 May 1996 09:56:06 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma015383; Wed, 1 May 96 09:56:03 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15058; 1 May 96 9:43 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-00.txt Date: Wed, 01 May 96 09:43:49 -0400 Message-Id: <9605010943.aa15058@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC-MD5 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-00.txt Pages : 6 Date : 04/30/1996 This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960430143416.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960430143416.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa15508; 1 May 96 10:18 EDT Received: by relay.tis.com; id KAA16163; Wed, 1 May 1996 10:19:36 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016150; Wed, 1 May 96 10:19:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28909; Wed, 1 May 96 10:19:29 EDT Received: by relay.tis.com; id KAA16142; Wed, 1 May 1996 10:19:06 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma016120; Wed, 1 May 96 10:18:50 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id KAA27980; Wed, 1 May 1996 10:19:11 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.23.21]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id KAA36003; Wed, 1 May 1996 10:18:56 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA20212; Wed, 1 May 1996 10:23:36 -0400 Date: Wed, 1 May 1996 10:23:36 -0400 Message-Id: <9605011423.AA20212@secpwr.watson.ibm.com> To: sommerfeld@apollo.hp.com, hughes@hughes.network.com Subject: Re: draft-ietf-ipsec-des-md5-00.txt Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: ES0ftS0ezUO6L0zigqpVUA== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi, this msg is a response to David's, Bill's and James's msgs. I do agree using uni-directional keys is a better solution. It is also easy to do, as David pointed out in his msg. In fact, we have been using it for a while in our lab and (soon to be) in our product. My problem is that I don't see uni-directional keys being made mandatory in RFC1825, ISAKMP draft 4 nor Oakley draft. I may have misread them. If any body sees it, please kindly point it to me. Thank you. Regards, Pau-Chen Received: from relay.tis.com by neptune.TIS.COM id aa15783; 1 May 96 10:39 EDT Received: by relay.tis.com; id KAA17064; Wed, 1 May 1996 10:40:06 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017048; Wed, 1 May 96 10:39:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00493; Wed, 1 May 96 10:39:57 EDT Received: by relay.tis.com; id KAA17041; Wed, 1 May 1996 10:39:35 -0400 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1) id xma017015; Wed, 1 May 96 10:38:42 -0400 Received: from (jimsmac.network.com) by nsco.network.com (4.1/1.34) id AA25593; Wed, 1 May 96 09:44:13 CDT Message-Id: <318719D2.16A7@hughes.network.com> Date: Wed, 01 May 1996 07:59:14 +0000 From: Jim Hughes Reply-To: hughes@hughes.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b3 (Macintosh; I; PPC) Mime-Version: 1.0 To: Bill Sommerfeld Cc: ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-esp-des-md5-01.txt References: <199604301719.AA124944796@relay.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > quoting from the draft: > > This draft describes a combination of privacy and optionally, > authentication, integrity and replay prevention into a single packet > format. > > and later: > > The combinations of transformations are negotiated at key > establishment time such as described in ISA/KMP [Maughan96] and > Oakley [Orman96]. To conform with this RFC, of the 3 transforms > documented in this RFC, only esp-DES-HMAC-RP shall be > implemented. > > Ok, is integrity protection mandatory or not? The text here seems to be clumbsy. > My impression (and please correct me if I'm wrong) was that the > consensus of the WG at the LA IETF was that privacy without integrity > was too dangerous to implement; however, this draft is internally > inconsistant about whether integrity is mandatory, and specifies > transforms which it says should not be implemented. > > What's changed? Nothing has "changed". If anything my text is less than clear. The mandetory transform is des-hmac. It is optional to not have the integrity and not to have replay. As Bellovan has stated, DES-CBC without integrity has several vulnerabilties, but that does not eliminate the viabilitiy of a des-only transform for performance sensitive solutions that understand these vulnerabilities and make an informed decision that the elimination of the hmac is not a problem. Suggested text for the above 2 paragraphs will be welcome. Is Ran's text replacent better? jim Received: from relay.tis.com by neptune.TIS.COM id aa17554; 1 May 96 12:29 EDT Received: by relay.tis.com; id MAA19708; Wed, 1 May 1996 12:30:11 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019696; Wed, 1 May 96 12:29:40 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06445; Wed, 1 May 96 12:30:00 EDT Received: by relay.tis.com; id MAA19689; Wed, 1 May 1996 12:29:39 -0400 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1) id xma019683; Wed, 1 May 96 12:29:30 -0400 Received: from (jimsmac.network.com) by nsco.network.com (4.1/1.34) id AA00610; Wed, 1 May 96 11:36:28 CDT Message-Id: <318791FE.492A@hughes.network.com> Date: Wed, 01 May 1996 11:31:59 -0500 From: Jim Hughes Reply-To: hughes@hughes.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b3 (Macintosh; I; PPC) Mime-Version: 1.0 To: Naganand Doraswamy Cc: "James P. Hughes" , ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-esp-des-md5-01.txt References: <2.2.32.19960430172549.00950e68@mailserv-H.ftp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Naganand Doraswamy wrote: > > Is there any security reason as to why we ae XORing the IV key when we use > 32 bit IV and replay protection and not when using IV lenght of 64 bits. The reason the XOR was added to the replay/IV creation is to defend against a codebook attack of early blocks assuming that the SPI is not a random number... The reason for adding the XOR to the 32 bit IV was to prevent a birthday/codebook attack on the first 65K packets... This is not a significant attack, but one that is simple to cover... Frankly, I had not thought about doing this for the 64 bit version.... I see little value in doing it, but it does not hurt? Here is a note from an early draft that I used to explain the change. [Note, The IV32 procedure is a change from the esp-des-cbc. XORing by the IV key prevents a birthday/codebook attack on the first block. Inverting the second half does not mitigate the birthday/codebook attack.] > If there is none, then I would suggest that we make it uniform and either XOR > with IV key for all transform or dont do it for any transform. this is OK by me. Comments from the Gallery? jim Received: from relay.tis.com by neptune.TIS.COM id aa17661; 1 May 96 12:34 EDT Received: by relay.tis.com; id MAA19794; Wed, 1 May 1996 12:35:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019790; Wed, 1 May 96 12:35:10 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06649; Wed, 1 May 96 12:35:31 EDT Received: by relay.tis.com; id MAA19783; Wed, 1 May 1996 12:35:09 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma019777; Wed, 1 May 96 12:34:58 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA17389; Wed, 1 May 1996 09:37:06 -0700 Date: Wed, 1 May 1996 09:37:06 -0700 From: Ran Atkinson Message-Id: <199605011637.JAA17389@puli.cisco.com> To: pau@watson.ibm.com Subject: Re: draft-ietf-ipsec-des-md5-00.txt In-Reply-To: <9605011423.AA20212@secpwr.watson.ibm.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Pau, RFC-1825 has always said that an IPsec Security Association is unidirectional, not bidirectional. Keys are one element of an IPsec Security Association. So my reading of RFC-1825 is that it already says that a key will normally be unidirectional. In general, folks should keep in mind that a Security Association contains a lot more than key material. If you think that this needs to be made more clear, then I have no problems with clarifying the text when the other editorial changes get made to 1825-1827 (these are coming soon, but I haven't yet made the accumulated editorial changes). Once I get the editorial changes in hand made, new I-Ds will go out so that people can review the I-Ds and remind me of whichever changes need to be made but have not yet been made. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa17903; 1 May 96 12:45 EDT Received: by relay.tis.com; id MAA20013; Wed, 1 May 1996 12:46:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020005; Wed, 1 May 96 12:46:10 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07000; Wed, 1 May 96 12:46:31 EDT Received: by relay.tis.com; id MAA19999; Wed, 1 May 1996 12:46:09 -0400 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1) id xma019995; Wed, 1 May 96 12:45:19 -0400 Received: from (jimsmac.network.com) by nsco.network.com (4.1/1.34) id AA01369; Wed, 1 May 96 11:47:20 CDT Message-Id: <3187948A.378F@hughes.network.com> Date: Wed, 01 May 1996 11:42:50 -0500 From: Jim Hughes Reply-To: hughes@hughes.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b3 (Macintosh; I; PPC) Mime-Version: 1.0 To: pau@watson.ibm.com Cc: sommerfeld@apollo.hp.com, hughes@hughes.network.com, ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-des-md5-00.txt References: <9605011423.AA20212@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk pau@watson.ibm.com wrote: > > Hi, this msg is a response to David's, Bill's and James's msgs. > > I do agree using uni-directional keys is a better solution. It is also > easy to do, as David pointed out in his msg. In fact, we have been using > it for a while in our lab and (soon to be) in our product. I was trying to avoid the product label, but NSC has product experiance with asymetric keys. > My problem is that I don't see uni-directional keys being made mandatory > in RFC1825, ISAKMP draft 4 nor Oakley draft. I may have misread them. > If any body sees it, please kindly point it to me. I can add this to the esp, just like dumbing the keys up was. After thinking aobut it, I just need something, anything to break a tie for picking a forward and a reverse direction. A flag as to if I am the initiator or responder? IP address? Lower SPI? Anyway, if there is a way, I can dumb-up a few more keys for directionality? Comments? Received: from relay.tis.com by neptune.TIS.COM id aa18663; 1 May 96 13:37 EDT Received: by relay.tis.com; id NAA20556; Wed, 1 May 1996 13:20:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020551; Wed, 1 May 96 13:20:10 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08547; Wed, 1 May 96 13:20:30 EDT Received: by relay.tis.com; id NAA20548; Wed, 1 May 1996 13:20:09 -0400 Received: from optima.cs.arizona.edu(192.12.69.5) by relay.tis.com via smap (V3.1) id xma020546; Wed, 1 May 96 13:19:58 -0400 Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA11500; Wed, 1 May 1996 10:20:48 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA05332; Wed, 1 May 1996 10:20:46 -0700 Date: Wed, 1 May 1996 10:20:46 -0700 From: Hilarie Orman Message-Id: <9605011720.AA05332@uncial.CS.Arizona.EDU> To: hughes@hughes.network.com Cc: sommerfeld@apollo.hp.com, ipsec@TIS.COM, hughes@nsco.network.com, pau@watson.ibm.com In-Reply-To: Yourmessage <3187158A.18EB@hughes.network.com> Subject: Re: draft-ietf-ipsec-des-md5-00.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk Here's my view. Oakley doesn't set IPSEC SPI keys per se --- ISAKMP does this. And ISAKMP will need to define how it derives each SPI key from the Oakley keying material. Prepending a counter to the keying material and hashing would seem the obvious answer ... a "0" for one direction, "1" for the other, higher numbers for deriving keys for a "block of SPIs". Received: from relay.tis.com by neptune.TIS.COM id aa23698; 1 May 96 17:49 EDT Received: by relay.tis.com; id RAA28682; Wed, 1 May 1996 17:50:20 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028673; Wed, 1 May 96 17:49:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21358; Wed, 1 May 96 17:50:13 EDT Received: by relay.tis.com; id RAA28664; Wed, 1 May 1996 17:49:50 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma028653; Wed, 1 May 96 17:49:26 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id RAA15820; Wed, 1 May 1996 17:52:18 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.23.21]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id RAA44843; Wed, 1 May 1996 17:52:03 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA20782; Wed, 1 May 1996 17:56:43 -0400 Date: Wed, 1 May 1996 17:56:43 -0400 Message-Id: <9605012156.AA20782@secpwr.watson.ibm.com> To: pau@watson.ibm.com, rja@cisco.com Subject: Re: draft-ietf-ipsec-des-md5-00.txt Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: RjfMzL4BoplNbzZS0jz4BQ== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran, thank you very much for the explanation. RFC1825 does say that an SPI and a destination address uniquely identifies an SA. I think it would be better to explicitly state this "uni-directional" nature of an SA. Regards, Pau-Chen > From: Ran Atkinson > Message-Id: <199605011637.JAA17389@puli.cisco.com> > To: pau@watson.ibm.com > Subject: Re: draft-ietf-ipsec-des-md5-00.txt > In-Reply-To: <9605011423.AA20212@secpwr.watson.ibm.com> > Organization: cisco Systems, Inc., Menlo Park, Ca. > Cc: ipsec@TIS.COM > Sender: ipsec-approval@neptune.tis.com > Precedence: bulk > Content-Length: 808 > Status: RO > > Pau, > > RFC-1825 has always said that an IPsec Security Association is > unidirectional, not bidirectional. Keys are one element of an IPsec > Security Association. So my reading of RFC-1825 is that it already says > that a key will normally be unidirectional. In general, folks should > keep in mind that a Security Association contains a lot more than key > material. > > If you think that this needs to be made more clear, then I have no > problems with clarifying the text when the other editorial changes get made > to 1825-1827 (these are coming soon, but I haven't yet made the accumulated > editorial changes). Once I get the editorial changes in hand made, new > I-Ds will go out so that people can review the I-Ds and remind me of > whichever changes need to be made but have not yet been made. > > Ran > rja@cisco.com > Received: from relay.tis.com by neptune.TIS.COM id aa24199; 1 May 96 18:04 EDT Received: by relay.tis.com; id SAA28970; Wed, 1 May 1996 18:05:50 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028968; Wed, 1 May 96 18:05:21 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21728; Wed, 1 May 96 18:05:42 EDT Received: by relay.tis.com; id SAA28965; Wed, 1 May 1996 18:05:20 -0400 Received: from unknown(198.92.30.31) by relay.tis.com via smap (V3.1) id xma028962; Wed, 1 May 96 18:05:15 -0400 Received: from dharkins-ss20.cisco.com (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id PAA12959 for ; Wed, 1 May 1996 15:10:45 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by dharkins-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id PAA04260 for ; Wed, 1 May 1996 15:07:51 -0700 Message-Id: <199605012207.PAA04260@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@TIS.COM Subject: cisco's ISAKMP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 May 1996 15:07:51 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk Cisco Systems is pleased to announce the release of their ISAKMP daemon. This software distribution is being made available free of charge for any commercial or non-commercial use to advance ISAKMP as a solution to Internet Key Management. To software can be downloaded by telneting to port 7600 on ftp-eng.cisco.com and following the directions from there. This daemon uses the PF_KEY Key Management API to register with a kernel which has implemented this API and the surrounding key management infrastructure. The NRL IPsec software distribution (currently bundled with IPv6) is such an implementation. Security associations negotiated by the ISAKMP daemon are inserted into the kernel's key engine and are available for use by its AH/ESP security mechanisms. To facilitate use of this ISAKMP daemon, the NRL distribution is also being made available on ftp-eng using the telnet procedure described above. Cisco's daemon is based on ISAKMP draft version 5 and utilizes features from the Oakley Key Determination Protocol draft version 1. This distribution comes with a cryptographic library from Cylink Corporation. Cylink has granted Cisco the right to offer this library-- source code to the Diffie-Hellman key exchange, the Digital Signature Standard, and the Digital Encryption Standard-- to all third parties on a royalty-free basis for use only with this ISAKMP reference implementation. A mailing list for problems, bug fixes, porting changes, and general discussion of ISAKMP and Oakley has been established: isakmp-oakley@cisco.com (majordomo@cisco.com for admin requests). Received: from relay.tis.com by neptune.TIS.COM id aa24253; 1 May 96 18:06 EDT Received: by relay.tis.com; id SAA29135; Wed, 1 May 1996 18:08:07 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029118; Wed, 1 May 96 18:07:36 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21892; Wed, 1 May 96 18:07:56 EDT Received: by relay.tis.com; id SAA29109; Wed, 1 May 1996 18:07:33 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma029099; Wed, 1 May 96 18:07:18 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id SAA24841; Wed, 1 May 1996 18:08:40 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.23.21]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id SAA53993; Wed, 1 May 1996 18:08:25 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA21306; Wed, 1 May 1996 18:13:05 -0400 Date: Wed, 1 May 1996 18:13:05 -0400 Message-Id: <9605012213.AA21306@secpwr.watson.ibm.com> To: hughes@hughes.network.com Subject: Re: draft-ietf-ipsec-des-md5-00.txt Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: YGSo0ku+8XNlw9gFaV4X/g== Sender: ipsec-approval@neptune.tis.com Precedence: bulk hughes@hughes.network.com wrote : > ..... > I can add this to the esp, just like dumbing the keys up was. > > After thinking aobut it, I just need something, anything to break a tie for > picking a forward and a reverse direction. A flag as to if I am the initiator > or responder? IP address? Lower SPI? Anyway, if there is a way, I can dumb-up a > few more keys for directionality? > > Comments? > For now, I am using addresses. But addresses may not work if NAT (network address translation) is used. SPI may be a candiate, but the two sides may choose the same SPI value. Perhaps this problem should be resolved at IKMP layer rather than at IPSEC layer ? The only thing the IKMP layer needs to do is to give IPSEC layer a 1-bit flag to indicate direction. I know that and pairs can be used to derive 2 uni-directional keys. But can IPSEC assumes cookies will always be used ? Regards, Pau-Chen Received: from relay.tis.com by neptune.TIS.COM id aa25567; 1 May 96 19:06 EDT Received: by relay.tis.com; id TAA29892; Wed, 1 May 1996 19:07:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029888; Wed, 1 May 96 19:07:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23214; Wed, 1 May 96 19:07:27 EDT Received: by relay.tis.com; id TAA29884; Wed, 1 May 1996 19:07:05 -0400 Received: from unknown(139.91.1.17) by relay.tis.com via smap (V3.1) id xma029882; Wed, 1 May 96 19:06:54 -0400 Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id CAA13309 (8.6.12/FORTHNET-2.0); Thu, 2 May 1996 02:04:38 +0300 (EET DST) Message-Id: <199605012304.CAA13309@info.forthnet.gr> Organization: To: pau@watson.ibm.com Cc: hughes@hughes.network.com, ipsec@TIS.COM Subject: Re: draft-ietf-ipsec-des-md5-00.txt In-Reply-To: Your message of "Wed, 01 May 1996 18:13:05 EDT." <9605012213.AA21306@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <6567.830991876.1@forthnet.gr> Date: Thu, 02 May 1996 02:04:37 +0300 From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <9605012213.AA21306@secpwr.watson.ibm.com>, pau@watson.ibm.com write s: > >For now, I am using addresses. But addresses may not work if NAT >(network address translation) is used. SPI may be a candiate, but >the two sides may choose the same SPI value. Perhaps this problem >should be resolved at IKMP layer rather than at IPSEC layer ? >The only thing the IKMP layer needs to do is to give IPSEC layer >a 1-bit flag to indicate direction. > >I know that and pairs >can be used to derive 2 uni-directional keys. But can IPSEC assumes >cookies will always be used ? > Anything on the packet that is not covered by an AH (or equivalent) header cannot be used for creating two keys. My feeling is that this is a KMP layer "problem". And then, i always opt for the greatest flexibility, which in this case means that the KMP should load each SPI/address/key tupple separately (maybe massively, but the key would be explicitly specified). Might make life easier in the future. And it's simpler too (or seems so). -Angelos Received: from relay.tis.com by neptune.TIS.COM id aa25723; 1 May 96 19:17 EDT Received: by relay.tis.com; id TAA29969; Wed, 1 May 1996 19:17:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029966; Wed, 1 May 96 19:17:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23399; Wed, 1 May 96 19:17:27 EDT Received: by relay.tis.com; id TAA29963; Wed, 1 May 1996 19:17:05 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma029961; Wed, 1 May 96 19:16:58 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA17717; Wed, 1 May 1996 16:19:05 -0700 Date: Wed, 1 May 1996 16:19:05 -0700 From: Ran Atkinson Message-Id: <199605012319.QAA17717@puli.cisco.com> To: pau@watson.ibm.com Subject: Re: draft-ietf-ipsec-des-md5-00.txt In-Reply-To: <9605012213.AA21306@secpwr.watson.ibm.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9605012213.AA21306@secpwr.watson.ibm.com> Pau wrote: >For now, I am using addresses. But addresses may not work if NAT >(network address translation) is used. For what its worth, NAT is increasingly commonplace in the deployed Internet. >SPI may be a candiate, but the two sides may choose the same SPI value. Hence, SPI is probably not a good general solution. >Perhaps this problem >should be resolved at IKMP layer rather than at IPSEC layer ? Yes. IKMP layer functions need to create an _entire_ IPsec Security Association (not just the key) and put that into place on both sides of the session. The IPsec layer only deals with whole IPsec Security Associations that have already been created either manually or dynamically (just the key alone is not sufficient and doesn't conform with the RFCs). >The only thing the IKMP layer needs to do is to give IPSEC layer >a 1-bit flag to indicate direction. False. IKMP must give the IPsec layer an _entire_ IPsec Security Association, not just a key and a direction bit. In fact, a direction bit probably is not part of the explicit Security Association. Direction is clear from the Security Association because the Security Association contains the destination address as one of its component. >I know that and pairs >can be used to derive 2 uni-directional keys. But can IPSEC assumes >cookies will always be used ? It is not clear to me what you mean by "IPsec" in the above text. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa26150; 1 May 96 19:45 EDT Received: by relay.tis.com; id TAA00261; Wed, 1 May 1996 19:46:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000259; Wed, 1 May 96 19:46:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23888; Wed, 1 May 96 19:46:27 EDT Received: by relay.tis.com; id TAA00256; Wed, 1 May 1996 19:46:05 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma000254; Wed, 1 May 96 19:45:47 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id TAA11731 for ; Wed, 1 May 1996 19:48:42 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.2.250.126]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id TAA40093 for ; Wed, 1 May 1996 19:48:27 -0400 Message-Id: <199605012348.TAA40093@mailhub1.watson.ibm.com> Received: from yktvmv.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with BSMTP id 3195; Wed, 01 May 96 19:48:22 EDT Date: Wed, 1 May 96 19:48:22 EDT From: "Pau-Chen Cheng (863-7446)" To: ipsec@TIS.COM Subject: Unidirectional SA (key) Sender: ipsec-approval@neptune.tis.com Precedence: bulk Folks, I must apologize for bringing this issue up. After thinking it over again, it seems to me that this problem is naturally solved by the key management protocol. If the KMP is designed to generate 2 uni-directional SA's with different key values in one round, then there is no problem. If it is designed to generate only 1 uni-directional SA in one round, then another round is necessary to generate an SA for the other direction. Again, sorry for the mix-up on my part. Regards, Pau-Chen Received: from relay.tis.com by neptune.TIS.COM id aa06499; 2 May 96 9:55 EDT Received: by relay.tis.com; id JAA07451; Thu, 2 May 1996 09:56:37 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007438; Thu, 2 May 96 09:56:08 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07475; Thu, 2 May 96 09:56:28 EDT Received: by relay.tis.com; id JAA07435; Thu, 2 May 1996 09:56:07 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma007432; Thu, 2 May 96 09:55:54 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa24324; 2 May 96 9:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-esp-des-md5-01.txt Date: Thu, 02 May 96 09:37:34 -0400 Message-Id: <9605020937.aa24324@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined DES-CBC, HMAC and Replay Prevention Security Transform Author(s) : J. Hughes Filename : draft-ietf-ipsec-esp-des-md5-01.txt Pages : 12 Date : 04/30/1996 This draft describes a combination of privacy and optionally, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-des-md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960430111952.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960430111952.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa10397; 6 May 96 8:54 EDT Received: by relay.tis.com; id IAA27852; Mon, 6 May 1996 08:55:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027850; Mon, 6 May 96 08:55:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21864; Mon, 6 May 96 08:55:48 EDT Received: by relay.tis.com; id IAA27847; Mon, 6 May 1996 08:55:28 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1) id xma027845; Mon, 6 May 96 08:55:09 -0400 Received: from ftp.com by ftp.com ; Mon, 6 May 1996 08:57:48 -0400 Received: from athena.ftp.com by ftp.com ; Mon, 6 May 1996 08:57:48 -0400 Message-Id: <2.2.32.19960506130057.003228c0@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 May 1996 09:00:57 -0400 To: ipsec@TIS.COM From: Naganand Doraswamy Subject: ISAKMP and Oakley drafts Sender: ipsec-approval@neptune.tis.com Precedence: bulk The recent draft announcement of ISAKMP and Oakley refer to version 04 and 00 respectively. However, the Cisco code that was released mentions that the implementations are based on drafts 05 and 01 for ISAKMP and Oakley respectively. Can someone give me pointers to the latest drafts and send mail to the mailing stating when these will be available as internet-drafts? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.tis.com by neptune.TIS.COM id aa10523; 7 May 96 17:57 EDT Received: by relay.tis.com; id RAA18955; Tue, 7 May 1996 17:37:21 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018947; Tue, 7 May 96 17:36:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16725; Tue, 7 May 96 17:37:13 EDT Received: by relay.tis.com; id RAA18939; Tue, 7 May 1996 17:36:51 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma018932; Tue, 7 May 96 17:36:22 -0400 Received: from research.att.com by ns; Tue May 7 17:37:06 EDT 1996 Received: from raptor.research.att.com by research; Tue May 7 17:36:14 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id RAA23819 for ; Tue, 7 May 1996 17:36:14 -0400 (EDT) Message-Id: <199605072136.RAA23819@raptor.research.att.com> To: ipsec@TIS.COM Subject: MD5 considered insecure? Date: Tue, 07 May 1996 17:36:13 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk There is reason to suspect that MD5 will not be secure for very much longer. Enclosed below, with permission, is a short note by Hans Dobbertin on a partial cryptanalysis of MD5. We should seriously consider making SHA and/or RIPEMD-160 a mandatory-to-implement transform as well, in my opinion. --Steve Bellovin P.S. My thanks to David Wagner for showing me this paper. ---- %!PS-Adobe-2.0 %%Creator: dvipsk 5.58a Copyright 1986, 1994 Radical Eye Software %%Title: md5-compress.dvi %%Pages: 2 %%PageOrder: Ascend %%BoundingBox: 0 0 596 842 %%DocumentPaperSizes: a4 %%EndComments %DVIPSCommandLine: dvips md5-compress %DVIPSParameters: dpi=300, compressed, comments removed %DVIPSSource: TeX output 1996.05.02:1222 %%BeginProcSet: texc.pro /TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N /X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72 mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1} ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul TR[matrix currentmatrix{dup dup round sub abs 0.00001 lt{round}if} forall round exch round exch]setmatrix}N /@landscape{/isls true N}B /@manualfeed{statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{ /nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{ /sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0] N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{ 128 ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 sub]/id ch-image N /rw ch-width 7 add 8 idiv string N /rc 0 N /gp 0 N /cp 0 N{rc 0 ne{rc 1 sub /rc X rw}{G}ifelse}imagemask restore}B /G{{id gp get /gp gp 1 add N dup 18 mod S 18 idiv pl S get exec}loop}B /adv{cp add /cp X}B /chg{rw cp id gp 4 index getinterval putinterval dup gp add /gp X adv}B /nd{/cp 0 N rw exit}B /lsh{rw cp 2 copy get dup 0 eq{pop 1}{ dup 255 eq{pop 254}{dup dup add 255 and S 1 and or}ifelse}ifelse put 1 adv}B /rsh{rw cp 2 copy get dup 0 eq{pop 128}{dup 255 eq{pop 127}{dup 2 idiv S 128 and or}ifelse}ifelse put 1 adv}B /clr{rw cp 2 index string putinterval adv}B /set{rw cp fillstr 0 4 index getinterval putinterval adv}B /fillstr 18 string 0 1 17{2 copy 255 put pop}for N /pl[{adv 1 chg} {adv 1 chg nd}{1 add chg}{1 add chg nd}{adv lsh}{adv lsh nd}{adv rsh}{ adv rsh nd}{1 add adv}{/rc X nd}{1 add set}{1 add clr}{adv 2 chg}{adv 2 chg nd}{pop nd}]dup{bind pop}forall N /D{/cc X dup type /stringtype ne{] }if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{ cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin 0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore userdict /eop-hook known{eop-hook}if showpage}N /@start{userdict /start-hook known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X /IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for 65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V {}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7 getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false} ifelse}{false}ifelse end{{gsave TR -.1 .1 TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1 .1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave newpath transform round exch round exch itransform moveto rulex 0 rlineto 0 ruley neg rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta 0 N /tail {dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}B /c{-4 M} B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{3 M}B /k{ 4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w}B /q{ p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p a}B /bos{/SS save N}B /eos{SS restore}B end %%EndProcSet TeXDict begin 39158280 55380996 1000 300 300 (md5-compress.dvi) @start /Fa 43 124 df<130413181330136013C013801201EA0300A21206120E120C12 1C1218A212381230A21270A21260A312E0A35AA51260A31220123012107E0E267B9B10> 40 D<134013601320133013101318AB1338A21330A21370A2136013E013C0A212011380 120313001206A25A5A12105A5A5A0D267F9B10>I<121812381278123812081210A21220 A212401280050B7D830C>44 DI<137CEA0186EA03031206 000C1380121CA21238A338700700A4EAE00EA35BA213185BEA60606C5A001FC7FC11187C 9714>48 D<1308131813301370EA01F0EA0E70EA00E0A4EA01C0A4EA0380A4EA0700A45A EAFFE00D187C9714>I<13031480EB0700A3130EA35BA213185BA25B5B13C6EA018EEA03 0EEA021C120412081210EA7FB838807F8038003800A25BA41360111F7F9714>52 D<38030180EBFF0013FCEA022048C7FCA45AEA0BE0EA0C181208EA001CA412201270485A EA8030EA40705BEA2180001EC7FC11187C9714>I<131EEB6180EA0180EA03031206000E C7FC5A12181238EA39F0EA7218EA740CEA780E127012F012E0A35BA2EA60385BEA30C0EA 1F8011187C9714>I<1206120F121E120C1200A81230127812F0126008107C8F0C>58 D<1420146014E0A2130114F0EB0270A213041308A21310A213201340A2EB8038EBFFF838 0100381202A25AA25A121838FE01FF181A7E991D>65 D67 D<3803FFF83800700E80809038E00180A315C0EA01 C0A43903800380A3150048485AA2140E140C000E131C5C5C5C381C0380D8FFFEC7FC1A1A 7D991D>I<0003B5FC380070071403140113E0A43801C080A313C13803FF001381A3EA07 02EB0004A21408120E1418141014304813E0B5FC181A7D991A>I<0003B5FC3800700714 03140113E0A43801C080A313C13803FF001381A3EA070290C7FCA3120EA4121EEAFFC018 1A7D9919>I73 D77 D79 D<3803FFF83800701C1406140713E0A43801C00EA2 141C143838038060EBFF80EB8000A248C7FCA4120EA45AB47E181A7D991A>I<3803FFF0 3800701C140E140713E0A43801C00E141C143814E03803FF80EB80C014601470EA0700A4 000E13E0A214E114E248136238FF803C181A7D991C>82 DI<383FFFFC38381C0C002013041240133812 80A338007000A45BA4485AA4485AA41207EAFFF8161A79991B>I97 D99 DII<1307EB0980131B EB3B00133813301370A4EA07FFEA00E0A5485AA5485AA490C7FC5AA21206126612E412CC 1270112181990C>I<13F338038B8038060700120E120C121CEA380EA4EA301CA3EA183C 5BEA07B8EA0038A25B1260EAE0E0EAC1C0007FC7FC11177E8F12>II<1203120712061200A61238124C124E128E129CA2121C1238A21270 1272A212E212E41264123808197C980C>I<121F1207A3120EA4121CA41238A41270A412 E4A412E81230081A7D990A>108 D<38307C1E38598663399E0783801403129CA239380E 0700A3140ED8701C1340A2141C158038E0380C39601807001A107C8F1F>II< EA01F0EA0618EA0C0CEA180E12301270126012E0A2130C131C13181330EA6060EA30C0EA 1F000F107C8F14>II114 DI<1206120EA45AA2EA FFC0EA1C005AA45AA412E1A312E212E412380A177C960D>III< 38380C10384C0E38EA4E1C008E1318129CA2381C38101238A338707020A2144012303818 B880380F0F0015107C8F19>I121 D123 D E /Fb 7 116 df82 D99 D<13FE3807FF80380F87C0381E01E0003E13F0EA7C0014F812FCA2B5FCA200FC C7FCA3127CA2127E003E13186C1330380FC0703803FFC0C6130015167E951A>101 DI<38FF07E0EB1FF8381F307CEB403CEB803EA21300AE39FFE1FFC0A21A 167E951F>110 D114 DI E /Fc 11 116 df45 D53 D68 D<00FCEB07E0A300EE130DA3 00E71319A3EB803900E31331EBC071A200E11361A2EBE0E1A200E013C113F1EB7181A3EB 3B01A3131EA313001B1D7C9C24>77 D99 D101 D<38E3F03F39EFF8FF80D8FFFD13C039F81F81E038F00F00EAE00EAD1B127D9124> 109 D111 DI114 DI E /Fd 1 55 df<1460A214C0A2EB0180A3EB0300A21306A25BA25BA35BA25BA25B A2485AA248C7FCA31206A25AA25AA25AA35AA25A124013287A9D00>54 D E /Fe 17 121 df48 D<12035AA25A5AB4FCA212E71207AEEAFFF8A30D197B9816>III<137C13FC13DC1201EA039CA2EA071C120F120E121E123C1238127812 F0B512E0A338001C00A53801FFC0A313197F9816>II<13F8EA03FC487EEA0F07EA1C0F1238EA78060070C7FCA2EAE3F8EAEFFCB4 7EEAF80F487EEB038012E0A21270A2130700381300EA3C1EEA1FFC6C5AEA03E011197E98 16>I<12E0B51280A338E00F00131EEA001C5B137813705BA2485AA3485AA448C7FCA711 1A7E9916>III<13E0487EA213B0A2EA03B8A31318EA071CA5EA0E0EA2EA0FFEA2487EEA1C07A3 387E0FC038FF1FE0387E0FC013197F9816>65 DI<3801F180EA07FBEA0FFFEA1F0FEA3C07EA38031270A200F0C7FC5AA77E387003 80A21238383C0700EA1F0FEA0FFE6C5AEA01F011197E9816>II<387FFFC0B5FC7EEA1C01A490C7FCA2131CA2EA1FFCA3EA1C1CA290C7FC14 E0A5EA7FFFB5FC7E13197F9816>I<387FFFE0B5FC7EEA1C00A41400A2131CA2EA1FFCA3 EA1C1CA290C7FCA6EA7F80487E6C5A13197F9816>I<387F1FC0133F131F380F1E006C5A EA03B813F012016C5A12017FEA03B8EA073C131CEA0E0E387F1FC038FF3FE0387F1FC013 127F9116>120 D E /Ff 2 106 df<14C01303EB0700131C1378EA01E0EA0780000EC7FC 123812F0A21238120E6C7EEA01E0EA0078131C1307EB03C0130012147D901A>60 D<1206120712061200A41238124CA2128C12981218A212301232A21264A2123808147F93 0C>105 D E /Fg 7 106 df<126012F0A2126004047C830C>58 D<126012F0A212701210 A41220A212401280040C7C830C>II<3801FFC038003C001338A45BA45BA4485AA4485AA448C7FCA45A EAFFE0121C7E9B12>73 D<39FFC00FF0391C00038015001402A25C5C121E000E5B143014 205CA25C49C7FC120FEA07025BA25BA25B5BEA03A013C05BA290C8FCA21C1D7D9B18>86 D<3A01FFC0FF803A001E003C00011C13306D13205D010F5B6D48C7FC1482EB038414CCEB 01D814F05C130080EB0170EB0278EB04381308EB103CEB201CEB401EEB800E3801000F00 027F1206001E497E39FF803FF0211C7F9B22>88 D105 D E /Fh 7 116 df99 D101 D<38E3C0F038EFF3FC38F8761C38F03C0EA2EAE038AC17117D9020>109 D111 DI114 DI E /Fi 5 89 df<126012F0A2126004047D830B>58 D<126012F0A212701210A31220A21240A204 0B7D830B>I73 D<39FF801FE0391C000700140614045C121E000E5B5CA25C14C05CD80F01 C7FC120713025BA25B5BEA039013A013C0A25BA290C8FC1B1A7E9916>86 D<3901FF01FE39003C00F01540011C1380EC0100EB0E025CEB0F086D5A14A0EB03C0A213 011303497E1304497EEB1070EB2078EB4038138048487E120248131E121EB4EB7FC01F1A 7F9920>88 D E /Fj 2 51 df<1218127812981218AC12FF08107D8F0F>49 D<121FEA6180EA40C0EA806012C01200A213C0EA0180EA030012065AEA10201220EA7FC0 12FF0B107F8F0F>I E /Fk 10 58 df<120FEA30C0EA6060A2EA4020EAC030A9EA4020EA 6060A2EA30C0EA0F000C137E9211>48 D<120C121C12EC120CAFEAFFC00A137D9211>I< 121FEA60C01360EAF07013301260EA0070A2136013C012011380EA02005AEA08101210EA 2020EA7FE012FF0C137E9211>II<136013E0A2EA0160 12021206120C120812101220126012C0EAFFFCEA0060A5EA03FC0E137F9211>III<1240EA7FFC13F8EA4010EA 80301320EA00401380EA0100A25A12021206A2120EA512040E147E9311>II<120FEA3080EA6040EA4060EAC0201330A31240EA6070EA30 B0EA0F30120013201360EAE0401380EA4100123E0C137E9211>I E /Fl 21 118 df45 D<127812FCA4127806067D850D>I<3838 0180383FFF005B5B5B13C00030C7FCA4EA31F8EA361E38380F80EA3007000013C014E0A3 127812F8A214C012F038600F8038381F00EA1FFEEA07F0131B7E9A18>53 D<90381FE0209038FFF8E03803F80F3807C003380F800148C7FC123E1560127E127C00FC 1400A8007C1460127E123E15C07E390F8001803907C003003803F80E3800FFFCEB1FE01B 1C7D9B22>67 DI77 D99 DII< 137F3801E3803803C7C0EA0787120FEB8380EB8000A5EAFFF8A2EA0F80AEEA7FF0A2121D 809C0F>I104 D<121E123FA4121EC7FCA6127FA2121FAEEAFFC0A20A1E7F9D0E>I108 D<39FF0FC07E903831E18F3A1F40F20780D980FC13C0 A2EB00F8AB3AFFE7FF3FF8A225127F9128>I<38FF0FC0EB31E0381F40F0EB80F8A21300 AB38FFE7FFA218127F911B>II<38FF3F80EBE1 E0381F80F0EB0078147C143C143EA6143C147C1478EB80F0EBC1E0EB3F0090C7FCA6EAFF E0A2171A7F911B>I 114 DI<1203A45AA25AA2EA3FFC12FFEA1F00A9 130CA4EA0F08EA0798EA03F00E1A7F9913>I<38FF07F8A2EA1F00AC1301120F380786FF EA01F818127F911B>I E /Fm 26 119 df<127012F8A312700505798414>46 D<1306130EA2131CA21338A21370A213E0A2EA01C0A2EA0380A3EA0700A2120EA25AA25A A25AA25AA25A0F1D7E9914>I64 D<3801F180EA07FFEA0E1FEA1C071238EA7003A348C7FCA738700380A338380700121CEA 0E0EEA07FCEA01F011177F9614>67 D73 D79 D83 D97 D<12FCA2121CA513F8EA1DFEEA1F07EA1E03001C1380EB01C0 A6EB0380001E1300EA1F0EEA1DFCEA0CF81217809614>II<137EA2130E A5EA07CEEA0FFEEA1C3EEA301EEA700E12E0A61270EA301EEA383E381FEFC0EA07CF1217 7F9614>II<13FCEA01FEEA038EEA07041300A3EA7FFE12 FFEA0700ACEAFFF8A20F177F9614>I<12FCA2121CA51378EA1DFEEA1F86EA1E07121CAA 38FF8FE0A21317809614>104 D<1206120FA21206C7FCA4B4FCA21207ACEAFFF8A20D18 7C9714>I<12FCA2121CA5EBFF80A2EB1C005B5B5BEA1DC0EA1FE0A2EA1E70EA1C38133C 131C7F38FF1F80A21117809614>107 DIIIII114 DI<1206120EA4EA7FFC12FFEA0E00A8130EA3131CEA07 F8EA01F00F157F9414>II<38FE 3F80A2383C1E00EA1C1CA36C5AA3EA0630EA0770A36C5AA311107F8F14>I E /Fn 70 127 df11 D<13FEEA038138060180EA0E03381C010090C7FCA5B51280EA 1C03AE38FF8FF0141A809915>II34 D<126012F012F812681208A31210A212201240050B7D990B>39 D<1380EA010012025A120C120812185AA35AA412E0AA1260A47EA37E1208120C12047E7E EA008009267D9B0F>I<7E12407E7E12181208120C7EA37EA41380AA1300A41206A35A12 08121812105A5A5A09267E9B0F>I<126012F0A212701210A31220A21240A2040B7D830B> 44 DI<126012F0A2126004047D830B>I48 D<12035AB4FC1207B3A2EA7FF80D187D9713>III<1318A21338137813F813B8EA01381202A212041208121812101220 124012C0B5FCEA0038A6EA03FF10187F9713>III<1240 EA7FFF13FEA2EA4004EA80081310A2EA00201340A21380120113005AA25A1206A2120EA5 120410197E9813>III<1260 12F0A212601200A8126012F0A2126004107D8F0B>I<126012F0A212601200A8126012F0 A212701210A31220A21240A204177D8F0B>I 61 D<130CA3131EA2132F1327A2EB4380A3EB81C0A200017F1300A248B47E38020070A2 487FA3487FA2003C131EB4EBFFC01A1A7F991D>65 DI IIIII<39FFE1FFC0390E001C00 AB380FFFFC380E001CAC39FFE1FFC01A1A7F991D>III76 DI<00FEEB7FC0000FEB0E001404EA0B80EA09C0A2EA08 E01370A21338131CA2130E1307EB0384A2EB01C4EB00E4A21474143CA2141C140C121C38 FF80041A1A7F991D>I<137F3801C1C038070070000E7F487F003C131E0038130E007813 0F00707F00F01480A80078EB0F00A20038130E003C131E001C131C6C5B6C5B3801C1C0D8 007FC7FC191A7E991E>II82 DI< 007FB5FC38701C0700401301A200C0148000801300A300001400B13803FFE0191A7F991C >I<39FFE07FC0390E000E001404B200065B12076C5B6C6C5A3800E0C0013FC7FC1A1A7F 991D>I<39FF801FC0391C00070014066C1304A36C5BA26C6C5AA36C6C5AA26C6C5AA3EB 7080A213790139C7FCA2131EA3130CA21A1A7F991D>I<3AFF81FF07F03A3C007801C000 1CEC0080A36C90389C0100A33907010E02A33903830F04EB8207A2150C3901C40388A339 00E801D0A390387000E0A301305B01201340241A7F9927>I92 D97 D<12FC121CA913FCEA1D07381E0380381C01C0130014E0A6EB01C01480381E0300EA1906 EA10F8131A809915>II<133F1307A9EA03E7EA0C17EA180F487E127012E0A6126012706C5A EA1C373807C7E0131A7F9915>IIII<12FC121CA9137CEA1D87381E0380A2121CAB38FF9FF0141A809915>I<1218 123CA212181200A612FC121CAE12FF081A80990A>I<12FC121CA9EB1FC0EB0F00130C5B 13205B13E0121DEA1E70EA1C7813387F131E7F148038FF9FE0131A809914>107 D<12FC121CB3A6EAFF80091A80990A>I<38FC7C1F391D8E6380391E0781C0A2001C1301 AB39FF9FE7F81D107F8F20>I III114 DI<1208A41218A21238EAFFC0EA3800A813 20A41218EA1C40EA07800B177F960F>I<38FC1F80EA1C03AB1307120CEA0E0B3803F3F0 1410808F15>I<38FF0F80383C0700EA1C061304A26C5AA26C5AA3EA03A0A2EA01C0A36C 5A11107F8F14>I<39FE7F1F8039381C0700003C1306381C0C04130E380E16081317A238 072310149013A33803C1A014E0380180C0A319107F8F1C>I<38FF0F80383C0700EA1C06 1304A26C5AA26C5AA3EA03A0A2EA01C0A36C5AA248C7FCA212E112E212E4127811177F8F 14>121 DII126 D E /Fo 59 127 df<137E3801C180EA0301380703C0120EEB018090C7 FCA5B512C0EA0E01B0387F87F8151D809C17>12 D<1380EA0100120212065AA25AA25AA3 5AA412E0AC1260A47EA37EA27EA27E12027EEA0080092A7C9E10>40 D<7E12407E12307EA27EA27EA37EA41380AC1300A41206A35AA25AA25A12205A5A092A7E 9E10>I<1306ADB612E0A2D80006C7FCAD1B1C7E9720>43 D<126012F0A212701210A412 20A212401280040C7C830C>II<126012F0A2126004047C830C> I48 D<5A1207123F12C71207B3A5EAFFF80D1C7C9B15 >I II<130C A2131C133CA2135C13DC139CEA011C120312021204120C1208121012301220124012C0B5 12C038001C00A73801FFC0121C7F9B15>II<13F0EA030CEA0404EA0C0EEA181E1230130CEA7000A21260EAE3E0EA E430EAE818EAF00C130EEAE0061307A51260A2EA7006EA300E130CEA1818EA0C30EA03E0 101D7E9B15>I56 DI<126012F0A212601200AA126012F0A2126004127C910C>I<126012 F0A212601200AA126012F0A212701210A41220A212401280041A7C910C>I<007FB512C0 B612E0C9FCA8B612E06C14C01B0C7E8F20>61 D<1306A3130FA3EB1780A2EB37C01323A2 EB43E01341A2EB80F0A338010078A2EBFFF83802003CA3487FA2000C131F80001E5BB4EB FFF01C1D7F9C1F>65 DI<90381F8080EBE061380180 1938070007000E13035A14015A00781300A2127000F01400A8007014801278A212386CEB 0100A26C13026C5B380180083800E030EB1FC0191E7E9C1E>III<39FFF0FFF0390F000F00AC90B5FCEB 000FAD39FFF0FFF01C1C7F9B1F>72 DI77 D80 D82 D<3807E080EA1C19EA30051303EA600112E01300A36C13007E127CEA7FC0EA3FF8EA1FFE EA07FFC61380130FEB07C0130313011280A300C01380A238E00300EAD002EACC0CEA83F8 121E7E9C17>I<007FB512C038700F010060130000401440A200C014201280A300001400 B1497E3803FFFC1B1C7F9B1E>I<39FFF01FF0390F000380EC0100B3A26C130213800003 5BEA01C03800E018EB7060EB0F801C1D7F9B1F>I<3AFFE1FFC0FF3A1F003E003C001E01 3C13186C6D1310A32607801F1320A33A03C0278040A33A01E043C080A33A00F081E100A3 9038F900F3017913F2A2017E137E013E137CA2013C133C011C1338A20118131801081310 281D7F9B2B>87 D<12FEA212C0B3B312FEA207297C9E0C>91 D<12FEA21206B3B312FEA2 0729809E0C>93 D97 D<12FC121CAA137CEA1D87381E01 80381C00C014E014601470A6146014E014C0381E018038190700EA10FC141D7F9C17>I< EA03F8EA0C0CEA181E1230EA700CEA600012E0A61260EA70021230EA1804EA0C18EA03E0 0F127F9112>III<13F8EA 018CEA071E1206EA0E0C1300A6EAFFE0EA0E00B0EA7FE00F1D809C0D>II<12FC121CAA137C1387EA1D03001E1380121CAD38FF9FF0141D7F9C17>I<1218123CA2 1218C7FCA712FC121CB0EAFF80091D7F9C0C>I<12FC121CAAEB0FE0EB0780EB06005B13 105B5B13E0121DEA1E70EA1C781338133C131C7F130F148038FF9FE0131D7F9C16>107 D<12FC121CB3A9EAFF80091D7F9C0C>I<39FC7E07E0391C838838391D019018001EEBE0 1C001C13C0AD3AFF8FF8FF8021127F9124>IIII114 DI<1204A4120CA2121C123CEAFFE0EA1C00A9 1310A5120CEA0E20EA03C00C1A7F9910>I<38FC1F80EA1C03AD1307120CEA0E1B3803E3 F014127F9117>I<38FF07E0383C0380381C0100A2EA0E02A2EA0F06EA0704A2EA0388A2 13C8EA01D0A2EA00E0A3134013127F9116>I<39FF3FC7E0393C0703C0001CEB01801500 130B000E1382A21311000713C4A213203803A0E8A2EBC06800011370A2EB803000001320 1B127F911E>I<38FF0FE0381E0700EA1C06EA0E046C5AEA039013B0EA01E012007F1201 1338EA021C1204EA0C0E487E003C138038FE1FF014127F9116>I<38FF07E0383C038038 1C0100A2EA0E02A2EA0F06EA0704A2EA0388A213C8EA01D0A2EA00E0A31340A25BA212F0 00F1C7FC12F312661238131A7F9116>I126 D E /Fp 17 122 df<00181306381F803EEBFFFC5C5C5C148049C7FC0018C8FCA7EB7F80 3819FFF0381B80F8381E007E00187FC7FCEC1F80A215C0A3127C12FEA315805A0078133F 006014006C133E001C5B380F01F83807FFE0C690C7FC1A277DA621>53 D<91387FE002903907FFF80690391FE01E0E90397F00039E01FCEB01FE4848EB007ED807 F0143E5B4848141E001F150E485AA21606127F90C8FC16005AA97EA26D1406123FA36C6C 140C120F6C6C14186D1438D801F814306C6C14E0017FEB03C090391FE00F00903807FFFC 9038007FE027297CA830>67 DI77 D<3803FF80000F13E0381F01F8383F80FC147EA280EA1F00C7FCA4 EB3FFF3801FE3FEA0FE0EA1F80EA3F005A12FE150CA3145F007F139F393F831FF8391FFE 0FF03903F807C01E1B7E9A21>97 D101 DI<120FEA1F8013C0 123FA2121F1380EA0F00C7FCA8EAFFC0A2120FB3A5EAFFF8A20D2B7EAA13>105 D108 D<26FFC0FEEB3F80903AC3FF80FF E03B0FC60FC183F0903AC807E201F89039D003E40001F001FC7F01E05BA201C05BB13CFF FC3FFF0FFFC0A2321B7E9A37>I<38FFC0FE9038C3FF80390FC60FC09038C807E0EBD003 01F013F013E0A213C0B139FFFC3FFFA2201B7E9A25>II<38FFC1FE9038C7FF8039 0FDE0FE09038F003F09038E001F801C013FC140015FEA2157FA8157E15FEA215FC140101 E013F89038F007F09038DC0FE09038C7FF809038C1FC0001C0C7FCAAEAFFFCA220277E9A 25>I<38FF83E0EB8FF8380F8C7CEB98FE13B013A0A2EBE07CEBC000B1EAFFFEA2171B7E 9A1B>114 D<3803FC60381FFFE0EA3C03EA7801EA700000F01360A300FC1300B47EEA7F FC13FF6C13C0000F13E0000313F0EA003FEB03F8EAC00014787EA27E14706C13E0EAFE03 38E7FF803881FE00151B7E9A1A>I<1360A413E0A21201A212031207121FB512E0A23807 E000AE1430A73803F0603801F8C03800FF80EB3F0014267FA51A>I<39FFF801FFA2390F C000707F000714606D13E0000314C07F0001EB0180A23900FC0300A26D5AEB7E06EB7F0E EB3F0C148CEB1F98A2EB0FF0A36D5AA26D5AA26D5AA249C7FCA25BEA3006EAFC0E130C5B 1338EA7870EA3FE0EA1F8020277F9A23>121 D E end %%EndProlog %%BeginSetup %%Feature: *Resolution 300dpi TeXDict begin %%PaperSize: a4 %%BeginPaperSize: a4 a4 %%EndPaperSize %%EndSetup %%Page: 1 1 1 0 bop 430 194 a Fp(Crypt)n(an)n(alys)q(i)q(s)20 b(of)i(MD5)f(Compre)r (s)q(s)759 340 y Fo(Hans)14 b(Dobb)q(ert)o(in)589 427 y Fn(Germ)o(an)f(Inform)o(a)o(t)o(ion)i(Secur)q(it)o(y)f(Agency)615 473 y(e-m)o(ail:)g Fm(dobbertin@)o(sk)o(om.)o(rh)o(ein)o(.de)800 566 y Fn(May)f(2,)g(1996)245 665 y Fo(In)19 b(1991)f(t)n(h)o(e)i(h)o (ash)f(fu)o(nct)o(ion)h(MD5)e(w)o(as)h(in)o(tro)q(d)o(u)o(ce)q(d)h(b)o (y)f(Ron)g(Riv)o(e)q(st)g(as)g(stren)o(g-)183 715 y(t)n(h)o(en)o(e)q(d) e(v)o(ers)q(ion)f(of)f(MD4.)g(Be)q(s)q(id)o(e)j(som)o(e)d(ot)n(h)o(er)i (mo)q(di\014ca)o(t)o(ions)d(t)n(h)o(e)j(n)n(u)o(m)n(b)q(er)e(of)h(rou)o (n)o(ds)183 765 y(i)q(s)d(ext)o(en)o(d)o(e)q(d)i(f)q(rom)d(t)n(hree)k (t)o(o)e(four.)245 817 y(In)19 b(t)n(hi)q(s)g(sh)o(ort)g(not)o(e)g(w)o (e)g(rep)q(ort)h(a)o(b)q(ou)o(t)f(an)g(a)o(t)n(t)o(ac)o(k)g(on)g(t)n(h) o(e)g(compre)q(ss)h(fu)o(nct)o(ion)f(of)183 867 y(MD5,)11 b(whic)o(h)i(i)q(s)f(bas)q(e)q(d)i(on)e(s)q(imilar)e(m)o(et)n(h)o(o)q (ds)j(as)g(previous)g(a)o(t)n(t)o(ac)o(ks)g(on)g(RIPEMD,)f(MD4)183 917 y(an)o(d)k(t)n(h)o(e)h(256-bit)e(ext)o(ens)q(ion)i(of)f(MD4)g(\(s)q (ee)h([4)o(],)f([5)o(]\).)g(Belo)o(w)g(w)o(e)h(giv)o(e)f(a)g Fl(co)o(lli)q(s)q(ion)1553 902 y Fk(1)1585 917 y Fl(of)183 966 y(t)n(h)o(e)e(compre)q(s)q(s)h(fu)o(nct)o(ion)e(of)i(MD5)p Fo(.)245 1019 y(Recall)i(t)n(h)o(a)o(t)h(in)g(1993)f(Bert)i(d)o(en)g (Bo)q(er)g(an)o(d)f(An)o(t)o(o)q(on)g(Boss)q(elaers)j([3)o(])c(sh)o(o)o (w)o(e)q(d)i(h)o(o)o(w)183 1068 y Fl(p)q(s)q(eudo-co)o(ll)o(i)o(s)q(i)o (ons)12 b Fo(\(in)k(our)f(t)o(erminology\))e(of)i(MD5)h(compre)q(ss)g (can)g(b)q(e)g(fou)o(n)o(d.)f(Ma)o(t)n(t)183 1118 y(Robsh)o(aw)e (\([8],)g(Rem)o(ar)o(k)g(1)g(in)h(Sect)o(ion)g(4.1\))f(comm)o(en)o(t)o (e)q(d)f(t)n(hi)q(s)h(a)o(t)n(t)o(ac)o(k)i(as)e(follo)o(w:)253 1206 y Fn(\\As)f(it)h(st)o(an)o(ds,)g(t)n(h)o(e)g(ps)q(eudo-colli)q(s)q (ion)i(ar)q(i)q(s)q(e)q(s)e(f)q(rom)e(init)o(iali)q(zi)q(n)o(g)16 b(t)n(h)o(e)c(four-w)o(ord)h(bu\013er)253 1252 y(a)o(t)d(t)n(h)o(e)h (st)o(art)g(of)f(MD5)g(t)o(o)h(t)o(w)o(o)f(di\013eren)o(t)i(v)n(alue)q (s.)f(Th)o(e)q(s)q(e)f(v)n(alue)q(s)i(di\013er)g(only)f(in)h(t)n(h)o(e) e(MSB)253 1298 y(of)16 b(eac)o(h)h(of)f(t)n(h)o(e)h(four)f(w)o(ords.)g (Th)o(e)g(sam)o(e)g(m)o(e)q(ssage)h(i)q(s)g(us)q(e)q(d)f(for)g(b)q(ot)n (h)h(s)q(ets)f(of)g(bu\013er)253 1343 y(v)n(alue)q(s)f(an)o(d)e(t)n(h)o (e)h(sam)o(e)f(m)o(e)q(ssage)h(dige)q(st)g(i)q(s)f(obt)o(ain)o(e)q(d.) 253 1391 y(A)c(f)q(ar)g(more)h(s)q(er)q(ious)g(\015aw)f(w)o(ould)i(b)q (e)e(if)h(it)g(w)o(ere)f(p)q(oss)q(ible)j(t)o(o)e(c)o(h)o(o)q(os)q(e)g (on)o(e)g(init)o(ial)i(st)o(art)o(in)o(g)253 1437 y(v)n(alue)k(for)f(t) n(h)o(e)g(bu\013er,)h(not)f(n)o(ece)q(ssar)q(ily)j(t)n(h)o(e)d(on)o(e)h (giv)o(en)g(in)f(t)n(h)o(e)h(algor)q(it)n(hm,)g(an)o(d)g(t)n(h)o(en)253 1482 y(c)o(h)o(o)q(os)q(e)c(t)o(w)o(o)f(di\013eren)o(t)h(m)o(e)q(ssage) q(s,)g(p)q(erh)o(aps)h(di\013er)q(in)o(g)g(in)f(only)g(a)f(few)g(bits)g (of)g(on)o(e)g(w)o(ord,)253 1528 y(so)i(t)n(h)o(a)o(t)h(t)n(h)o(e)f (sam)o(e)h(m)o(e)q(ssage)g(dige)q(st)g(i)q(s)f(obt)o(ain)o(e)q(d.")183 1618 y Fo(Th)o(e)18 b(la)o(t)n(t)o(er)g(d)o(e)q(scr)q(ib)q(e)q(s)i (preci)q(s)q(ely)e(wh)o(a)o(t)g(i)q(s)f(don)o(e)h(no)o(w.)f(W)m(e)g(t)n (hink)h(t)n(h)o(a)o(t)g(t)n(hi)q(s)g(migh)o(t)e(b)q(e)183 1668 y(reason)f(enough)f(t)o(o)g(su)n(bst)o(it)o(u)o(t)o(e)i(MD5)d(in)g (fu)o(t)o(ure)i(ap)o(plica)o(t)o(ions.)245 1720 y(Al)o(t)o(er)q(n)o(a)o (t)o(iv)o(e)q(s)e(for)g(MD5)f(are)i(SHA-1)e([1])g(an)o(d)h(on)f(t)n(h)o (e)i(ot)n(h)o(er)g(h)o(an)o(d)e(RIPEMD-160)g([6],)183 1770 y(whic)o(h)k(h)o(as)g(b)q(een)h(d)o(e)q(s)q(ign)o(e)q(d)g(as)f(a)g (stren)o(gt)n(h)o(en)o(e)q(d)j(v)o(ers)q(ion)e(of)e(RIPEMD)h([2])f(b)o (y)h(An)o(t)o(o)q(on)183 1820 y(Boss)q(elaers,)g(Bart)e(Pren)o(eel)h (an)o(d)f(t)n(h)o(e)h(a)n(u)o(t)n(h)o(or)g(t)o(akin)o(g)e(accou)o(n)o (t)i(of)e(t)n(h)o(e)h(recen)o(t)i(an)o(alys)q(i)q(s)c(of)183 1869 y(MD4-lik)o(e)g(h)o(ash)i(fu)o(nct)o(ions.)p 183 1905 237 2 v 191 1932 a Fj(1)221 1948 y Fn(Us)q(in)o(g)g(t)n(h)o(e)f(t) o(erm)g(\\colli)q(s)q(ion)i(of)d(a)h(compre)q(ss)h(fu)o(nct)o(ion")h(w) o(e)d(assu)o(m)o(e)i(t)n(h)o(a)o(t)f(t)n(h)o(e)h(init)o(ial)h(v)n(alue) f(i)q(s)221 1994 y(t)n(h)o(e)g(sam)o(e)g(for)g(b)q(ot)n(h)g(inpu)o(ts,) h(i.e.)f(an)g(init)o(ial)i(v)n(alue)f Fi(I)s(V)22 b Fn(an)o(d)15 b(t)o(w)o(o)e(di\013eren)o(t)i(inpu)o(ts)h Fi(X)g Fn(an)o(d)1600 1984 y(~)1589 1994 y Fi(X)221 2039 y Fn(are)d(giv)o(en)h(su)o(c)o(h)g (t)n(h)o(a)o(t)613 2126 y Fh(comp)o(re)q(ss)n Fn(\()p Fi(I)s(V)9 b Fn(;)d Fi(X)s Fn(\))k(=)h Fh(comp)o(re)q(ss)n Fn(\()p Fi(I)s(V)e Fn(;)1183 2117 y(~)1172 2126 y Fi(X)s Fn(\))p Fi(:)221 2213 y Fn(On)14 b(t)n(h)o(e)h(ot)n(h)o(er)g(h)o(an)o (d)h(w)o(e)e(us)q(e)g(t)n(h)o(e)h(t)o(erm)f(\\ps)q(eudo-colli)r(s)q (ion")j(if)e(t)o(w)o(o)f(di\013eren)o(t)i(init)o(ial)h(v)n(alue)q(s)221 2258 y Fi(I)s(V)r(;)298 2249 y Fn(~)282 2258 y Fi(I)s(V)22 b Fn(an)o(d)13 b(\(p)q(oss)q(ibly)j(id)o(en)o(t)o(ical\))f(inpu)o(ts)g Fi(X)q(;)927 2249 y Fn(~)917 2258 y Fi(X)g Fn(are)e(giv)o(en)h(su)o(c)o (h)g(t)n(h)o(a)o(t)613 2345 y Fh(comp)o(re)q(ss)n Fn(\()p Fi(I)s(V)9 b Fn(;)d Fi(X)s Fn(\))k(=)h Fh(comp)o(re)q(ss)n Fn(\()1120 2336 y(~)1104 2345 y Fi(I)s(V)e Fn(;)1183 2336 y(~)1172 2345 y Fi(X)s Fn(\))p Fi(:)221 2432 y Fn(Ps)q(eudo-colli) q(s)q(ions)16 b(are)d(of)g(m)n(u)o(c)o(h)h(le)q(ss)g(pract)o(ical)h (imp)q(ort)o(ance)f(t)n(h)o(an)g(colli)q(s)q(ions.)p eop %%Page: 2 2 2 1 bop 340 194 a Fl(Co)o(lli)q(s)q(ion)9 b(for)j(t)n(h)o(e)g(compre)q (s)q(s)f(fu)o(nct)o(ion)f(of)i(MD5.)18 b Fo(Us)q(e)12 b(t)n(h)o(e)g(follo)o(win)o(g)c(init)o(ial)h(v)n(alue)340 244 y Fg(I)s(V)24 b Fo(an)o(d)14 b(d)o(e\014n)o(e)h(t)n(h)o(e)f (\014rst)h(inpu)o(t)f Fg(X)i Fo(=)11 b(\()p Fg(X)1014 250 y Ff(i)1029 244 y Fo(\))1045 250 y Ff(i<)p Fk(16)1132 244 y Fo(b)o(y)i(s)q(et)n(t)o(in)o(g:)549 335 y Fg(I)s(V)22 b Fo(=)11 b Fe(0x12AC2375)h(0x3B341042)g(0x5F62B97C)g(0x4BA763ED)346 409 y Fg(X)380 415 y Fk(0)411 409 y Fo(=)g Fe(0xAA1DDA5E)37 b Fg(X)746 415 y Fk(4)776 409 y Fo(=)12 b Fe(0x1006363E)37 b Fg(X)1111 415 y Fk(8)1142 409 y Fo(=)12 b Fe(0x98A1FB19)37 b Fg(X)1477 415 y Fk(12)1524 409 y Fo(=)12 b Fe(0x1326ED65)346 459 y Fg(X)380 465 y Fk(1)411 459 y Fo(=)g Fe(0xD97ABFF5)37 b Fg(X)746 465 y Fk(5)776 459 y Fo(=)12 b Fe(0x7218209D)37 b Fg(X)1111 465 y Fk(9)1142 459 y Fo(=)12 b Fe(0x1FAE44B0)37 b Fg(X)1477 465 y Fk(13)1524 459 y Fo(=)12 b Fe(0xD93E0972)346 509 y Fg(X)380 515 y Fk(2)411 509 y Fo(=)g Fe(0x55F0E1C1)37 b Fg(X)746 515 y Fk(6)776 509 y Fo(=)12 b Fe(0xE01C135D)21 b Fg(X)1095 515 y Fk(10)1142 509 y Fo(=)12 b Fe(0x236BB992)37 b Fg(X)1477 515 y Fk(14)1524 509 y Fo(=)12 b Fe(0xD458C868)346 559 y Fg(X)380 565 y Fk(3)411 559 y Fo(=)g Fe(0x32774244)37 b Fg(X)746 565 y Fk(7)776 559 y Fo(=)12 b Fe(0x9DA64D0E)21 b Fg(X)1095 565 y Fk(11)1142 559 y Fo(=)12 b Fe(0x6B7A669B)37 b Fg(X)1477 565 y Fk(15)1524 559 y Fo(=)12 b Fe(0x6B72746A)340 658 y Fo(Th)o(e)k(s)q(econ)o(d)h(inpu)o(t)685 647 y(~)673 658 y Fg(X)h Fo(=)d(\()800 647 y(~)788 658 y Fg(X)822 664 y Ff(i)836 658 y Fo(\))852 664 y Ff(i<)p Fk(16)941 658 y Fo(i)q(s)g(d)o(e\014n)o(e)q(d)i(b)o(y)e(s)q(et)n(t)o(in)o(g)1336 647 y(~)1324 658 y Fg(X)1358 664 y Ff(i)1387 658 y Fo(=)f Fg(X)1467 664 y Ff(i)1497 658 y Fo(\()p Fg(i)h(<)f Fo(16)p Fg(;)7 b(i)14 b Fd(6)p Fo(=)h(14\))340 707 y(an)o(d)432 697 y(~)420 707 y Fg(X)454 713 y Fk(14)501 707 y Fo(=)d Fg(X)579 713 y Fk(14)624 707 y Fo(+)d(2)686 692 y Fk(9)705 707 y Fo(.)k(Th)o(en)h(w)o(e)g(h)o(a)o(v)o(e)g(a)f(colli)q(s)q(ion,)e (i.e.)625 793 y Fc(MD5-comp)o(re)q(ss)n Fo(\()p Fg(I)s(V)f Fo(;)d Fg(X)s Fo(\))12 b(=)g Fc(MD5-comp)o(re)q(ss)n Fo(\()p Fg(I)s(V)e Fo(;)1444 782 y(~)1432 793 y Fg(X)s Fo(\))p Fg(;)340 878 y Fo(an)o(d)k(t)n(hi)q(s)g(common)d(compre)q(ss)k (v)n(alue)e(i)q(s)587 963 y Fe(0xBF90E670)f(0x752AF92B)f(0x9CE4E3E1)h (0xB12CF8DE)n Fg(:)340 1048 y Fo(Th)o(e)j(compu)o(t)o(a)o(t)o(ion)d(of) h(su)o(c)o(h)i(a)e(colli)q(s)q(ion)e(t)o(ak)o(e)q(s)k(a)o(b)q(ou)o(t)f (10)f(h)o(ours)h(on)g(a)g(P)o(en)o(t)o(iu)o(m)e(PC.)340 1183 y Fb(Reference)r(s)340 1278 y Fn(1.)21 b(FIPS)13 b(180-1,)d Fa(Se)n(cur)n(e)f(hash)g(standar)n(d,)e Fn(NIST,)i(US)g (Depart)o(m)o(en)o(t)i(of)e(Comm)o(erce,)h(W)m(ashin)o(gt)o(on)391 1324 y(D.C.,)i(A)n(pr)q(il)i(1995.)340 1370 y(2.)21 b(RIPE)10 b(Consort)o(iu)o(m,)h Fa(R)o(ip)n(e)f(Inte)n(grity)e(Primitives)h({)i (Final)e(r)n(ep)n(ort)h(of)g(RA)o(CE)h(Inte)n(grity)d(Prim-)391 1415 y(itives)k(Evaluation)f(\(R1040\))p Fn(,)f(LNCS)i(1007,)i(Spr)q (in)o(ger-V)m(erlag,)h(1995.)340 1461 y(3.)21 b(B.)15 b(d)o(en)i(Bo)q(er,)f(A.)f(Boss)q(elaers,)j Fa(Col)r(lisions)13 b(for)j(the)f(c)n(ompr)n(ession)f(function)g(of)h(MD5)p Fn(,)g(Ad-)391 1507 y(v)n(ance)q(s)g(in)h(Crypt)o(ology)m(,)f(Pro)q(c.) g(Euro)q(crypt'93,)g(LNCS)e(765,)h(T.)e(Helle)q(s)q(et)n(h,)k(Ed.,)e (Spr)q(in)o(ger-)391 1552 y(V)m(erlag,)f(1994,)h(p)o(p.)e(293{304.)340 1598 y(4.)21 b(H.)f(Dobb)q(ert)o(in,)i Fa(RIPEMD)f(with)f(two-r)n(ound) f(c)n(ompr)n(ess)g(function)f(is)j(not)e(c)n(ol)r(lision-fr)n(e)n(e)p Fn(,)391 1644 y(Jour)q(n)o(al)14 b(of)f(Crypt)o(ology)m(,)h(t)o(o)f(ap) o(p)q(ear.)340 1689 y(5.)21 b(H.)d(Dobb)q(ert)o(in,)h Fa(Cryptanalysis)d(of)i(MD4)p Fn(,)g(F)m(ast)g(Soft)o(w)o(are)g (Encrypt)o(ion,)i(LNCS)13 b(1039,)18 b(D.)391 1735 y(Gollm)o(ann,)d (Ed.,)d(Spr)q(in)o(ger-V)m(erlag,)k(1996,)d(p)o(p.)g(53{69.)340 1781 y(6.)21 b(H.)c(Dobb)q(ert)o(in,)h(A.)f(Boss)q(elaers,)i(an)o(d)f (B.)f(Pren)o(eel:)h Fa(RIPEMD-160:)e(A)h(str)n(engthene)n(d)d(ver-)391 1826 y(sion)e(of)g(RIPEMD)p Fn(,)g(F)m(ast)g(Soft)o(w)o(are)g(Encrypt)o (ion,)i(Cam)n(br)q(idge)f(W)m(orksh)o(o)o(p,)g(LNCS)f(1039,)g(D.)391 1872 y(Gollm)o(ann,)j(Ed.,)d(Spr)q(in)o(ger-V)m(erlag,)k(1996,)d(p)o (p.)g(71-82.)1209 1856 y Fj(2)340 1918 y Fn(7.)21 b(R.)13 b(Riv)o(e)q(st,)h Fa(The)f(MD5)h(message)e(digest)g(algorithm)p Fn(,)e(RF)o(C)j(1321,)g(A)n(pr)q(il)h(1992.)340 1963 y(8.)21 b(M.)13 b(Robsh)o(aw,)i Fa(On)f(pseudo-c)n(o)o(l)r(lis)o(ion)o (s)d(in)j(MD5)p Fn(,)f(T)m(ec)o(hnical)h(Rep)q(ort)h(TR-102,)e(v)o(ers) q(ion)i(1.1,)391 2009 y(RSA)e(La)o(b)q(ora)o(t)o(or)q(ie)q(s,)i(July)f (1994.)p 340 2343 237 2 v 349 2370 a Fj(2)379 2386 y Fn(Thi)q(s)d(\014rst)h(pu)n(blica)o(t)o(ion)i(st)o(ill)f(con)o(t)o (ains)g(som)o(e)e(bugs.)h(Th)o(e)f(correct)o(e)q(d)g(v)o(ers)q(ion)i (can)e(b)q(e)g(obt)o(ain)o(e)q(d)379 2432 y(u)o(n)o(d)o(er)k Fm(ftp.esat.)o(ku)o(leu)o(ve)o(n.a)o(c.)o(be)10 b Fn(in)j(t)n(h)o(e)h (direct)o(ory)h Fm(/pub/COSI)o(C/)o(bos)o(se)o(lae)o(/ri)o(pe)o(md/)o Fn(.)1050 2556 y Fo(2)p eop %%Trailer end userdict /end-hook known{end-hook}if %%EOF Received: from relay.tis.com by neptune.TIS.COM id aa11347; 7 May 96 18:44 EDT Received: by relay.tis.com; id SAA19562; Tue, 7 May 1996 18:45:51 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019557; Tue, 7 May 96 18:45:22 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17998; Tue, 7 May 96 18:45:42 EDT Received: by relay.tis.com; id SAA19552; Tue, 7 May 1996 18:45:21 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma019547; Tue, 7 May 96 18:45:06 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA16578; Tue, 7 May 1996 15:47:47 -0700 Date: Tue, 7 May 1996 15:47:47 -0700 From: Ran Atkinson Message-Id: <199605072247.PAA16578@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: MD5 considered insecure? In-Reply-To: <199605072136.RAA23819@raptor.research.att.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, Thanks very much for sharing that paper with us. Its quite short, but very interesting reading. Everyone, In my own personal mind, it raises the question of how we should proceed on the AH transforms. Possible options for the WG to consider include at least these: - Make both HMAC MD5 and HMAC SHA-1 mandatory-to-implement - Make HMAC MD5 optional-to-implement and HMAC SHA-1 mandatory-to-implement One question I have is whether it would be sensible to substitute HMAC SHA-1 for HMAC MD5 in the ESP "DES-CBC HMAC MD5 Replay" transform. What do folks think is best ? I'm hoping to see some discussion on the list about how to proceed after folks have had the time to read and digest the material Steve has passed along. Ran rja@inet.org Received: from relay.tis.com by neptune.TIS.COM id aa13135; 7 May 96 21:06 EDT Received: by relay.tis.com; id VAA21165; Tue, 7 May 1996 21:07:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021160; Tue, 7 May 96 21:07:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19867; Tue, 7 May 96 21:07:26 EDT Received: by relay.tis.com; id VAA21157; Tue, 7 May 1996 21:07:05 -0400 Received: from portal.visa.com(198.80.42.2) by relay.tis.com via smap (V3.1) id xma021155; Tue, 7 May 96 21:06:56 -0400 Received: by portal.visa.com id AA14058 (InterLock SMTP Gateway 3.0 for ipsec@TIS.COM); Wed, 8 May 1996 01:09:31 GMT Message-Id: <199605080109.AA14058@portal.visa.com> Date: Tue, 7 May 1996 19:03:00 -0700 From: "Smith, David" Subject: RE: MD5 considered insecure? To: ipsec X-Mailer: Worldtalk(NetConnex V3.50c)/stream Sender: ipsec-approval@neptune.tis.com Precedence: bulk For those of us who don't get MIME objects well, could someone please provide a net reference to where the MD5 paper can be found. Thanks. David Smith Visa International Received: from relay.tis.com by neptune.TIS.COM id aa13415; 7 May 96 21:29 EDT Received: by relay.tis.com; id VAA21259; Tue, 7 May 1996 21:30:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021257; Tue, 7 May 96 21:30:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20092; Tue, 7 May 96 21:30:26 EDT Received: by relay.tis.com; id VAA21254; Tue, 7 May 1996 21:30:05 -0400 Received: from odin.ucsd.edu(132.239.51.3) by relay.tis.com via smap (V3.1) id xma021249; Tue, 7 May 96 21:29:43 -0400 Received: from work.ucsd.edu by odin.ucsd.edu; id AA14423 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Tue, 7 May 96 18:32:24 -0700 for ipsec@TIS.COM Received: from work.ucsd.edu (localhost [127.0.0.1]) by work.ucsd.edu (8.7.1/8.7.1) with ESMTP id SAA06871; Tue, 7 May 1996 18:32:12 -0700 (PDT) Message-Id: <199605080132.SAA06871@work.ucsd.edu> To: "Smith, David" Cc: ipsec Reply-To: Bennet Yee Subject: Re: MD5 considered insecure? In-Reply-To: Your message of "Tue, 07 May 1996 19:03:00 -0700." <199605080109.AA14058@portal.visa.com> Date: Tue, 07 May 1996 18:32:09 -0700 From: Bennet Yee Sender: ipsec-approval@neptune.tis.com Precedence: bulk http://www.cs.ucsd.edu/users/bsy/dobbertin.ps is a copy of the PostScript file. -------- Bennet S. Yee Phone: +1 619 534 4614 Email: bsy@cs.ucsd.edu Web: http://www-cse.ucsd.edu/users/bsy/ USPS: Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114 Received: from relay.tis.com by neptune.TIS.COM id aa16064; 8 May 96 1:15 EDT Received: by relay.tis.com; id BAA22322; Wed, 8 May 1996 01:16:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022320; Wed, 8 May 96 01:16:07 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22943; Wed, 8 May 96 01:16:27 EDT Received: by relay.tis.com; id BAA22317; Wed, 8 May 1996 01:16:05 -0400 Received: from unknown(129.34.139.6) by relay.tis.com via smap (V3.1) id xma022315; Wed, 8 May 96 01:16:05 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id BAA21400; Wed, 8 May 1996 01:18:57 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/4/8/96) id AA23119; Wed, 8 May 1996 01:18:41 -0400 From: Uri Blumenthal Message-Id: <9605080518.AA23119@hawpub.watson.ibm.com> Subject: Re: MD5 considered insecure? To: Ran Atkinson Date: Wed, 8 May 1996 01:18:41 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <199605072247.PAA16578@puli.cisco.com> from "Ran Atkinson" at May 7, 96 03:47:47 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran Atkinson says: > In my own personal mind, it raises the question of how we should proceed > on the AH transforms. Possible options for the WG to consider include > at least these: > - Make both HMAC MD5 and HMAC SHA-1 mandatory-to-implement > - Make HMAC MD5 optional-to-implement and HMAC SHA-1 mandatory-to-implement The second one makes much more sense. Why would we be mandating something that we know isn't likely to stay "good" for long? > One question I have is whether it would be sensible to substitute HMAC SHA-1 > for HMAC MD5 in the ESP "DES-CBC HMAC MD5 Replay" transform. What do folks > think is best ? This substitution seems the most logical choice. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa17294; 8 May 96 2:41 EDT Received: by relay.tis.com; id CAA22801; Wed, 8 May 1996 02:43:06 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022799; Wed, 8 May 96 02:42:38 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23732; Wed, 8 May 96 02:42:57 EDT Received: by relay.tis.com; id CAA22796; Wed, 8 May 1996 02:42:36 -0400 Received: from kekec.e5.ijs.si(193.138.1.2) by relay.tis.com via smap (V3.1) id xma022794; Wed, 8 May 96 02:42:11 -0400 Received: by kekec.e5.ijs.si id AA02041 (5.67b/IDA-1.5 for ipsec@TIS.COM); Wed, 8 May 1996 08:47:02 +0200 Date: Wed, 8 May 1996 08:47:02 +0200 From: Denis Trcek Message-Id: <199605080647.AA02041@kekec.e5.ijs.si> To: -v@e5.ijs.si, ipsec@TIS.COM Subject: Re: MD5 considered insecure? Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Steve, > > Thanks very much for sharing that paper with us. Its quite short, >but very interesting reading. I must have overlooked or not received some e-mails. Would it be possible to resend the paper (or URL)? Thank you. Denis ************************************************************* ************ * Denis Trcek O O * * * * "Jozef Stefan" Institute O O * * * * Jamova 39, 61 111 Ljubljana, SLOVENIA O O * * * * e-mail: denis.trcek@e5.ijs.si denis.trcek@ijs.si O * * * * Tel.:+386 61 1259 199, Fax:+386 61 1261 029, +386 61 273 677 * * * ******************************************************************* ****** Received: from relay.tis.com by neptune.TIS.COM id aa28275; 8 May 96 15:15 EDT Received: by relay.tis.com; id PAA04717; Wed, 8 May 1996 15:16:42 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004714; Wed, 8 May 96 15:16:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18089; Wed, 8 May 96 15:16:33 EDT Received: by relay.tis.com; id PAA04708; Wed, 8 May 1996 15:16:13 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma004703; Wed, 8 May 96 15:16:00 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA290893118; Wed, 8 May 1996 12:18:39 -0700 Message-Id: <199605081918.AA290893118@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA143693163; Wed, 8 May 1996 15:19:23 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: Ran Atkinson , Steven Bellovin Cc: ipsec@TIS.COM Subject: Re: MD5 considered insecure? In-Reply-To: rja's message of Tue, 07 May 1996 15:47:47 -0700. <199605072247.PAA16578@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 08 May 1996 15:18:37 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I'm hoping to see some discussion on the list about how to proceed after folks have had the time to read and digest the material Steve has passed along. The paper says "the computation of such a collision takes about 10 hours on a pentium PC", but it doesn't give the starting conditions of the attack -- is it free to choose the IV and both inputs (in which case it's not likely to turn into a practical attack), or are any of those values fixed? Given that HMAC uses (essentially) secret IV's, it's not clear how much danger this attack presents to HMAC-MD5, as opposed to systems which hash only plaintext and then sign the hash.. Anyone have more details? - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMZDzhlpj/0M1dMJ/AQF3nAP9Geq0tUv9lPkl8UvmdW1CY874CLZ4YhlR hePDfZOv34LlZ06KFohIHfyk20ShF01Dk5kX/upuLMmb9bFJtqiIXXBYWGkEdWrh FF5DlzsR3CTd8dyoH7xNyS+ec5nhlKs+dxkpuPDm+pzo67I0OsF2pVuS3AxQ1UDy 8IS5NpZzNT4= =SMPS -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa29444; 8 May 96 16:30 EDT Received: by relay.tis.com; id QAA06353; Wed, 8 May 1996 16:31:12 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006346; Wed, 8 May 96 16:30:44 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21019; Wed, 8 May 96 16:31:03 EDT Received: by relay.tis.com; id QAA06343; Wed, 8 May 1996 16:30:42 -0400 Received: from unknown(129.34.139.6) by relay.tis.com via smap (V3.1) id xma006339; Wed, 8 May 96 16:30:30 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id QAA13090 for ; Wed, 8 May 1996 16:33:19 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.2.250.126]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id QAA25413 for ; Wed, 8 May 1996 16:33:03 -0400 Message-Id: <199605082033.QAA25413@mailhub1.watson.ibm.com> Received: from yktvmv.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with BSMTP id 1333; Wed, 08 May 96 16:32:58 EDT Date: Wed, 8 May 96 16:32:58 EDT To: IPSEC@TIS.COM Subject: HMAC-MD5: to be or not to be? Sender: ipsec-approval@neptune.tis.com Precedence: bulk As it has been already announced in this list, MD5 is broken for collisions (Hans Dobbertin has extended his own techniques used against MD4 to attack MD5 as well). MD5 needs to be dropped (hope everyone already did) from any use that requires resistance to collisions by plain MD5. One application that is NOT broken with Dobbertin's attack is HMAC with MD5. Collisions in plain MD5 do not compromise HMAC-MD5 as the latter uses secret IVs and hides the result of the inner iterated function. The question is whether the new attack has a significant potential of being developed further to break also HMAC-MD5. Beyond our own assessment we have got the opinion of a few first line cryptographers that they see no way to make these techniques work against the use of MD5 in HMAC. With permission of Hans Dobbertin I reproduce this note he sent to me over the weekend in response to my question of whether he sees any application of his results to break HMAC-MD5: Date: Sat, 4 May 1996 22:48:09 +0200 (MET DST) From: Hans Dobbertin <> To: "H.Krawczyk" Hi Hugo, I looked in your paper which you have sent me in January. To answer your question I can assure you that I cannot image any way to attack MD5 as it is used in HMAC. To be more precise, from the recent attack on MD5 (compress) one cannot derive any reservation against the use of MD5 in this context. (Perhaps one could argue that the randomness of MD5 is not sufficiently investigated ..., but that is another question, and I personally do not see a problem here.) Best regards, Hans This does not mean in any way that HMAC-MD5 is going to be secure forever. It is only to stress that the new attack is not necessarily a reason to drop MD5 from its current use in IPSEC. I believe that we can keep using it until new developments will bring HMAC-MD5 closer to a break. Remember this "principle" from draft-ietf-ipsec-hmac-md5-txt.00: Message authentication, as opposed to encryption, has a "transient" effect. A published breaking of a message authentication scheme would lead to the replacement of that scheme, but would have no adversarial effect on information authenticated in the past. This is in sharp contrast with encryption, where information encrypted today may suffer from exposure in the future if, and when, the encryption algorithm is broken. Following this principle I believe we can keep enjoying the better speed of MD5 at least for some time (weeks? months? years? who knows?) Just to stress this: there is NO known security advantage in keeping MD5 relative to going to SHA-1. The only issue here is performance. It is there where the trade-off seems to favor MD5 right now. Having said all of this here is a short note on the theory behind HMAC-MD5. In our paper we have chosen to make much stronger assumptions than needed on the underlying hash function. This is motivated by the search of easy to state and well-defined assumptions together with a simple and correct analysis. One of these assumptions on the hash function which we call "weakly collision resistance" requires resistance to collisions when the IV is secret. In a strict sense such collisions can be found for MD5 using Dobbertin's techniques. However, this is possible through extension attacks that are prevented in HMAC by the outer application of MD5. Therefore, the actual function HMAC-MD5 remains secure. In our coming Crypto'96 paper we will elaborate more on the analytical issues and strength of assumptions. In particular, we may suggest an additional (more conservative) variant of HMAC in which one appends a key to the data before hashing (in the inner transformation). However, this has to be seen as "yet another fence" and not something for which there is clear indication that we need to adopt immediately. Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always very attentive to updates from the cryptanalytic front.) Hugo Received: from relay.tis.com by neptune.TIS.COM id aa04226; 10 May 96 11:01 EDT Received: by relay.tis.com; id LAA07437; Fri, 10 May 1996 11:02:24 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007428; Fri, 10 May 96 11:02:00 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18012; Fri, 10 May 96 11:02:14 EDT Received: by relay.tis.com; id LAA07419; Fri, 10 May 1996 11:01:54 -0400 Received: from unknown(192.32.253.3) by relay.tis.com via smap (V3.1) id xma007401; Fri, 10 May 96 11:01:39 -0400 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id LAA24155; Fri, 10 May 1996 11:06:10 -0400 Received: from gopher.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA02343; Fri, 10 May 96 11:04:14 EDT Date: Fri, 10 May 96 11:04:14 EDT From: Cheryl Madson Message-Id: <9605101504.AA02343@pobox.BayNetworks.com> To: ipsec@TIS.COM Subject: The various incantations of MD5... Cc: cmadson@baynetworks.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk So far, what I'm hearing is "MD5 is probably OK in HMAC". It isn't clear to me what the recommendation is for other uses of MD5, apart from a blanket statement to "punt it". I tend to see such statements as knee-jerk reactions, which cause me to have my own knee-jerk reaction (usually in the opposite direction ;-). I've been trying to classify the uses of MD5, to get a better sense of where it's critical to replace MD5 with something else, and where the use of MD5 isn't a risk. My off-the-cuff list: 1) MD5 hashes to generate "bits"; something along these lines: 3DES key1 = MD5(1|secret value) key2 = MD5(2|secret value) key3 = MD5(3|secret value) 2) keyed MD5, where the shared secret key is inserted into the digest field for calculation purposes; this field is then overwritten by the digest. Examples: OSPF, RIP, ... 3) keyed MD5 used like PPP CHAP [I can't remember how it's done, except I remember it's different than (2)] 4) HMAC-style hashes 5) MD5 in public-key signed hash functions 6) ... It sounds like we have more of an answer on #4 than any of the others. MD5 is already being used by more than IPSEC. I think we should be more formally describing the characteristics where "MD5 is safe to use" vs. "MD5 is risky to use", so we can better advise other WGs as to what they should do. Maybe in some cases MD5 is OK provided that certain things (e.g. paramters to MD5?) are done differently. Right now, I wouldn't feel comfortable going to any other WG and telling them that they absolutely had to replace MD5 with something else. Maybe it isn't necessary, or maybe more is necessary than simply replacing the algorithm, in light of HMAC, followed by the recent news of MD5. - C Received: from relay.tis.com by neptune.TIS.COM id aa14680; 13 May 96 10:34 EDT Received: by relay.tis.com; id KAA28941; Mon, 13 May 1996 10:36:11 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028939; Mon, 13 May 96 10:35:44 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16612; Mon, 13 May 96 10:35:58 EDT Received: by relay.tis.com; id KAA28936; Mon, 13 May 1996 10:35:41 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma028934; Mon, 13 May 96 10:35:32 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11741; 13 May 96 10:34 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-oakley-01.txt Date: Mon, 13 May 96 10:34:25 -0400 Message-Id: <9605131034.aa11741@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The OAKLEY Key Determination Protocol Author(s) : H. Orman Filename : draft-ietf-ipsec-oakley-01.txt Pages : 48 Date : 05/10/1996 This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user-defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-oakley-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-oakley-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960513102709.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-oakley-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-oakley-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960513102709.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa02110; 14 May 96 9:21 EDT Received: by relay.tis.com; id JAA13673; Tue, 14 May 1996 09:23:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013671; Tue, 14 May 96 09:22:34 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22881; Tue, 14 May 96 09:22:48 EDT Received: by relay.tis.com; id JAA13663; Tue, 14 May 1996 09:22:32 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma013656; Tue, 14 May 96 09:22:13 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14849; 14 May 96 9:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-oakley-01.txt Date: Tue, 14 May 96 09:10:34 -0400 Message-Id: <9605140910.aa14849@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The OAKLEY Key Determination Protocol Author(s) : H. Orman Filename : draft-ietf-ipsec-oakley-01.txt Pages : 48 Date : 05/10/1996 This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user-defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-oakley-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-oakley-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960510100020.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-oakley-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-oakley-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960510100020.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa17041; 16 May 96 16:37 EDT Received: by relay.tis.com; id QAA00216; Thu, 16 May 1996 16:39:13 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000205; Thu, 16 May 96 16:38:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10747; Thu, 16 May 96 16:38:53 EDT Received: by relay.tis.com; id QAA00202; Thu, 16 May 1996 16:38:39 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1) id xma000197; Thu, 16 May 96 16:38:28 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id NAA23071; Thu, 16 May 1996 13:40:25 -0700 Received: from monster.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id NAA22979; Thu, 16 May 1996 13:41:25 -0700 Received: by monster.incog.com (SMI-8.6/SMI-SVR4) id NAA07527; Thu, 16 May 1996 13:41:31 -0700 Date: Thu, 16 May 1996 13:41:31 -0700 From: Tom Markson Message-Id: <199605162041.NAA07527@monster.incog.com> To: ipsec@TIS.COM Subject: SKIP Developer's Workshop Sender: ipsec-approval@neptune.tis.com Precedence: bulk We're pleased to announce the first SKIP Developers Workshop. This will take place at the San Francisco Airport Marriott Hotel on June 17-19. Everyone is welcome to attend. The workshop will feature: o Direct access to SKIP developers from all over the world o SKIP product demonstrations o Presentations on real-world deployments of SKIP o SKIP interoperability workshop and test lab o Raw AH/ESP interoperability testing (S/WAN compatibility) o In-depth workshops about the SKIP protocols o Future directions for SKIP o Cool SKIP paraphenalia! SKIP is Simple Key management for Internet Protocols. SKIP secures IP network communications using IETF standard transforms and protocols. SKIP supports high availablity, provides extremely low overhead in the establishment of secure IP channels, and has extensions for perfect forward secrecy (PFS) and encrypted/authenticated multicast. Registration is $495.00, and includes lunch on all three days and workshop materials. Payment will be taken on site. To register, contact Judy Nakamura at: email: X1380@applelink.apple.com voice: 415-812-9770 fax: 415-812-9777 Postal mail: 4129 Wilkie Court Palo Alto, CA 94306 A block of hotel rooms has been reserved at the Marriott. Registrants should book their own rooms. Mention the Sun Microsystems SKIP Developers Workshop to obtain the group rate. San Francisco Airport Marriott 1800 Old Bayshore Highway Burlingame, CA 94010 415-692-9100 Received: from relay.tis.com by neptune.TIS.COM id aa17959; 16 May 96 17:34 EDT Received: by relay.tis.com; id RAA02412; Thu, 16 May 1996 17:36:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002410; Thu, 16 May 96 17:35:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12900; Thu, 16 May 96 17:35:54 EDT Received: by relay.tis.com; id RAA02407; Thu, 16 May 1996 17:35:40 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma002405; Thu, 16 May 96 17:35:34 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA12873; Thu, 16 May 1996 14:35:34 -0700 Date: Thu, 16 May 1996 14:35:34 -0700 From: Ran Atkinson Message-Id: <199605162135.OAA12873@puli.cisco.com> To: markson@osmosys.incog.com Subject: Re: SKIP Developer's Workshop In-Reply-To: <199605162041.NAA07527@monster.incog.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <199605162041.NAA07527@monster.incog.com> Tom Markson wrote: [Commercial advertising deleted here] Tom, Blatent commercial advertising, such as for your meeting with high attendance fees, is NOT appropriate use of an IETF mailing list. Please do NOT send such material to the ipsec@tis.com list in future. Ran rja@inet.org Co-Chair, IP Security WG Received: from relay.tis.com by neptune.TIS.COM id aa23125; 16 May 96 23:28 EDT Received: by relay.tis.com; id WAA05138; Thu, 16 May 1996 22:57:13 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005136; Thu, 16 May 96 22:56:44 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18091; Thu, 16 May 96 22:56:57 EDT Received: by relay.tis.com; id WAA05131; Thu, 16 May 1996 22:56:43 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma005127; Thu, 16 May 96 22:56:15 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id TAA26666 for ipsec@tis.com; Thu, 16 May 1996 19:58:52 -0700 Date: Thu, 16 May 1996 19:58:52 -0700 From: Ran Atkinson Message-Id: <199605170258.TAA26666@puli.cisco.com> To: ipsec@TIS.COM Subject: quick survey on MD5 & SHA-1 Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm trying to figure out where folks stand on the matter of which cryptographic hash function the IPsec WG should be using as its default, mandatory-to-implement function. At the LA IETF, there was a very clear consensus that the HMAC technique described by Hugo should be the standard technique used with cryptographi hash functions in the IPsec context. The paper from the German Information Security Agency indicated a partial cryptanalysis, not a full cryptanalysis, of ordinary MD5. Reportedly, that work does not apply to the HMAC technique of using MD5. So there is no known cryptanalysis of MD5 at present, though probably less confidence in MD5 than before. The main alternative to MD5 would be SHA-1 since MD4 is known to be less strong than MD5. Also, neither MD4, MD5, nor SHA-1 have patent problems. Will active members of the WG who have a strong opinion about which cryptographic hash function should be the default mandatory-to-implement algorithm please send an email note to me and to Paul Lambert and indicate your preference and reasoning so we can figure out where folks stand on this question. Thanks, Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa29943; 17 May 96 9:31 EDT Received: by relay.tis.com; id JAA09300; Fri, 17 May 1996 09:32:28 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009291; Fri, 17 May 96 09:31:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29354; Fri, 17 May 96 09:32:12 EDT Received: by relay.tis.com; id JAA09281; Fri, 17 May 1996 09:31:58 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1) id xma009273; Fri, 17 May 96 09:31:55 -0400 Received: from ftp.com by ftp.com ; Fri, 17 May 1996 09:33:58 -0400 Received: from athena.ftp.com by ftp.com ; Fri, 17 May 1996 09:33:58 -0400 Message-Id: <2.2.32.19960517133734.00cc59fc@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 May 1996 09:37:34 -0400 To: swan-dev@rsa.com, ipsec@TIS.COM From: Naganand Doraswamy Subject: AH-SHA implementation Sender: ipsec-approval@neptune.tis.com Precedence: bulk I am in the process of adding SHA-1 support for AH in our product. I would like to know if there are implemetations out there that I could interoperate with. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.tis.com by neptune.TIS.COM id aa03009; 17 May 96 12:17 EDT Received: by relay.tis.com; id MAA13855; Fri, 17 May 1996 12:18:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013843; Fri, 17 May 96 12:18:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07556; Fri, 17 May 96 12:18:26 EDT Received: by relay.tis.com; id MAA13837; Fri, 17 May 1996 12:18:11 -0400 Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1) id xma013826; Fri, 17 May 96 12:17:55 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA12763 for ipsec@tis.com; Fri, 17 May 1996 09:20:27 -0700 Message-Id: <199605171620.JAA12763@puli.cisco.com> From: Ran Atkinson Date: Fri, 17 May 1996 09:20:26 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Re: quick survey Sender: ipsec-approval@neptune.tis.com Precedence: bulk A bit of "good news, bad news", with the bad first... A couple of people have observed in email that SHA-1 is export-controlled from the US, which is surprising news to me (and in my personal opinion is _incredibly_ stupid since its just a one-way hash function). However, one of those folks provided me with a URL that makes this very clear. The good news is that SHA-1 is under Commerce Department rules, which means that US export licenses should be MUCH MUCH easier to obtain. I'll cut/paste the relevant text from FIPS 180-1 below. I obtained the quoted text from: http://129.6.52.11/fips/fip180-1.txt "Export Control: Implementations of this standard are subject to Federal Government export controls as specified in Title 15, Code of Federal Regulations, Parts 768 through 799. Exporters are advised to contact the Department of Commerce, Bureau of Export Administration for more information." If this changes the views of anyone who already responded via email, please feel free to send a revised email along. Ran rja@cisco.com -- Received: from relay.tis.com by neptune.TIS.COM id aa06485; 17 May 96 15:05 EDT Received: by relay.tis.com; id PAA19567; Fri, 17 May 1996 15:07:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019550; Fri, 17 May 96 15:06:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16231; Fri, 17 May 96 15:07:07 EDT Received: by relay.tis.com; id PAA19545; Fri, 17 May 1996 15:06:53 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma019537; Fri, 17 May 96 15:06:33 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id MAA09054; Fri, 17 May 1996 12:09:08 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id MAA18837; Fri, 17 May 1996 12:12:09 -0700 (PDT) Message-Id: <199605171912.MAA18837@mailsun2.us.oracle.com> Date: 17 May 96 11:54:10 -0700 From: "PALAMBER.US.ORACLE.COM" To: rja@cisco.com Subject: Re: moving forward ? Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:rja@cisco.com's message of 17-May-96 09:11 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-4920843-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-4920843-0-0 Ran, I just called the NSA on SHA export... both MD5 and SHA are both "export controlled", but they are both "under Department of Commerce jurisdiction". Hash algorithms can be readily exported. SHA and MD5 are treated the same for US export considerations. I'd recommend a change from MD5 to SHA ... Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-4920843-0-0 Content-Type: message/rfc822 Date: 17 May 96 09:11:59 From:"Ran Atkinson" To: PALAMBER@us.oracle.com Subject: Re: moving forward ? X-Orcl-Application: In-Reply-To: "PALAMBER.US.ORACLE.COM" X-Orcl-Application: In-Reply-To: "Re: moving forward ?" (May 17, 9:05am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) Umm. There is one small problem with SHA-1. The FIPS PUB 180-1 (http://129.6.52.11/fips/fip180-1.txt) indicates that SHA-1 is export-controlled under Commerce Department rules. MD5 is believed not to be export controlled. This is an issue in many vendors' minds. As long as we use HMAC, I'm indifferent about MD5 or SHA-1. I'm still not seeing anything resembling consensus on key management. We earlier put SKIP into the RFC publication queue for "Experimental" status (it was delayed by the March issuance of "IAB Official Protocols", which caused a backlog at the RFC Editor). Bill Simpson plans to put out Photuris as Experimental eventually. I'm not sure what the status is with ISAKMP and Oakley. I'll ping the folks back east and check... Ran rja@cisco.com -- --Boundary-4920843-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa07193; 17 May 96 15:43 EDT Received: by relay.tis.com; id PAA20570; Fri, 17 May 1996 15:44:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020559; Fri, 17 May 96 15:44:26 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17854; Fri, 17 May 96 15:44:38 EDT Received: by relay.tis.com; id PAA20545; Fri, 17 May 1996 15:44:23 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma020534; Fri, 17 May 96 15:44:09 -0400 Received: from st5.ncsl.nist.gov (st5.ncsl.nist.gov [129.6.55.35]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with SMTP id PAA03267 for ; Fri, 17 May 1996 15:47:01 -0400 (EDT) Message-Id: <199605171947.PAA03267@snad.ncsl.nist.gov> X-Sender: chang@snad.ncsl.nist.gov X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 May 1996 14:35:23 -0400 To: ipsec@TIS.COM From: Shu-jen Chang Subject: Re: export control of SHA Sender: ipsec-approval@neptune.tis.com Precedence: bulk >A couple of people have observed in email that SHA-1 is export-controlled from >the US. > >The good news is that SHA-1 is under Commerce Department rules, which means >that US export licenses should be MUCH MUCH easier to obtain. > It is true that SHA-1 is export-controlled. However, according to the folks at the Computer Security Division, NIST has sent a request to the Commerce Department asking for a more general authorization for distributing DSS and SHA-1. The request seemed to be approved. Unfortunately the person who was handling the case was not available today, therefore, I would have to get back to you next Monday regarding the specific rules for SHA distribution. Shu-jen Received: from relay.tis.com by neptune.TIS.COM id aa09143; 17 May 96 17:33 EDT Received: by relay.tis.com; id RAA23075; Fri, 17 May 1996 17:34:23 -0400 From: gmcgreal@ire.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023066; Fri, 17 May 96 17:33:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21783; Fri, 17 May 96 17:34:07 EDT Received: by relay.tis.com; id RAA23060; Fri, 17 May 1996 17:33:53 -0400 Received: from uu5.psi.com(38.145.226.3) by relay.tis.com via smap (V3.1) id xma023050; Fri, 17 May 96 17:33:33 -0400 Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA24469 for ; Fri, 17 May 96 17:22:10 -0400 Received: from cc:Mail by uu1023.ire.com id AA832373828 Fri, 17 May 96 15:57:08 Date: Fri, 17 May 96 15:57:08 Encoding: 3415 Text Message-Id: <9604178323.AA832373828@uu1023.ire.com> To: ipsec@TIS.COM, Ran Atkinson Subject: Re[2]: quick survey Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran, The Department of State, Bureau of Politico-Military Affairs, in 22 CFR Part 121.1 Category 13 which addresses cryptographic systems specifically excludes "data authentication which calculates a Message Authentication Code (MAC) or similar result to insure no alteration of text has taken place, or to authenticate users" (Section 1(vi)) Only if the authentication is part of a system where encryption is also being carried out would the MAC come under regulation. This would seem to conflict with the information you have. Do you have a reference for that regulation? Gary L. McGreal ______________________________ Reply Separator _________________________________ Subject: Re: quick survey Author: Ran Atkinson at INTERNET Date: 5/17/96 1:27 PM Received: by ccmail Received: from uupsi5 by ire.com (UUPC/extended 1.11) with UUCP; Fri, 17 May 1996 13:22:14 EDT Received: from neptune.tis.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via S MTP; id AA21143 for gmcgreal; Fri, 17 May 96 13:06:43 -0400 Received: from neptune.tis.com by neptune.TIS.COM id aa03026; 17 May 96 12:29 EDT Received: from relay.tis.com by neptune.TIS.COM id aa03009; 17 May 96 12:17 EDT Received: by relay.tis.com; id MAA13855; Fri, 17 May 1996 12:18:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013843; Fri, 17 May 96 12:18:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07556; Fri, 17 May 96 12:18:26 EDT Received: by relay.tis.com; id MAA13837; Fri, 17 May 1996 12:18:11 -0400 Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1) id xma013826; Fri, 17 May 96 12:17:55 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA12763 for ipsec @tis.com; Fri, 17 May 1996 09:20:27 -0700 Message-Id: <199605171620.JAA12763@puli.cisco.com> From: Ran Atkinson X-ccAdmin: bprice@uupsi5 Date: Fri, 17 May 1996 09:20:26 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Re: quick survey Sender: ipsec-approval@neptune.tis.com Precedence: bulk A bit of "good news, bad news", with the bad first... A couple of people have observed in email that SHA-1 is export-controlled from the US, which is surprising news to me (and in my personal opinion is _incredibly_ stupid since its just a one-way hash function). However, one of those folks provided me with a URL that makes this very clear. The good news is that SHA-1 is under Commerce Department rules, which means that US export licenses should be MUCH MUCH easier to obtain. I'll cut/paste the relevant text from FIPS 180-1 below. I obtained the quoted text from: http://129.6.52.11/fips/fip180-1.txt "Export Control: Implementations of this standard are subject to Federal Government export controls as specified in Title 15, Code of Federal Regulations, Parts 768 through 799. Exporters are advised to contact the Department of Commerce, Bureau of Export Administration for more information." If this changes the views of anyone who already responded via email, please feel free to send a revised email along. Ran rja@cisco.com -- Received: from relay.tis.com by neptune.TIS.COM id aa09768; 17 May 96 18:12 EDT Received: by relay.tis.com; id SAA23372; Fri, 17 May 1996 18:13:54 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023367; Fri, 17 May 96 18:13:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22643; Fri, 17 May 96 18:13:37 EDT Received: by relay.tis.com; id SAA23361; Fri, 17 May 1996 18:13:23 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1) id xma023355; Fri, 17 May 96 18:13:02 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 17 May 1996 15:15:33 -0700 Date: Fri, 17 May 1996 15:15:31 -0700 Posted-Date: Fri, 17 May 1996 15:15:31 -0700 Message-Id: <199605172215.AA15753@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 17 May 1996 15:15:31 -0700 To: ipsec@TIS.COM, rja@cisco.com Subject: Re: quick survey on MD5 & SHA-1 X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.tis.com Thu May 16 21:15:22 1996 > Date: Thu, 16 May 1996 19:58:52 -0700 > From: Ran Atkinson > To: ipsec@tis.com > Subject: quick survey on MD5 & SHA-1 > > > I'm trying to figure out where folks stand on the matter of which > cryptographic hash function the IPsec WG should be using as its > default, mandatory-to-implement function. ... > The paper from the German Information Security Agency indicated a partial > cryptanalysis, not a full cryptanalysis, of ordinary MD5. Reportedly, > that work does not apply to the HMAC technique of using MD5. So there > is no known cryptanalysis of MD5 at present, though probably less confidence > in MD5 than before. If the HMAC isn't compromised by this attack, the proposed spec should not be changed. Strength is going to be relative anyway, and chasing the 'strongest MAC at the time of publication' seems like a fleeting goal. The only gain of such a change would appear to be to delay the demonstration implementations. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa00624; 18 May 96 0:43 EDT Received: by relay.tis.com; id AAA00831; Sat, 18 May 1996 00:44:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000829; Sat, 18 May 96 00:44:30 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00652; Sat, 18 May 96 00:44:43 EDT Received: by relay.tis.com; id AAA00823; Sat, 18 May 1996 00:44:28 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma000818; Sat, 18 May 96 00:44:16 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id VAA04431; Fri, 17 May 1996 21:46:53 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id VAA05812; Fri, 17 May 1996 21:49:54 -0700 (PDT) Message-Id: <199605180449.VAA05812@mailsun2.us.oracle.com> Date: 17 May 96 15:19:05 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Yes, you can export SHA and MD5 Mime-Version: 1.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk >The good news is that SHA-1 is under Commerce Department >rules, which means that US export licenses should be >MUCH MUCH easier to obtain. One more time .... to be sure that for this discussion we are clear: SHA and MD5 are both export controled, both are "easy" to export. Export should not be a consideration in the comparison of SHA to MD5. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa00861; 18 May 96 1:06 EDT Received: by relay.tis.com; id BAA01158; Sat, 18 May 1996 01:08:04 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001156; Sat, 18 May 96 01:07:35 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00823; Sat, 18 May 96 01:07:48 EDT Received: by relay.tis.com; id BAA01153; Sat, 18 May 1996 01:07:34 -0400 Received: from south-station-annex.mit.edu(18.72.1.2) by relay.tis.com via smap (V3.1) id xma001151; Sat, 18 May 96 01:07:28 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA07701; Sat, 18 May 96 01:08:40 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA25623; Sat, 18 May 1996 01:10:03 -0400 Date: Sat, 18 May 1996 01:10:03 -0400 Message-Id: <9605180510.AA25623@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@TIS.COM In-Reply-To: PALAMBER.US.ORACLE.COM's message of 17 May 96 15:19:05 -0700, <199605180449.VAA05812@mailsun2.us.oracle.com> Subject: Re: Yes, you can export SHA and MD5 Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1150 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: 17 May 96 15:19:05 -0700 From: "PALAMBER.US.ORACLE.COM" SHA and MD5 are both export controled, both are "easy" to export. Export should not be a consideration in the comparison of SHA to MD5. Well, to be precise, the NSA has made the claim that SHA and MD5 are export controlled, and the NIST's FIPS documenting SHA claims that SHA is export controlled. There seems to be at least some controversy as to what their statutory and regulatory authorities they are using to make either a statement, at least where SHA and MD5 is being used in a system which does not use any encryption methods or which attempts to engage in data hiding. As far as I know, no one on the IPSEC list is a lawyer, and is actively giving legal advise (myself included). You should see your favorite high-priced export control lawyer for an official legal opinion. My own personal belief is that any algorithm suite which is using as a weak an encryption as single DES might as well use HMAC-MD5. If we were going to use triple-DES for encryption it would perhaps make sense to use HMAC-SHA, or some such. - Ted Received: from relay.tis.com by neptune.TIS.COM id aa00916; 18 May 96 1:10 EDT Received: by relay.tis.com; id SAA23287; Fri, 17 May 1996 18:03:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023281; Fri, 17 May 96 18:02:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22422; Fri, 17 May 96 18:03:07 EDT Received: by relay.tis.com; id SAA23278; Fri, 17 May 1996 18:02:53 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma023275; Fri, 17 May 96 18:02:37 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA13372; Fri, 17 May 1996 15:05:11 -0700 Message-Id: <199605172205.PAA13372@puli.cisco.com> From: Ran Atkinson Date: Fri, 17 May 1996 15:05:10 PDT In-Reply-To: gmcgreal@ire.com "Re[2]: quick survey" (May 17, 3:57pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: gmcgreal@ire.com Subject: Re: Re[2]: quick survey Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Gary, I provided a URL in my original note and don't recall that URL off the top of my head. The statement is embedded inside FIPS 180-1 itself. Btw, late breaking news is that someone at NIST is actively looking into the current exportability state of SHA-1. If I get more data, I will pass it along straight away. Ran rja@cisco.com -- Received: from relay.tis.com by neptune.TIS.COM id aa05415; 18 May 96 9:18 EDT Received: by relay.tis.com; id JAA02895; Sat, 18 May 1996 09:20:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xmaa02893; Sat, 18 May 96 09:19:57 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02275; Sat, 18 May 96 09:20:07 EDT Received: by relay.tis.com; id JAA02890; Sat, 18 May 1996 09:19:53 -0400 Received: from unknown(204.96.36.2) by relay.tis.com via smap (V3.1) id xma002888; Sat, 18 May 96 09:19:36 -0400 Received: from ferguson ([199.249.254.9]) by wizard.pn.com (8.6.12) with SMTP id JAA02077; Sat, 18 May 1996 09:21:40 -0400 Message-Id: <199605181321.JAA02077@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 May 1996 09:21:42 -0400 To: gmcgreal@ire.com From: Rodney Thayer Subject: Re: Re[2]: quick survey Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk the reference is: http://cs-www.ncsl.nist.gov/fips/fips180-1.txt Although I should appreciate the 15 minutes of fame I have received for supplying this URL, all I did was to bash on the search button in my web browser. No rocket science involved. I too am not a lawyer, and my interpretation of the document I refer to is "gee this looks like a sufficiently real claim that I should go ask my lawyer about it", no more. At 03:57 PM 5/17/96, you wrote: > > Ran, > > The Department of State, Bureau of Politico-Military Affairs, in 22 > CFR Part 121.1 Category 13 which addresses cryptographic systems > specifically excludes "data authentication which calculates a Message > Authentication Code (MAC) or similar result to insure no alteration of > text has taken place, or to authenticate users" (Section 1(vi)) > > Only if the authentication is part of a system where encryption is > also being carried out would the MAC come under regulation. > > This would seem to conflict with the information you have. Do you have > a reference for that regulation? > > Gary L. McGreal > > > >______________________________ Reply Separator _________________________________ >Subject: Re: quick survey >Author: Ran Atkinson at INTERNET >Date: 5/17/96 1:27 PM > > >Received: by ccmail >Received: from uupsi5 by ire.com (UUPC/extended 1.11) with UUCP; > Fri, 17 May 1996 13:22:14 EDT >Received: from neptune.tis.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via >S MTP; > id AA21143 for gmcgreal; Fri, 17 May 96 13:06:43 -0400 >Received: from neptune.tis.com by neptune.TIS.COM id aa03026; > 17 May 96 12:29 EDT >Received: from relay.tis.com by neptune.TIS.COM id aa03009; 17 May 96 12:17 EDT >Received: by relay.tis.com; id MAA13855; Fri, 17 May 1996 12:18:44 -0400 >Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) > id xma013843; Fri, 17 May 96 12:18:17 -0400 >Received: from relay.tis.com by tis.com (4.1/SUN-5.64) > id AA07556; Fri, 17 May 96 12:18:26 EDT >Received: by relay.tis.com; id MAA13837; Fri, 17 May 1996 12:18:11 -0400 >Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1) > id xma013826; Fri, 17 May 96 12:17:55 -0400 >Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA12763 for >ipsec @tis.com; Fri, 17 May 1996 09:20:27 -0700 >Message-Id: <199605171620.JAA12763@puli.cisco.com> >From: Ran Atkinson >X-ccAdmin: bprice@uupsi5 >Date: Fri, 17 May 1996 09:20:26 PDT >X-Mailer: Mail User's Shell (7.2.5 10/14/92) >To: ipsec@TIS.COM >Subject: Re: quick survey >Sender: ipsec-approval@neptune.tis.com >Precedence: bulk > >A bit of "good news, bad news", with the bad first... > >A couple of people have observed in email that SHA-1 is export-controlled from >the US, which is surprising news to me (and in my personal opinion is >_incredibly_ stupid since its just a one-way hash function). However, >one of those folks provided me with a URL that makes this very clear. > >The good news is that SHA-1 is under Commerce Department rules, which means >that US export licenses should be MUCH MUCH easier to obtain. > >I'll cut/paste the relevant text from FIPS 180-1 below. I obtained >the quoted text from: > http://129.6.52.11/fips/fip180-1.txt > >"Export Control: Implementations of this standard are subject to Federal >Government export controls as specified in Title 15, Code of Federal >Regulations, Parts 768 through 799. Exporters are advised to contact the >Department of Commerce, Bureau of Export Administration for more information." > > >If this changes the views of anyone who already responded via email, >please feel free to send a revised email along. > >Ran >rja@cisco.com > >-- > > Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" Received: from relay.tis.com by neptune.TIS.COM id aa02298; 20 May 96 10:23 EDT Received: by relay.tis.com; id KAA16703; Mon, 20 May 1996 10:25:26 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016689; Mon, 20 May 96 10:24:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21910; Mon, 20 May 96 10:25:09 EDT Received: by relay.tis.com; id KAA16682; Mon, 20 May 1996 10:24:56 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma016678; Mon, 20 May 96 10:24:51 -0400 Received: from sloth.ncsl.nist.gov (sloth.ncsl.nist.gov [129.6.55.36]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with ESMTP id KAA22495; Mon, 20 May 1996 10:26:55 -0400 (EDT) From: Robert Glenn Received: (from glenn@localhost) by sloth.ncsl.nist.gov (8.7.5/8.7.3) id KAA14160; Mon, 20 May 1996 10:26:25 -0400 (EDT) Date: Mon, 20 May 1996 10:26:25 -0400 (EDT) Message-Id: <199605201426.KAA14160@sloth.ncsl.nist.gov> To: ipsec@TIS.COM Subject: Whatever happend to compression? Cc: rob.glenn@nist.gov Sender: ipsec-approval@neptune.tis.com Precedence: bulk The idea of having a transform that performs compression before encryption has come up several times in the past, but I don't believe it has been discussed recently. Notably, compression has not been added to any of the existing transform documents. Along these lines, I have a few questions. 1. Is compression still of interest as part of this group? If so, I'll ask our local compression folks for some detailed information (and try to get them to write something up). If not, I guess the rest of this can be ignored ;) 2. Should compression be a seperate function (i.e. ESP, AH, Compression) or should it be optionally applied to the individual transforms as part of ESP (and AH?)? 3. Are compression algorithm patent issues still a problem and are they enough of a problem to prevent IETF standardization? Rob G. rob.glenn@nist.gov Received: from relay.tis.com by neptune.TIS.COM id aa04620; 20 May 96 12:38 EDT Received: by relay.tis.com; id MAA20412; Mon, 20 May 1996 12:39:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020382; Mon, 20 May 96 12:39:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00662; Mon, 20 May 96 12:39:40 EDT Received: by relay.tis.com; id MAA20368; Mon, 20 May 1996 12:39:27 -0400 Received: from theory.lcs.mit.edu(18.52.0.92) by relay.tis.com via smap (V3.1) id xma020360; Mon, 20 May 96 12:39:14 -0400 Received: from swift.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA04812; Mon, 20 May 96 12:41:48 EDT From: Be Hubbard Received: by swift.lcs.mit.edu (5.65c/TOC-1.2C) id AA10005; Mon, 20 May 96 12:36:36 EDT Date: Mon, 20 May 96 12:36:36 EDT Message-Id: <199605201636.AA10005@swift.lcs.mit.edu> To: ipsec@TIS.COM Subject: Trying to print out a copy of oakley-01.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk Dear Internet-Drafts people, I am trying to print this out for Prof. Ron Rivest here at the Lab for CS at MIT. I tried to locate ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-01.txt and Netscape said it ``is unable to find the file: internet-drafts/draft-ietf-ipsec-oakley-01.txt'' to check the file name and try again. Can you help? Best regards, Be Hubbard 617 253-6098 Received: from relay.tis.com by neptune.TIS.COM id aa05279; 20 May 96 13:18 EDT Received: by relay.tis.com; id NAA21387; Mon, 20 May 1996 13:19:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021382; Mon, 20 May 96 13:19:49 -0400 Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64) id AA02560; Mon, 20 May 96 13:20:00 EDT Resent-Message-Id: <9605201720.AA02560@tis.com> Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01617; Mon, 20 May 96 13:00:40 EDT Received: by relay.tis.com; id NAA20977; Mon, 20 May 1996 13:00:27 -0400 Received: from neptune.tis.com(192.94.214.96) by relay.tis.com via smap (V3.1) id xma020970; Mon, 20 May 96 12:59:58 -0400 Received: from inet-smtp-gw-1.us.oracle.com by neptune.TIS.COM id aa04983; 20 May 96 12:58 EDT Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id KAA02587; Mon, 20 May 1996 10:02:27 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA20157; Mon, 20 May 1996 10:02:19 -0700 Message-Id: <9605201702.AA20157@maildig1.us.oracle.com> Date: Mon, 20 May 1996 10:02:19 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec-approval@neptune.tis.com Subject: Re: Yes, you can export SHA and MD5 X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 18-May-96 01:10 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-20037326-0-0 Resent-To: ipsec@neptune.tis.com Resent-Date: Mon, 20 May 1996 13:22:09 -0400 Resent-From: Mark S Feldman Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-20037326-0-0 >You should see your favorite >high-priced export control lawyer for an >official legal opinion. No, just call the NSA ... lawyers opinions don't count. All cryptography is export controlled (from the US). Cryptographic functionality used in a product that provides only integrity and authentication services is usually "easy" to export. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-20037326-0-0 Content-Type: message/rfc822 Date: 18 May 96 01:10:03 From:"Theodore Y. Ts'o" To: PALAMBER@us.oracle.com Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: PALAMBER.US.ORACLE.COM's message of 17 May 96 15:19:05 -0700, X-Orcl-Application: In-Reply-To: <199605180449.VAA05812@mailsun2.us.oracle.com> X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139 X-Orcl-Application: Phone: (617) 253-8091 X-Orcl-Application: Content-Length: 1150 X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk Date: 17 May 96 15:19:05 -0700 From: "PALAMBER.US.ORACLE.COM" SHA and MD5 are both export controled, both are "easy" to export. Export should not be a consideration in the comparison of SHA to MD5. Well, to be precise, the NSA has made the claim that SHA and MD5 are export controlled, and the NIST's FIPS documenting SHA claims that SHA is export controlled. There seems to be at least some controversy as to what their statutory and regulatory authorities they are using to make either a statement, at least where SHA and MD5 is being used in a system which does not use any encryption methods or which attempts to engage in data hiding. As far as I know, no one on the IPSEC list is a lawyer, and is actively giving legal advise (myself included). You should see your favorite high-priced export control lawyer for an official legal opinion. My own personal belief is that any algorithm suite which is using as a weak an encryption as single DES might as well use HMAC-MD5. If we were going to use triple-DES for encryption it would perhaps make sense to use HMAC-SHA, or some such. - Ted --Boundary-20037326-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa05343; 20 May 96 13:21 EDT Received: by relay.tis.com; id NAA21480; Mon, 20 May 1996 13:22:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021470; Mon, 20 May 96 13:22:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02685; Mon, 20 May 96 13:22:40 EDT Received: by relay.tis.com; id NAA21461; Mon, 20 May 1996 13:22:27 -0400 Received: from theory.lcs.mit.edu(18.52.0.92) by relay.tis.com via smap (V3.1) id xma021454; Mon, 20 May 96 13:22:17 -0400 Received: from swift.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA05785; Mon, 20 May 96 13:24:46 EDT From: Be Hubbard Received: by swift.lcs.mit.edu (5.65c/TOC-1.2C) id AA10094; Mon, 20 May 96 13:19:34 EDT Date: Mon, 20 May 96 13:19:34 EDT Message-Id: <199605201719.AA10094@swift.lcs.mit.edu> To: ipsec@TIS.COM Subject: sorry to bother you.. I'm all set Sender: ipsec-approval@neptune.tis.com Precedence: bulk \\ || // \ . . / ___.oo0_(__()__)__0oo.___ Subject: Trying to print out a copy of oakley-01.txt Dear Internet-Drafts people, My netscape2 was sick sick sick. All is well and printing now. Best regards, Be Hubbard for RL Rivest ---------- __o __o __o __o -------- _`\<,_ _`\<,_ _`\<,_ _`\<,_ ------- (*)/ (*) (*)/ (*) (*)/ (*) (*)/ (*) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Received: from relay.tis.com by neptune.TIS.COM id aa05342; 20 May 96 13:21 EDT Received: by relay.tis.com; id NAA21481; Mon, 20 May 1996 13:22:57 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021471; Mon, 20 May 96 13:22:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02686; Mon, 20 May 96 13:22:40 EDT Received: by relay.tis.com; id NAA21462; Mon, 20 May 1996 13:22:28 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma021455; Mon, 20 May 96 13:22:23 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id KAA11989; Mon, 20 May 1996 10:24:27 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id KAA18637; Mon, 20 May 1996 10:27:30 -0700 (PDT) Message-Id: <199605201727.KAA18637@mailsun2.us.oracle.com> Date: 20 May 96 10:03:36 -0700 From: "PALAMBER.US.ORACLE.COM" To: tytso@mit.edu Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:tytso@MIT.EDU's message of 18-May-96 01:10 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-4941951-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-4941951-0-0 >You should see your favorite >high-priced export control lawyer for an >official legal opinion. No, just call the NSA ... lawyers opinions don't count. All cryptography is export controlled (from the US). Cryptographic functionality used in a product that provides only integrity and authentication services is usually "easy" to export. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-4941951-0-0 Content-Type: message/rfc822 Date: 18 May 96 01:10:03 From:"Theodore Y. Ts'o" To: PALAMBER@us.oracle.com Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: PALAMBER.US.ORACLE.COM's message of 17 May 96 15:19:05 -0700, X-Orcl-Application: In-Reply-To: <199605180449.VAA05812@mailsun2.us.oracle.com> X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139 X-Orcl-Application: Phone: (617) 253-8091 X-Orcl-Application: Content-Length: 1150 Date: 17 May 96 15:19:05 -0700 From: "PALAMBER.US.ORACLE.COM" SHA and MD5 are both export controled, both are "easy" to export. Export should not be a consideration in the comparison of SHA to MD5. Well, to be precise, the NSA has made the claim that SHA and MD5 are export controlled, and the NIST's FIPS documenting SHA claims that SHA is export controlled. There seems to be at least some controversy as to what their statutory and regulatory authorities they are using to make either a statement, at least where SHA and MD5 is being used in a system which does not use any encryption methods or which attempts to engage in data hiding. As far as I know, no one on the IPSEC list is a lawyer, and is actively giving legal advise (myself included). You should see your favorite high-priced export control lawyer for an official legal opinion. My own personal belief is that any algorithm suite which is using as a weak an encryption as single DES might as well use HMAC-MD5. If we were going to use triple-DES for encryption it would perhaps make sense to use HMAC-SHA, or some such. - Ted --Boundary-4941951-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa05708; 20 May 96 13:36 EDT Received: by relay.tis.com; id NAA21965; Mon, 20 May 1996 13:38:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021956; Mon, 20 May 96 13:37:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03493; Mon, 20 May 96 13:38:10 EDT Received: by relay.tis.com; id NAA21951; Mon, 20 May 1996 13:37:57 -0400 Received: from south-station-annex.mit.edu(18.72.1.2) by relay.tis.com via smap (V3.1) id xma021946; Mon, 20 May 96 13:37:42 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA12261; Mon, 20 May 96 13:38:51 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA27194; Mon, 20 May 1996 13:40:14 -0400 Date: Mon, 20 May 1996 13:40:14 -0400 Message-Id: <9605201740.AA27194@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@TIS.COM In-Reply-To: PALAMBER.US.ORACLE.COM's message of 20 May 96 10:03:36 -0700, <199605201727.KAA18637@mailsun2.us.oracle.com> Subject: Re: Yes, you can export SHA and MD5 Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 360 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: 20 May 96 10:03:36 -0700 From: "PALAMBER.US.ORACLE.COM" >You should see your favorite >high-priced export control lawyer for an >official legal opinion. No, just call the NSA ... lawyers opinions don't count. Paul, I can't tell from your e-mail message whether you're joking or not.... ! - Ted Received: from relay.tis.com by neptune.TIS.COM id aa05742; 20 May 96 13:37 EDT Received: by relay.tis.com; id MAA20452; Mon, 20 May 1996 12:41:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020448; Mon, 20 May 96 12:40:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00716; Mon, 20 May 96 12:41:09 EDT Received: by relay.tis.com; id MAA20445; Mon, 20 May 1996 12:40:57 -0400 Received: from pilot.is.chrysler.com(204.189.94.147) by relay.tis.com via smap (V3.1) id xma020424; Mon, 20 May 96 12:40:25 -0400 Received: by pilot.firewall.is.chrysler.com; id MAA13829; Mon, 20 May 1996 12:38:26 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma013822; Mon, 20 May 96 12:38:14 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id MAA14396; Mon, 20 May 1996 12:41:06 -0400 (EDT) Message-Id: <2.2.32.19960520163508.008e9434@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 May 1996 12:35:08 -0400 To: Robert Glenn , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Whatever happend to compression? Cc: rob.glenn@nist.gov Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 10:26 AM 5/20/96 -0400, Robert Glenn wrote: > >The idea of having a transform that performs compression before >encryption has come up several times in the past, but I don't believe >it has been discussed recently. Notably, compression has not been >added to any of the existing transform documents. Along these lines, I >have a few questions. > >1. Is compression still of interest as part of this group? If so, > I'll ask our local compression folks for some detailed information > (and try to get them to write something up). If not, I guess > the rest of this can be ignored ;) Compression must be a real issue to anyone on this list that will be running product over slow WAN links, like POTS. I think that is most here. My dialup experience says its a must implement, the only question is how. See below. >2. Should compression be a seperate function (i.e. ESP, AH, > Compression) or should it be optionally applied to the individual > transforms as part of ESP (and AH?)? It seems that there were opinions that said this would be a negotiated option. That all of the key negotiation proposals had ways of including the compression negotiation and that a separate transform was not needed. >3. Are compression algorithm patent issues still a problem and are > they enough of a problem to prevent IETF standardization? The PPPEXT group finally went with a variance. Discuss this with them and the IESG for details. It was painful, that much I remember. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa08396; 20 May 96 15:26 EDT Received: by relay.tis.com; id PAA25337; Mon, 20 May 1996 15:27:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025327; Mon, 20 May 96 15:27:04 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09516; Mon, 20 May 96 15:27:15 EDT Received: by relay.tis.com; id PAA25323; Mon, 20 May 1996 15:27:03 -0400 Received: from unknown(204.189.94.148) by relay.tis.com via smap (V3.1) id xma025317; Mon, 20 May 96 15:26:37 -0400 Received: by pilotx.firewall.is.chrysler.com; id PAA12914; Mon, 20 May 1996 15:29:09 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma012906; Mon, 20 May 96 15:29:03 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id PAA17681; Mon, 20 May 1996 15:31:56 -0400 (EDT) Message-Id: <2.2.32.19960520192557.00c5f3ec@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 May 1996 15:25:57 -0400 To: "Theodore Y. Ts'o" , "PALAMBER.US.ORACLE.COM" From: Robert Moskowitz Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 01:40 PM 5/20/96 -0400, Theodore Y. Ts'o wrote: > From: "PALAMBER.US.ORACLE.COM" > > No, just call the NSA ... lawyers opinions don't count. > >I can't tell from your e-mail message whether you're joking or not.... ! Unfortunately he is not. I have had to be in some policy meetings in DC on ITAR stuff, and this is the theme I have heard. Different rulings for different companies that are not following any pattern that security savy lawyers can use to guide companies along. This alone is reason enough to scrap the whole system. And a call to NSA is insufficient. You need it in writing. Good luck on getting that! Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa08757; 20 May 96 15:44 EDT Received: by relay.tis.com; id PAA25830; Mon, 20 May 1996 15:46:03 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025800; Mon, 20 May 96 15:45:35 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10460; Mon, 20 May 96 15:45:46 EDT Received: by relay.tis.com; id PAA25789; Mon, 20 May 1996 15:45:33 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma025760; Mon, 20 May 96 15:45:14 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id MAA15799; Mon, 20 May 1996 12:47:44 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id MAA07483; Mon, 20 May 1996 12:50:46 -0700 (PDT) Message-Id: <199605201950.MAA07483@mailsun2.us.oracle.com> Date: 20 May 96 12:34:37 -0700 From: "PALAMBER.US.ORACLE.COM" To: tytso@mit.edu Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:tytso@MIT.EDU's message of 20-May-96 13:40 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-4946428-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-4946428-0-0 >Sent: MAY 20, 1996 13:40 >From: Theodore Y. Ts'o >> Date: 20 May 96 10:03:36 -0700 >> From: "PALAMBER.US.ORACLE.COM" >> >You should see your favorite >> >high-priced export control lawyer for an >> >official legal opinion. >> >> No, just call the NSA ... lawyers opinions don't count. >> >Paul, > >I can't tell from your e-mail message whether you're joking or not.... ! Ted, No, I am not joking. I also spoke with the NSA on this topic ... SHA and MD5 when used as hash algorithms have the same export considerations. This is not a promise or direct ruling on SHA that our standards group can easily quote, but it is an indicator of the current review process. Standards are not subject to export control, so we are all subject to review of the final embodyment of these technologies into a product. Paul --Boundary-4946428-0-0 Content-Type: message/rfc822 Date: 20 May 96 13:40:14 From:"Theodore Y. Ts'o" To: PALAMBER@us.oracle.com Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: PALAMBER.US.ORACLE.COM's message of 20 May 96 10:03:36 -0700, X-Orcl-Application: In-Reply-To: <199605201727.KAA18637@mailsun2.us.oracle.com> X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139 X-Orcl-Application: Phone: (617) 253-8091 X-Orcl-Application: Content-Length: 360 Date: 20 May 96 10:03:36 -0700 From: "PALAMBER.US.ORACLE.COM" >You should see your favorite >high-priced export control lawyer for an >official legal opinion. No, just call the NSA ... lawyers opinions don't count. Paul, I can't tell from your e-mail message whether you're joking or not.... ! - Ted --Boundary-4946428-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa09527; 20 May 96 16:32 EDT Received: by relay.tis.com; id QAA27662; Mon, 20 May 1996 16:34:03 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027654; Mon, 20 May 96 16:33:35 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12919; Mon, 20 May 96 16:33:45 EDT Received: by relay.tis.com; id QAA27651; Mon, 20 May 1996 16:33:33 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma027649; Mon, 20 May 96 16:33:07 -0400 Received: from st5.ncsl.nist.gov (st5.ncsl.nist.gov [129.6.55.35]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with SMTP id QAA26321 for ; Mon, 20 May 1996 16:35:59 -0400 (EDT) Date: Mon, 20 May 1996 16:35:59 -0400 (EDT) From: Shu-jen Chang To: ipsec@TIS.COM Subject: Export control of SHA Cc: mruhl@nist.gov, craig.hunt@nist.gov Message-Id: Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have checked with my colleague at the Security Division and the Bureau of Export Administration (BXA) regarding SHA code distribution. The answer is: SHA can be exported with some restrictions. NIST can not distribute SHA implementation via WWW at this time (see later note regarding FTP release). However, NIST has obtained a license from the Commerce Department which permits NIST to distribute SHA and DSS to the majority of the world with a few exceptions. People's Republic of China and the former Soviet Block can import SHA as long as it's intended for civil end-user applications rather than for military purpose. The following countries are prohibited from importing SHA: Cuba, Iran, Iraq, Libya, North Korea, Serbia, Syria, and Sudan. Please note that this list of embargo countries changes over time. Companies or individuals who plan to use the SHA implementation inside their product(s) need not obtain a separate export license for reexporting SHA as long as the same guideline on the original license is followed. For information or clarification on this issue, please call BXA at (202) 482-4811. To obtain the SHA implementation from NIST, please send email to Eduardo Chen at eduardo.chen@nist.gov. Eduardo can also be reached at (301) 975-3367. Other than requesting the SHA implementation, please refrain from making other requests such as technical consultations from Eduardo (He works for a different division). NIST FIPS publications can be downloaded from the URL: http://csrc.nist.gov/fips. NIST also has a plan to make SHA and DSS implementations available over a NIST export-controlled FTP site. The plan is being evaluated by the upper management and legal council. I'll keep you posted as soon as it is approved. Shu-jen Received: from relay.tis.com by neptune.TIS.COM id aa09650; 20 May 96 16:37 EDT Received: by relay.tis.com; id QAA27779; Mon, 20 May 1996 16:38:34 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027760; Mon, 20 May 96 16:38:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13090; Mon, 20 May 96 16:38:16 EDT Received: by relay.tis.com; id QAA27747; Mon, 20 May 1996 16:38:04 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma027734; Mon, 20 May 96 16:37:56 -0400 Received: (from chang@localhost) by snad.ncsl.nist.gov (8.7.5/8.7.3) id QAA26429 for ipsec@TIS.COM; Mon, 20 May 1996 16:40:49 -0400 (EDT) Date: Mon, 20 May 1996 16:40:49 -0400 (EDT) From: Shu-jen Chang Message-Id: <199605202040.QAA26429@snad.ncsl.nist.gov> To: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have checked with my colleague at the Security Division and the Bureau of Export Administration (BXA) regarding SHA code distribution. The answer is: SHA can be exported with some restrictions. NIST can not distribute SHA implementation via WWW at this time (see later note regarding FTP release). However, NIST has obtained a license from the Commerce Department which permits NIST to distribute SHA and DSS to the majority of the world with a few exceptions. People's Republic of China and the former Soviet Block can import SHA as long as it's intended for civil end-user applications rather than for military purpose. The following countries are prohibited from importing SHA: Cuba, Iran, Iraq, Libya, North Korea, Serbia, Syria, and Sudan. Please note that this list of embargo countries changes over time. Companies or individuals who plan to use the SHA implementation inside their product(s) need not obtain a separate export license for reexporting SHA as long as the same guideline on the original license is followed. For information or clarification on this issue, please call BXA at (202) 482-4811. To obtain the SHA implementation from NIST, please send email to Eduardo Chen at eduardo.chen@nist.gov. Eduardo can also be reached at (301) 975-3367. Other than requesting the SHA implementation, please refrain from making other requests such as technical consultations from Eduardo (He works for a different division). NIST FIPS publications can be downloaded from the URL: http://csrc.nist.gov/fips. NIST also has a plan to make SHA and DSS implementations available over a NIST export-controlled FTP site. The plan is being evaluated by the upper management and legal council. I'll keep you posted as soon as it is approved. Shu-jen Received: from relay.tis.com by neptune.TIS.COM id aa15077; 20 May 96 23:01 EDT Received: by relay.tis.com; id XAA00775; Mon, 20 May 1996 23:03:04 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000773; Mon, 20 May 96 23:02:35 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21068; Mon, 20 May 96 23:02:46 EDT Received: by relay.tis.com; id XAA00770; Mon, 20 May 1996 23:02:34 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma000768; Mon, 20 May 96 23:02:30 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id UAA07144; Mon, 20 May 1996 20:05:05 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id UAA24746; Mon, 20 May 1996 20:08:08 -0700 (PDT) Message-Id: <199605210308.UAA24746@mailsun2.us.oracle.com> Date: 20 May 96 19:58:15 -0700 From: "PALAMBER.US.ORACLE.COM" To: tytso@mit.edu Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:tytso@MIT.EDU's message of 20-May-96 15:59 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-4955695-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-4955695-0-0 >I thought everyone was at least *pretending* >that the NSA was staying within the scope of their charter. But they are ... they are not exerting any "statutory or regulatory authority" ... they review the technical capabilities of a product. I do not agree with the policies and find that the process hurts my business, but the NSA is following a fairly clear set of guidelines. >Different rulings for different companies that >are not following any pattern that security savy >lawyers can use to guide companies along. I have not seen that much variation ... perhaps a gradual loosening, but no wild variations. The variations most likely come from the range in ablility of vendors to document the products that they build. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-4955695-0-0 Content-Type: message/rfc822 Date: 20 May 96 15:59:41 From:"Theodore Y. Ts'o" To: Robert,Moskowitz,rgm3@chrysler.com Subject: Re: Yes, you can export SHA and MD5 Cc: LAMBER@us.oracle.com X-Orcl-Application: In-Reply-To: Robert Moskowitz's message of Mon, 20 May 1996 15:25:57 -0400, X-Orcl-Application: In-Reply-To: <2.2.32.19960520192557.00c5f3ec@pop3hub.is.chrysler.com> X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139 X-Orcl-Application: Phone: (617) 253-8091 X-Orcl-Application: Content-Length: 1445 Date: Mon, 20 May 1996 15:25:57 -0400 From: Robert Moskowitz (Note: ipsec has been removed from the cc list.) At 01:40 PM 5/20/96 -0400, Theodore Y. Ts'o wrote: > From: "PALAMBER.US.ORACLE.COM" > > No, just call the NSA ... lawyers opinions don't count. > >I can't tell from your e-mail message whether you're joking or not.... ! Unfortunately he is not. I have had to be in some policy meetings in DC on ITAR stuff, and this is the theme I have heard. Different rulings for different companies that are not following any pattern that security savy lawyers can use to guide companies along. I didn't think the NSA as an agency had the statutory or regulatory authority to make decisions regarding export control. It's one thing if the State Department and the Commerce Department were under the thrall of the NSA and always blindly followed the NSA's lead --- but that's still a far cry from saying that companies should call the NSA because its the agency running the whole show. (This was why I wasn't sure whether Paul was joking!) I thought everyone was at least *pretending* that the NSA was staying within the scope of their charter. :-) This alone is reason enough to scrap the whole system. What you've described is called "secret law" (if you can prove it) and last I checked, it wasn't legal within the United States.... - Ted --Boundary-4955695-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa20848; 21 May 96 6:50 EDT Received: by relay.tis.com; id GAA02821; Tue, 21 May 1996 06:52:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002819; Tue, 21 May 96 06:51:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28451; Tue, 21 May 96 06:51:52 EDT Received: by relay.tis.com; id GAA02816; Tue, 21 May 1996 06:51:40 -0400 Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1) id xma002814; Tue, 21 May 96 06:51:15 -0400 Received: by pilotx.firewall.is.chrysler.com; id GAA19523; Tue, 21 May 1996 06:53:50 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma019515; Tue, 21 May 96 06:53:28 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id GAA24650; Tue, 21 May 1996 06:56:20 -0400 (EDT) Message-Id: <2.2.32.19960521105009.00bfc138@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 06:50:09 -0400 To: "PALAMBER.US.ORACLE.COM" , tytso@mit.edu From: Robert Moskowitz Subject: Re: Yes, you can export SHA and MD5 Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 07:58 PM 5/20/96 -0700, PALAMBER.US.ORACLE.COM wrote: > >>Different rulings for different companies that >>are not following any pattern that security savy >>lawyers can use to guide companies along. > >I have not seen that much variation ... perhaps a gradual loosening, but no >wild variations. The variations most likely come from the range in ablility >of vendors to document the products that they build. The last sentence tells it all. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa25819; 21 May 96 11:51 EDT Received: by relay.tis.com; id LAA10356; Tue, 21 May 1996 11:53:11 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010352; Tue, 21 May 96 11:52:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10942; Tue, 21 May 96 11:52:53 EDT Received: by relay.tis.com; id LAA10349; Tue, 21 May 1996 11:52:41 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma010347; Tue, 21 May 96 11:52:40 -0400 Received: from st5.ncsl.nist.gov (st5.ncsl.nist.gov [129.6.55.35]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with SMTP id LAA04745; Tue, 21 May 1996 11:55:30 -0400 (EDT) Message-Id: <199605211555.LAA04745@snad.ncsl.nist.gov> X-Sender: chang@snad.ncsl.nist.gov X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 10:43:19 -0400 To: "Theodore Y. Ts'o" From: Shu-jen Chang Subject: Re: Export control of SHA Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Companies or individuals who plan to use the SHA implementation > inside their product(s) need not obtain a separate export license > for reexporting SHA as long as the same guideline on the original > license is followed. For information or clarification on this > issue, please call BXA at (202) 482-4811. > >Shu-jen, > If the text of the original export license which NIST has >obtained for the export of SHA could be obtained in electronic form, >could you please post a pointer to it? I suspect it would be of great >interest to many implementors on this list. > Unfortunately the export license NIST obtained from the Commerse Department is not available in electronic form nor self-explanatory. The license contains: 1. Export Control Classification Number: 5D13A (this is the reference number for making inquiries). In fact, 5 - indicates the "Telecommunications and Cryptography" category. D - software 01 - 19: Coordinating Committee Controls (others are: 20-39: Missile Technology Controls 40-59: Nuclear Non-Proliferation Controls 60-79: Chemical and Biological Weapons Controls 80-99: Other Controls) A - a data processing code to indicate the country group for which a Validated License is required 2. General license eligibility: GTDR, GLX GTDR(General License Technical Data Restricted) is the code for the free world countries. GLX is the code for countries where SHA can only be imported for non-military usage. 3. Validated License Required for Country Groups: All The license also contains the following footnotes: Commodities eligible for export under General License and used in the design, development, production or use of Nuclear, Chemical or Biological weapons or ballistic missiles require a Validated export license. The countries included in each Country Group are listed on the reverse side of this form (Not copied for this email message). For shipments of the above commodities to any of the destinations indicated in the validated license required column (meaning the item 3 above), the exporter must apply for and obtain a validated license document from the Office of Exporter Services, P.O. Box 273, Washington, D.C. 20044. When an export is made, it is necessary for the exporter to show on the Shipper's Export Declaration (Form 7525-V), either the validated license number or the applicable general license symbol (e.g., GLV, G-DEST, etc.). Form 7525-V is available from the Superintendent of Documents, U.S. Government Printing Office, Washinton, D. C. 20402, and from Export Administration District Offices (U.S. Dept of Commerce). They may also be obtained from certain commercial stationers. For Information concerning this classification (i.e. 5D13A) contact Gustaf A. Sundquist Phone: 202 482-1265 Above is the information contained in NIST's export license, granted on 8/17/1995. > I don't quite understand what you mean by "the same guidelines >on the original license". In the context of your message, that could be >interepreted as "anywhere except the embargoed countries, plus civilian >use only for China and former Soviet Bloc countries", or it could imply >there were other restrictions on the original license. > Your first interpretation was exactly what I meant to convey. I have called BXA to confirm this interpretation. For example, if country A exports SHA to country B under the general license GTDR, and country B later on wants to export SHA to country C, country B does not need a separate license as long as country A can export to country C under the original license. When Eduardo Chen sends out the SHA code upon request, he will attach a memo basically saying something similar to what I summarized in yesterday's message. I hope this long message is useful to most of you. > >P.S. I do think NIST should be commended in its proactive role in >obtaining an export license for SHA which could be used by other >companies or individuals who are contemplating using SHA in their >products. > Thank you, service is our name:-). Shu-jen Received: from relay.tis.com by neptune.TIS.COM id aa29254; 21 May 96 14:52 EDT Received: by relay.tis.com; id OAA16289; Tue, 21 May 1996 14:54:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016265; Tue, 21 May 96 14:53:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20033; Tue, 21 May 96 14:54:07 EDT Received: by relay.tis.com; id OAA16252; Tue, 21 May 1996 14:53:55 -0400 Received: from unknown(128.221.131.1) by relay.tis.com via smap (V3.1) id xma016222; Tue, 21 May 96 14:53:25 -0400 Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA22284; Tue, 21 May 1996 14:55:28 -0400 Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA06191; Tue, 21 May 1996 14:55:25 -0400 Message-Id: <9605211855.AA06191@wellspring.us.dg.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 14:55:28 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: Re: Whatever happend to compression? Sender: ipsec-approval@neptune.tis.com Precedence: bulk am I to take this as an indication that at least some people would do a compression transform "beside" an encryption transform? In other words, the "don't worry PPP will make you happy" answer is not considered sufficient? >X-Sender: t3125rm@pop3hub.is.chrysler.com >Date: Mon, 20 May 1996 12:35:08 -0400 >To: Robert Glenn , ipsec@TIS.COM >From: Robert Moskowitz >Subject: Re: Whatever happend to compression? >Cc: rob.glenn@nist.gov >Sender: ipsec-approval@neptune.tis.com > >At 10:26 AM 5/20/96 -0400, Robert Glenn wrote: >> >>The idea of having a transform that performs compression before >>encryption has come up several times in the past, but I don't believe >>it has been discussed recently. Notably, compression has not been >>added to any of the existing transform documents. Along these lines, I >>have a few questions. >> >>1. Is compression still of interest as part of this group? If so, >> I'll ask our local compression folks for some detailed information >> (and try to get them to write something up). If not, I guess >> the rest of this can be ignored ;) > >Compression must be a real issue to anyone on this list that will be running >product over slow WAN links, like POTS. I think that is most here. > >My dialup experience says its a must implement, the only question is how. >See below. > >>2. Should compression be a seperate function (i.e. ESP, AH, >> Compression) or should it be optionally applied to the individual >> transforms as part of ESP (and AH?)? > >It seems that there were opinions that said this would be a negotiated >option. That all of the key negotiation proposals had ways of including the >compression negotiation and that a separate transform was not needed. > >>3. Are compression algorithm patent issues still a problem and are >> they enough of a problem to prevent IETF standardization? > >The PPPEXT group finally went with a variance. Discuss this with them and >the IESG for details. It was painful, that much I remember. > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > > Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" Received: from relay.tis.com by neptune.TIS.COM id aa29457; 21 May 96 15:02 EDT Received: by relay.tis.com; id PAA16813; Tue, 21 May 1996 15:04:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016790; Tue, 21 May 96 15:03:56 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20611; Tue, 21 May 96 15:04:05 EDT Received: by relay.tis.com; id PAA16781; Tue, 21 May 1996 15:03:53 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma016756; Tue, 21 May 96 15:03:24 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA04885 for ipsec@tis.com; Tue, 21 May 1996 12:05:59 -0700 Message-Id: <199605211905.MAA04885@puli.cisco.com> From: Ran Atkinson Date: Tue, 21 May 1996 12:05:59 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Results of quick survey Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi, The quick survey indicated very clear consensus that HMAC SHA-1 should be the mandatory-to-implement approach for AH and that HMAC MD5 should be optional-to-implement for AH. I'll post the WG Last Call for the 2 HMAC AH transforms in a few minutes. It isn't clear to me whether this also means that folks prefer to have "DES-CBC + HMAC SHA-1 + Replay protection" instead of "DES-CBC + HMAC SHA-1 + Replay protection" in the mandatory-to-implement ESP transform. Could the active members of the WG with a strong view either way on the integrity part of the ESP transform please send a quick note _now_ to Paul Lambert and to me indicating your preference with regard to ESP ? If this new survey results in MD5 as OK for ESP, then we'll hold WG Last Call for the combined ESP transform edited by Jim Hughes right away. Otherwise, Jim will need to re-edit his draft according to the consensus and WG Last Call will necessarily be delayed on that edit cycle. Thanks, Ran rja@cisco.com -- Received: from relay.tis.com by neptune.TIS.COM id aa29599; 21 May 96 15:09 EDT Received: by relay.tis.com; id PAA17228; Tue, 21 May 1996 15:11:02 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017219; Tue, 21 May 96 15:10:35 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20935; Tue, 21 May 96 15:10:45 EDT Received: by relay.tis.com; id PAA17213; Tue, 21 May 1996 15:10:33 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma017208; Tue, 21 May 96 15:10:29 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA05237; Tue, 21 May 1996 12:13:04 -0700 Message-Id: <199605211913.MAA05237@puli.cisco.com> From: Ran Atkinson Date: Tue, 21 May 1996 12:13:04 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: WG Last Call: AH Transforms to Proposed Standard Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is the formal IPsec WG Last Call for the drafts below. Comments on this action should be sent by midnight (US Pacific Time) 27 May to the co-chairs, Paul Lambert and Randall Atkinson . Minor editorial comments should be sent directly to the document editors, with a copy to each of the co-chairs. draft-ietf-ipsec-ah-hmac-sha-00.txt to "Proposed Standard" as mandatory to implement for all IPv6 systems and mandatory to implement for IPv4 systems that implement AH. draft-ietf-ipsec-ah-hmac-md5-00.txt to "Proposed Standard" with elective status. draft-ietf-ipsec-hmac-md5-00.txt to "Proposed Standard" with elective status. Ran rja@cisco.com -- Received: from relay.tis.com by neptune.TIS.COM id aa00829; 21 May 96 16:09 EDT Received: by relay.tis.com; id QAA19357; Tue, 21 May 1996 16:10:45 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019341; Tue, 21 May 96 16:10:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23804; Tue, 21 May 96 16:10:27 EDT Received: by relay.tis.com; id QAA19338; Tue, 21 May 1996 16:10:15 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma019328; Tue, 21 May 96 16:09:49 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA211659528; Tue, 21 May 1996 13:12:09 -0700 Message-Id: <199605212012.AA211659528@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA061929637; Tue, 21 May 1996 16:13:57 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: Rodney Thayer Cc: ipsec@TIS.COM Subject: Re: Whatever happend to compression? In-Reply-To: rodney's message of Tue, 21 May 1996 14:55:28 -0400. <9605211855.AA06191@wellspring.us.dg.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 21 May 1996 16:12:07 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii In other words, the "don't worry PPP will make you happy" answer is not considered sufficient? Well, it won't make you happy (unless all you want is a feature-checkoff box..) Any encryption algorithm which generates output which is compressible should be considered highly suspect. You need to compress before you encrypt (and decompress after you decrypt). - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMaIjkFpj/0M1dMJ/AQGn2wP+JhUxC3VU/cuflIWNH1eFtdX9+QaYD6pO ZLjirmc7fbR3snvPzKqG3rZfWB+80vtTmIkTNm7HJdNbr5sUXGolAoNcvf4qLooR MyqsIbJ95cZnlUa+v1ueVfQA6al04ZGvqyhzOmXUre70+qRWmGPSXNTL7D1gIUbo ESwfBDkj+G4= =70/K -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa01946; 21 May 96 17:04 EDT Received: by relay.tis.com; id RAA21508; Tue, 21 May 1996 17:06:16 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021498; Tue, 21 May 96 17:05:51 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26096; Tue, 21 May 96 17:05:57 EDT Received: by relay.tis.com; id RAA21494; Tue, 21 May 1996 17:05:46 -0400 Received: from pilot.is.chrysler.com(204.189.94.147) by relay.tis.com via smap (V3.1) id xma021492; Tue, 21 May 96 17:05:22 -0400 Received: by pilot.firewall.is.chrysler.com; id RAA07816; Tue, 21 May 1996 17:07:58 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma007812; Tue, 21 May 96 17:07:41 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id RAA06884; Tue, 21 May 1996 17:10:33 -0400 (EDT) Message-Id: <2.2.32.19960521210413.00bae91c@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 17:04:13 -0400 To: Rodney Thayer , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Whatever happend to compression? Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 02:55 PM 5/21/96 -0400, Rodney Thayer wrote: >am I to take this as an indication that at least some people would do a >compression transform "beside" an encryption transform? In other words, the >"don't worry PPP will make you happy" answer is not considered sufficient? How can PPP 'make you happy' when the data is already encrypted? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa02907; 21 May 96 17:44 EDT Received: by relay.tis.com; id RAA22667; Tue, 21 May 1996 17:46:21 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022660; Tue, 21 May 96 17:45:53 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27380; Tue, 21 May 96 17:46:03 EDT Received: by relay.tis.com; id RAA22649; Tue, 21 May 1996 17:45:51 -0400 Received: from dg-webo.us.dg.com(128.221.131.1) by relay.tis.com via smap (V3.1) id xma022640; Tue, 21 May 96 17:45:26 -0400 Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA26298; Tue, 21 May 1996 17:47:49 -0400 Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA13438; Tue, 21 May 1996 17:47:49 -0400 Message-Id: <9605212147.AA13438@wellspring.us.dg.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 17:47:53 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: Re: Whatever happend to compression? Sender: ipsec-approval@neptune.tis.com Precedence: bulk sorry -- that's what I meant. I guess I was asking this... is this combination: original IP packet -> AH + ESP(Compression(original)) something that other people are thinking about. ESP being one payload scheme and Compression being another payload scheme. I believe the RFC's support the concept of multiple payload schemes, right? >To: Rodney Thayer >Cc: ipsec@TIS.COM >Subject: Re: Whatever happend to compression? >Date: Tue, 21 May 1996 16:12:07 -0400 >From: Bill Sommerfeld >Sender: ipsec-approval@neptune.tis.com > >-----BEGIN PGP SIGNED MESSAGE----- > >content-type: text/plain; charset=us-ascii > > In other words, the "don't worry PPP will make you happy" answer is > not considered sufficient? > >Well, it won't make you happy (unless all you want is a >feature-checkoff box..) > >Any encryption algorithm which generates output which is compressible >should be considered highly suspect. > >You need to compress before you encrypt (and decompress after you >decrypt). > > - Bill > > > > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.2 > >iQCVAwUBMaIjkFpj/0M1dMJ/AQGn2wP+JhUxC3VU/cuflIWNH1eFtdX9+QaYD6pO >ZLjirmc7fbR3snvPzKqG3rZfWB+80vtTmIkTNm7HJdNbr5sUXGolAoNcvf4qLooR >MyqsIbJ95cZnlUa+v1ueVfQA6al04ZGvqyhzOmXUre70+qRWmGPSXNTL7D1gIUbo >ESwfBDkj+G4= >=70/K >-----END PGP SIGNATURE----- > > Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" Received: from relay.tis.com by neptune.TIS.COM id aa14786; 22 May 96 7:31 EDT Received: by relay.tis.com; id HAA27929; Wed, 22 May 1996 07:32:29 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027927; Wed, 22 May 96 07:32:05 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09530; Wed, 22 May 96 07:32:10 EDT Received: by relay.tis.com; id HAA27920; Wed, 22 May 1996 07:31:59 -0400 Received: from unknown(152.116.1.69) by relay.tis.com via smap (V3.1) id xma027913; Wed, 22 May 96 07:31:33 -0400 Received: from hp730297.tcc.chrysler.com (hp730297.tcc.chrysler.com [152.116.1.30]) by sg543689.tcc.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA06159; Wed, 22 May 1996 07:33:52 -0400 Received: from clhubgw1-nf0.is.chrysler.com (clhubgw1-nf0.is.chrysler.com [129.9.212.167]) by hp730297.tcc.chrysler.com (8.6.9/8.6.9) with ESMTP id HAA05033; Wed, 22 May 1996 07:34:17 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id HAA13051; Wed, 22 May 1996 07:35:57 -0400 (EDT) Message-Id: <2.2.32.19960522112931.00afba00@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 May 1996 07:29:31 -0400 To: Rodney Thayer , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Whatever happend to compression? Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 05:47 PM 5/21/96 -0400, Rodney Thayer wrote: >sorry -- that's what I meant. I guess I was asking this... > >is this combination: > > original IP packet -> AH + ESP(Compression(original)) > >something that other people are thinking about. ESP being one payload >scheme and Compression being another payload scheme. I believe the RFC's >support the concept of multiple payload schemes, right? That is the best way IMHO. Compression is something that should be negotiated, just like ESP and AH. Afterall, there are many compression schemes, some preferable over others (read better patent terms), just like cryphers. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa22127; 22 May 96 13:52 EDT Received: by relay.tis.com; id NAA06756; Wed, 22 May 1996 13:54:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006725; Wed, 22 May 96 13:53:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26137; Wed, 22 May 96 13:53:51 EDT Received: by relay.tis.com; id NAA06722; Wed, 22 May 1996 13:53:40 -0400 Received: from bugs_bunny.columbia.sparta.com(157.185.80.205) by relay.tis.com via smap (V3.1) id xma006711; Wed, 22 May 96 13:53:10 -0400 Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95) id AA05889; Wed, 22 May 96 13:55:44 EDT Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1) id AA01250; Wed, 22 May 96 13:55:42 -0400 From: Howard Weiss Message-Id: <9605221755.AA01250@katahdin.columbia.sparta.com> Subject: Re: Results of quick survey To: ipsec@TIS.COM Date: Wed, 22 May 1996 13:55:38 -0400 (EDT) Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1847 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Regarding the issue of HMAC SHA-1 versus HMAC MD5 and the mandatory transform for ESP .... During the discussion of the combined ESP DES-CBC, HMAC + Replay Prevention transform at the LA IPSEC, there was a question on whether the ICV (HMAC Residual) should be encrypted or unencrypted by ESP. The desire for the ICV to be unencrypted is credited to Phil Karn in his desire to lessen the impact of flooding (aka "clogging") attacks where the receiver would be required to spend lots of time decrypting bogus packets that could be dealt with more efficiently, and discarded if bogus, by a less intensive MAC check. If I recall correctly, Phil announced at LA that as far as he was now concerned, this no longer was an issue becasue he could run DES as fast as MD5 and therefore unencrypting a packet was no big deal. An issue: is this also the case for DES vs SHA-1 and therefore we still don't care? What I don't remember was the group coming to any consensus regarding which way to go. The current version of the transform (draft-ietf-ipsec-esp-des-md5-01.txt) still has the ICV unencrypted. Given the recent turmoil over the cryptographic weakness of MD5, doesn't it make sense to limit the exposure of whichever MAC algorithm used to any future cryptographic attacks by encrypting the ICV? Regards, Howie Weiss ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| Received: from relay.tis.com by neptune.TIS.COM id aa23963; 22 May 96 15:35 EDT Received: by relay.tis.com; id PAA09597; Wed, 22 May 1996 15:36:30 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009578; Wed, 22 May 96 15:35:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01580; Wed, 22 May 96 15:36:07 EDT Received: by relay.tis.com; id PAA09575; Wed, 22 May 1996 15:35:56 -0400 Received: from baa01075.slip.digex.net(204.91.208.66) by relay.tis.com via smap (V3.1) id xma009563; Wed, 22 May 96 15:35:29 -0400 Received: (from karn@localhost) by baa01075.slip.digex.net (8.7.4/8.7.3) id OAA02324; Wed, 22 May 1996 14:48:18 -0400 (EDT) Date: Wed, 22 May 1996 14:48:18 -0400 (EDT) From: Phil Karn Jr Message-Id: <199605221848.OAA02324@baa01075.slip.digex.net> To: rodney@sabletech.com Cc: ipsec@TIS.COM In-Reply-To: <9605212147.AA13438@wellspring.us.dg.com> (message from Rodney Thayer on Tue, 21 May 1996 17:47:53 -0400) Subject: Re: Whatever happend to compression? Reply-To: karn@qualcomm.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Well, we could certainly add compression as an optional ESP transform, but it does seem to me that the widespread use of compression at the application layer may render this moot in the majority of cases. It's already standard practice to compress large files before ftping them over the net, and of course virtually every network image format has compression built-in. Compressing at the application layer does have the significant advantage of saving bandwidth all along the network path, not just in the part that's encrypted with ESP (assuming tunnel mode operation, which I expect to be IPSP's primary use in the near term). Phil Received: from relay.tis.com by neptune.TIS.COM id aa24290; 22 May 96 15:59 EDT Received: by relay.tis.com; id QAA10494; Wed, 22 May 1996 16:00:26 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010488; Wed, 22 May 96 16:00:01 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02886; Wed, 22 May 96 16:00:07 EDT Received: by relay.tis.com; id PAA10477; Wed, 22 May 1996 15:59:56 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1) id xma010468; Wed, 22 May 96 15:59:40 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id NAA29982; Wed, 22 May 1996 13:02:06 -0700 (PDT) Date: Wed, 22 May 1996 13:02:06 -0700 (PDT) From: Phil Karn Message-Id: <199605222002.NAA29982@servo.qualcomm.com> To: hsw@columbia.sparta.com Cc: ipsec@TIS.COM In-Reply-To: <9605221755.AA01250@katahdin.columbia.sparta.com> (message from Howard Weiss on Wed, 22 May 1996 13:55:38 -0400 (EDT)) Subject: Re: Results of quick survey Sender: ipsec-approval@neptune.tis.com Precedence: bulk One point about the relative ordering of authentication and encryption. Even though I can now do DES pretty fast, it's still true that if you wrap encryption outside authentication then you still have to perform both algorithms to determine that the packet is bogus. If you authenticate outside of encryption, then you only need execute the authentication algorithm before you toss the bogus packet. So unless your encryption algorithm is *free* (not just as cheap as the authentication) there is still a good reason to put authentication outside encryption. Phil Received: from relay.tis.com by neptune.TIS.COM id aa25809; 22 May 96 17:37 EDT Received: by relay.tis.com; id RAA12721; Wed, 22 May 1996 17:38:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012716; Wed, 22 May 96 17:38:29 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06724; Wed, 22 May 96 17:38:38 EDT Received: by relay.tis.com; id RAA12713; Wed, 22 May 1996 17:38:28 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma012698; Wed, 22 May 96 17:37:58 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id RAA09126; Wed, 22 May 1996 17:40:50 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA25348; Wed, 22 May 1996 17:40:32 -0400 From: Uri Blumenthal Message-Id: <9605222140.AA25348@hawpub.watson.ibm.com> Subject: Re: Results of quick survey To: Phil Karn Date: Wed, 22 May 1996 17:40:32 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <199605222002.NAA29982@servo.qualcomm.com> from "Phil Karn" at May 22, 96 01:02:06 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn says: > One point about the relative ordering of authentication and encryption. > Even though I can now do DES pretty fast, it's still true that if you > wrap encryption outside authentication then you still have to perform > both algorithms to determine that the packet is bogus. On the other hand, it is considered best to authenticate the "final result" date, which is the plaintext. For "proving" that this encrypted data was "kosher" strictly speaking, is NOT equivalent to "proving" that the decrypted data is what was sent (i.e. it may decrypt to different things under different keys and so on)... Do we care? [I understand your concern about performance.] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa26869; 22 May 96 18:55 EDT Received: by relay.tis.com; id SAA13740; Wed, 22 May 1996 18:57:28 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013731; Wed, 22 May 96 18:56:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08087; Wed, 22 May 96 18:57:09 EDT Received: by relay.tis.com; id SAA13725; Wed, 22 May 1996 18:56:58 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1) id xma013719; Wed, 22 May 96 18:56:29 -0400 Received: from research.att.com by ns; Wed May 22 18:57:14 EDT 1996 Received: from raptor.research.att.com by research; Wed May 22 18:56:03 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id SAA25035; Wed, 22 May 1996 18:56:03 -0400 (EDT) Message-Id: <199605222256.SAA25035@raptor.research.att.com> To: uri@watson.ibm.com Cc: Phil Karn , ipsec@TIS.COM Subject: Re: Results of quick survey Date: Wed, 22 May 1996 18:56:03 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn says: > One point about the relative ordering of authentication and encrypti on. > Even though I can now do DES pretty fast, it's still true that if yo u > wrap encryption outside authentication then you still have to perfor m > both algorithms to determine that the packet is bogus. On the other hand, it is considered best to authenticate the "final result" date, which is the plaintext. For "proving" that this encrypted data was "kosher" strictly speaking, is NOT equivalent to "proving" that the decrypted data is what was sent (i.e. it may decrypt to different things under different keys and so on)... Do we care? [I understand your concern about performance.] The problem with putting the authentication check on the inside is that the short-block guessing attack can be used. I'm not at all convinced, though, that denial-of-service is worth worrying about here. Or rather, it is a problem, and a serious one, but it would happen either way; it's very cheap for the attacker to generate the packets and expensive for you to detect them, whichever tack you take. Received: from relay.tis.com by neptune.TIS.COM id aa27595; 22 May 96 19:42 EDT Received: by relay.tis.com; id TAA14264; Wed, 22 May 1996 19:43:30 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014260; Wed, 22 May 96 19:43:02 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08784; Wed, 22 May 96 19:43:11 EDT Received: by relay.tis.com; id TAA14257; Wed, 22 May 1996 19:43:00 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma014255; Wed, 22 May 96 19:42:35 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA29406 for ipsec@tis.com; Wed, 22 May 1996 16:45:10 -0700 Date: Wed, 22 May 1996 16:45:10 -0700 From: Ran Atkinson Message-Id: <199605222345.QAA29406@puli.cisco.com> To: ipsec@TIS.COM Subject: ESP transform Sender: ipsec-approval@neptune.tis.com Precedence: bulk [speaking as an individual, not as co-chair] My personal preference would be to retain HMAC MD5 for use with the Combined ESP transform. There are no known problems with HMAC MD5 and there is ample freely distributable source code, some of which has pretty good performance. SHA-1 is generally believed to be slower than MD5 and performance ought not be completely ignored. I also prefer to put the HMAC MD5 residual underneath the encryption. While I understand Phil Karn's point, I prefer to have the additional protection on the authentication that is provided by having it beneath the encryption. I also thought Uri's point about the semantic of the authentication was a good one. What do other folks think about making this change ? [as co-chair] We need to reach closure on the Combined ESP transform very very soon. Folks with open issues or comments should PLEASE raise them NOW to the list (or if you prefer, directly with the Jim Hughes). Thanks, Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa27790; 22 May 96 19:55 EDT Received: by relay.tis.com; id TAA14422; Wed, 22 May 1996 19:57:00 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014415; Wed, 22 May 96 19:56:32 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08987; Wed, 22 May 96 19:56:41 EDT Received: by relay.tis.com; id TAA14412; Wed, 22 May 1996 19:56:30 -0400 Received: from unknown(128.84.154.10) by relay.tis.com via smap (V3.1) id xma014410; Wed, 22 May 96 19:56:04 -0400 Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.10/R1.4) with ESMTP id TAA14177; Wed, 22 May 1996 19:58:33 -0400 Received: from gilling.cs.cornell.edu (GILLING.CS.CORNELL.EDU [128.84.254.180]) by cloyd.cs.cornell.edu (8.6.10/M1.8) with ESMTP id TAA02031; Wed, 22 May 1996 19:58:31 -0400 From: Lewis McCarthy Received: (lew@localhost) by gilling.cs.cornell.edu (8.6.10/C1.3) id TAA07658; Wed, 22 May 1996 19:58:23 -0400 Date: Wed, 22 May 1996 19:58:23 -0400 Message-Id: <199605222358.TAA07658@gilling.cs.cornell.edu> To: uri@watson.ibm.com Subject: Re: Results of quick survey Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn writes: > So unless your encryption algorithm is *free* (not just as cheap > as the authentication) there is still a good reason to put > authentication outside encryption. Uri Blumenthal writes: # On the other hand, it is considered best to authenticate the # "final result" date, which is the plaintext. Does anyone think it might be worthwhile to authenticate _both_ inside and outside the encryption ? I.e. HMAC(DES-CBC(HMAC(data))) This might improve protection against clogging attacks as per Phil, while authenticating an unambiguous plaintext as suggested by Uri. Howie Weiss expressed concern earlier about exposing the HMAC result in case the underlying hash is (partially) cryptanalyzed. The outer HMAC, upon which the quick anti-clogging protection relies, would be equally vulnerable in this scheme. But the inner HMAC should be shielded in part against hash collision attacks, by the covering encryption. Two immediate problems with this approach are performance degradation for the sender, and (the big one) complication of the protocol and its analysis. The receiver could be allowed to choose to ignore the outer HMAC value, thus avoiding a performance hit by passing up the chance to detect bad packets early in the processing. Of course this adds complexity to receivers' policies. -Lewis McCarthy lew@cs.cornell.edu (until June 1) Received: from relay.tis.com by neptune.TIS.COM id aa06902; 23 May 96 8:41 EDT Received: by relay.tis.com; id IAA21758; Thu, 23 May 1996 08:43:00 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021752; Thu, 23 May 96 08:42:32 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21509; Thu, 23 May 96 08:42:41 EDT Received: by relay.tis.com; id IAA21743; Thu, 23 May 1996 08:42:30 -0400 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma021729; Thu, 23 May 96 08:42:02 -0400 Received: by callandor.cybercash.com; id IAA15415; Thu, 23 May 1996 08:42:38 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1) id xma015413; Thu, 23 May 96 08:42:16 -0400 Received: from [204.254.34.75] (loial.cybercash.com) by cybercash.com (4.1/SMI-4.1) id AA22109; Thu, 23 May 96 08:39:29 EDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 May 1996 08:44:59 -0400 To: Lewis McCarthy From: Steve Crocker Subject: Re: Results of quick survey Cc: uri@watson.ibm.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 7:58 PM 5/22/96, Lewis McCarthy wrote: >Does anyone think it might be worthwhile to authenticate _both_ inside and >outside the encryption ? I.e. HMAC(DES-CBC(HMAC(data))) Yes, I wondering the same thing. And if one is going to authenticate both inside and outside, is there an opportunity to share some of the work. E.g.other than violating layering rather grossly, what else is wrong with computing the hash of the plain text, the hash of the ciphertext and then just one signature covering both hashes? Two hash computations are still required, and the receiver could still elect elect to ignore the outer hash, but the cost would be lower and the tendency to ignore this outer check would be lessened. Steve -------------------- Steve Crocker Main: +1 703 620 4200 CyberCash, Inc. Desk: +1 703 716 5214 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 22091 crocker@cybercash.com Received: from relay.tis.com by neptune.TIS.COM id aa07799; 23 May 96 9:42 EDT Received: by relay.tis.com; id JAA23129; Thu, 23 May 1996 09:44:04 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023118; Thu, 23 May 96 09:43:36 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24886; Thu, 23 May 96 09:43:45 EDT Received: by relay.tis.com; id JAA23110; Thu, 23 May 1996 09:43:34 -0400 Received: from drawbridge.ascend.com(198.4.92.1) by relay.tis.com via smap (V3.1) id xma023103; Thu, 23 May 96 09:43:22 -0400 Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id GAA20748 for ; Thu, 23 May 1996 06:45:49 -0700 Received: from Mail-gw.ascend.com (mail-gw.ascend.com [192.207.23.142]) by spud.ascend.com (8.6.12/8.6.12) with SMTP id GAA13941 for <@spud.ascend.com:ipsec@tis.com>; Thu, 23 May 1996 06:45:44 -0700 Received: by Mail-gw.ascend.com (IBM OS/2 SENDMAIL VERSION 1.3.14/1.0) id AA0156; Thu, 23 May 96 06:44:39 -0700 Message-Id: <9605231344.AA0156@Mail-gw.ascend.com> Received: from Ascend with "Lotus Notes Mail Gateway for SMTP" id E47FD454AFDDA44488256333001D0BD0; Thu, 23 May 96 06:44:39 To: ipsec From: Matt Holdrege/Ascend/US Date: 22 May 96 22:29:02 Subject: Re: Whatever happend to compression? Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipsec-approval@neptune.tis.com Precedence: bulk A few thoughts. In general, compression is nice in that it randomizes the data first, then encryption further scrambles the bits making it harder for anyone to make sense of it. It's another roadblock to the bad guy. Compression should happen before encryption since compression works better on raw data than on encrypted data. Compression (as per the CCP draft RFC) can compress the PPP header information as well as the data which helps overall performance on WAN links. How about this? Once RFC's are set for IPSEC and CCP, another WG could be put together to define encryption and compression interaction in the PPP world. Eh? Or will a WG even be needed? Received: from relay.tis.com by neptune.TIS.COM id aa08389; 23 May 96 10:20 EDT Received: by relay.tis.com; id KAA24974; Thu, 23 May 1996 10:22:28 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024962; Thu, 23 May 96 10:21:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27215; Thu, 23 May 96 10:22:09 EDT Received: by relay.tis.com; id KAA24957; Thu, 23 May 1996 10:21:58 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma024931; Thu, 23 May 96 10:21:39 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id KAA24582; Thu, 23 May 1996 10:24:28 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA42814; Thu, 23 May 1996 10:24:09 -0400 From: Uri Blumenthal Message-Id: <9605231424.AA42814@hawpub.watson.ibm.com> Subject: Re: Results of quick survey To: Steve Crocker Date: Thu, 23 May 1996 10:24:09 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: from "Steve Crocker" at May 23, 96 08:44:59 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve Crocker says: > >Does anyone think it might be worthwhile to authenticate _both_ inside and > >outside the encryption ? I.e. HMAC(DES-CBC(HMAC(data))) > > Yes, I wondering the same thing. And if one is going to authenticate both > inside and outside, is there an opportunity to share some of the work. Probably it's a good idea, *if* the "outside" authentication is cheap "enough" [you tell me what "enough" means here :-]. I'd see it mostly as anti-clogging measure. > E.g.other than violating layering rather grossly, what else is wrong with > computing the hash of the plain text, the hash of the ciphertext and then > just one signature covering both hashes? Two hash computations are still > required, and the receiver could still elect elect to ignore the outer > hash, but the cost would be lower and the tendency to ignore this outer > check would be lessened. Yeah, but where would you put that "double hash"? Analysis [in my understanding] would be a true hellish nightmare. I don't really believe any work can be shared between the "outer" and "inner" auth... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa09119; 23 May 96 10:57 EDT Received: by relay.tis.com; id KAA26082; Thu, 23 May 1996 10:58:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026071; Thu, 23 May 96 10:58:31 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28703; Thu, 23 May 96 10:58:40 EDT Received: by relay.tis.com; id KAA26057; Thu, 23 May 1996 10:58:28 -0400 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1) id xma026039; Thu, 23 May 96 10:58:07 -0400 Received: by mercury.Sun.COM (Sun.COM) id IAA14405; Thu, 23 May 1996 08:00:38 -0700 Received: from bebop by France.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk200) id QAA14680; Thu, 23 May 1996 16:56:28 +0200 Received: from sdm.France.Sun.COM by bebop (SMI-8.6/SMI-SVR4-su.fkk202) id QAA29587; Thu, 23 May 1996 16:58:46 +0200 Received: by sdm.France.Sun.COM (SMI-8.6/SMI-SVR4) id QAA02622; Thu, 23 May 1996 16:56:24 +0200 Date: Thu, 23 May 1996 16:56:24 +0200 From: Martin Patterson - Sun Microsystems Message-Id: <199605231456.QAA02622@sdm.France.Sun.COM> To: ipsec@TIS.COM Subject: ppp compression X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk For info, here is the reference for the compression control protocol which has been mentioned recently. Our experience with IPSEC protocols over classic 28.8k dialup PPP links suggests that payload compression is a must. Martin >----------------Begin Forwarded Message----------------< Date: Thu, 23 May 96 09:26:37 -0400 From: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-stacker-07.txt To: IETF-Announce@ Cc: ietf-ppp@MERIT.EDU A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : PPP Stac LZS Compression Protocol Author(s) : R. Friend, W. Simpson Filename : draft-ietf-pppext-stacker-07.txt Pages : 14 Date : 05/22/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-stacker-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-stacker-07.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-stacker-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. >----------------End Forwarded Message----------------< ----- End Included Message ----- Received: from relay.tis.com by neptune.TIS.COM id aa09198; 23 May 96 11:00 EDT Received: by relay.tis.com; id LAA26210; Thu, 23 May 1996 11:01:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026200; Thu, 23 May 96 11:01:30 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28860; Thu, 23 May 96 11:01:39 EDT Received: by relay.tis.com; id LAA26195; Thu, 23 May 1996 11:01:28 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma026187; Thu, 23 May 96 11:01:02 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id LAA26527; Thu, 23 May 1996 11:03:19 -0400 (EDT) Message-Id: <199605231503.LAA26527@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Matt Holdrege/Ascend/US Cc: ipsec Subject: Re: Whatever happend to compression? In-Reply-To: Your message of "22 May 1996 22:29:02." <9605231344.AA0156@Mail-gw.ascend.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 23 May 1996 11:03:14 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Matt Holdrege/Ascend/US writes: > A few thoughts. > > In general, compression is nice in that it randomizes the data first, > then encryption further scrambles the bits making it harder for > anyone to make sense of it. It's another roadblock to the bad guy. Any compression scheme you can reverse doesn't randomize the data in any meaningful sense. The reason to want compression is to reduce bandwidth, not for security. > Compression should happen before encryption since compression > works better on raw data than on encrypted data. Compression should not work at all on encrypted data since encrypted data should be essentially random to anyone without the key. That implies incompressable. Perry Received: from relay.tis.com by neptune.TIS.COM id aa10783; 23 May 96 12:09 EDT Received: by relay.tis.com; id MAA28235; Thu, 23 May 1996 12:11:22 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028229; Thu, 23 May 96 12:10:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02220; Thu, 23 May 96 12:11:03 EDT Received: by relay.tis.com; id MAA28220; Thu, 23 May 1996 12:10:52 -0400 Received: from dworshak.cs.uidaho.edu(129.101.100.160) by relay.tis.com via smap (V3.1) id xma028213; Thu, 23 May 96 12:10:42 -0400 Received: from payette.cs.uidaho.edu (payette.cs.uidaho.edu [129.101.100.21]) by dworshak.cs.uidaho.edu (8.7.5/1.1) with ESMTP id JAA09667; Thu, 23 May 1996 09:13:13 -0700 (PDT) From: "J. Alves Foss 2nd account" Received: (jimaf2@localhost) by payette.cs.uidaho.edu (8.7.5/1.0) id JAA20576; Thu, 23 May 1996 09:13:13 -0700 (PDT) Message-Id: <199605231613.JAA20576@payette.cs.uidaho.edu> Subject: Re: Whatever happend to compression? To: perry@piermont.com Date: Thu, 23 May 1996 09:13:12 -0700 (PDT) Cc: Matt_Holdrege@ascend.com, ipsec@TIS.COM In-Reply-To: <199605231503.LAA26527@jekyll.piermont.com> from "Perry E. Metzger" at May 23, 96 11:03:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > > Matt Holdrege/Ascend/US writes: > > A few thoughts. > > > > In general, compression is nice in that it randomizes the data first, > > then encryption further scrambles the bits making it harder for > > anyone to make sense of it. It's another roadblock to the bad guy. > > Any compression scheme you can reverse doesn't randomize the data in > any meaningful sense. The reason to want compression is to reduce > bandwidth, not for security. > > > Compression should happen before encryption since compression > > works better on raw data than on encrypted data. > > Compression should not work at all on encrypted data since encrypted > data should be essentially random to anyone without the key. That > implies incompressable. > > Perry > Received: from relay.tis.com by neptune.TIS.COM id aa10924; 23 May 96 12:15 EDT Received: by relay.tis.com; id MAA28342; Thu, 23 May 1996 12:16:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028336; Thu, 23 May 96 12:16:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02366; Thu, 23 May 96 12:16:33 EDT Received: by relay.tis.com; id MAA28329; Thu, 23 May 1996 12:16:22 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1) id xma028325; Thu, 23 May 96 12:15:54 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA174718270; Thu, 23 May 1996 09:17:51 -0700 Message-Id: <199605231617.AA174718270@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA149918387; Thu, 23 May 1996 12:19:47 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: karn@qualcomm.com Cc: rodney@sabletech.com, ipsec@TIS.COM Subject: Re: Whatever happend to compression? In-Reply-To: karn's message of Wed, 22 May 1996 14:48:18 -0400. <199605221848.OAA02324@baa01075.slip.digex.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 23 May 1996 12:17:49 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii Well, we could certainly add compression as an optional ESP transform, but it does seem to me that the widespread use of compression at the application layer may render this moot in the majority of cases. There's no application-layer compression to speak of in: http pop smtp telnet All of these mostly transport text, which is eminently compressible. Compressing at the application layer does have the significant advantage of saving bandwidth all along the network path, not just in the part that's encrypted with ESP (assuming tunnel mode operation, which I expect to be IPSP's primary use in the near term). If the primary use of tunnel mode is for "road warriors" stringing up a tunnel to the home office, the "last hop" from the other tunnel endpoint to the application server will probably be over a LAN, which has effectively infinite bandwidth compared with 28.8k or even ISDN.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMaSPpVpj/0M1dMJ/AQE3vgP9HVrw0q77Gziay2liMvXQa376Q4lnAtvd 2ua1t791PFcEdmUcpeMe8aE/Uv8aYOxYU/iJi9NLlxMupl81XQJiZkOswfz31zQy J/493J6pdWUbgr4rFzKfcQtfbVf/oUMFPZ1dZOHc9xAaaikdEQp0gju0+HnYs9ld 5UGg+r+mR6g= =ezXw -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa11970; 23 May 96 13:00 EDT Received: by relay.tis.com; id NAA29243; Thu, 23 May 1996 13:01:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029226; Thu, 23 May 96 13:01:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03740; Thu, 23 May 96 13:01:33 EDT Received: by relay.tis.com; id NAA29221; Thu, 23 May 1996 13:01:22 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1) id xma029189; Thu, 23 May 96 13:00:56 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id KAA16575; Thu, 23 May 1996 10:02:08 -0700 (PDT) Date: Thu, 23 May 1996 10:02:08 -0700 (PDT) From: Phil Karn Message-Id: <199605231702.KAA16575@servo.qualcomm.com> To: sommerfeld@apollo.hp.com Cc: rodney@sabletech.com, ipsec@TIS.COM In-Reply-To: <199605231617.AA174718270@relay.hp.com> (message from Bill Sommerfeld on Thu, 23 May 1996 12:17:49 -0400) Subject: Re: Whatever happend to compression? Sender: ipsec-approval@neptune.tis.com Precedence: bulk >There's no application-layer compression to speak of in: http True, though most HTML documents transferred with HTTP aren't particularly large. GIF and JPEGs transferred with HTTP are already compressed. pop smtp I've been saying for some time that these ought to be replaced with a "mailbag" protocol which would make life for road warriors much more pleasant. telnet This is hard to compress since the packets are already so small to begin with, and the traffic is fairly low speed anyway. I'm not disputing the usefulness of compression below the application layer, but I do think that the payback may not be as great as you might think. Phil Received: from relay.tis.com by neptune.TIS.COM id aa13068; 23 May 96 13:50 EDT Received: by relay.tis.com; id NAA01809; Thu, 23 May 1996 13:51:43 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001801; Thu, 23 May 96 13:51:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05819; Thu, 23 May 96 13:51:29 EDT Received: by relay.tis.com; id NAA01787; Thu, 23 May 1996 13:51:16 -0400 Received: from unknown(194.100.8.234) by relay.tis.com via smap (V3.1) id xma001774; Thu, 23 May 96 13:51:05 -0400 Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1]) by muuri.ssh.fi (8.7.5/8.7.3) with ESMTP id UAA18286; Thu, 23 May 1996 20:53:27 +0300 (EET DST) Received: (from ylo@localhost) by pilari.ssh.fi (8.7.5/8.7.3) id UAA21385; Thu, 23 May 1996 20:53:26 +0300 (EET DST) Date: Thu, 23 May 1996 20:53:26 +0300 (EET DST) Message-Id: <199605231753.UAA21385@pilari.ssh.fi> From: Tatu Ylonen To: Phil Karn Cc: ipsec@TIS.COM Subject: Re: Whatever happend to compression? In-Reply-To: <199605231702.KAA16575@servo.qualcomm.com> References: <199605231617.AA174718270@relay.hp.com> <199605231702.KAA16575@servo.qualcomm.com> Organization: SSH Communications Security, Finland Sender: ipsec-approval@neptune.tis.com Precedence: bulk > telnet > > This is hard to compress since the packets are already so small to > begin with, and the traffic is fairly low speed anyway. My experience from SSH is that for terminal sessions, compression reduces the amount of data transmitted in the server->client direction to about a third. That is the direction in which most of the data flows. You update the entire screen very often. Tatu Received: from relay.tis.com by neptune.TIS.COM id aa13845; 23 May 96 14:29 EDT Received: by relay.tis.com; id OAA03081; Thu, 23 May 1996 14:30:43 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003077; Thu, 23 May 96 14:30:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07841; Thu, 23 May 96 14:30:23 EDT Received: by relay.tis.com; id OAA03071; Thu, 23 May 1996 14:30:13 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma003056; Thu, 23 May 96 14:29:42 -0400 Received: from sloth.ncsl.nist.gov (sloth.ncsl.nist.gov [129.6.55.36]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with ESMTP id NAA01822; Thu, 23 May 1996 13:42:01 -0400 (EDT) From: Robert Glenn Received: (from glenn@localhost) by sloth.ncsl.nist.gov (8.7.5/8.7.3) id NAA15086; Thu, 23 May 1996 13:41:26 -0400 (EDT) Date: Thu, 23 May 1996 13:41:26 -0400 (EDT) Message-Id: <199605231741.NAA15086@sloth.ncsl.nist.gov> To: perry@piermont.com Subject: Re: Whatever happend to compression? Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: "Perry E. Metzger" > Sender: ipsec-approval@neptune.tis.com > Content-Length: 711 > > > Matt Holdrege/Ascend/US writes: > > A few thoughts. > > > > In general, compression is nice in that it randomizes the data first, > > then encryption further scrambles the bits making it harder for > > anyone to make sense of it. It's another roadblock to the bad guy. > >Any compression scheme you can reverse doesn't randomize the data in >any meaningful sense. The reason to want compression is to reduce >bandwidth, not for security. Actually, I have a paper here in front of me, "Contemporary Cryptology: An Introduction" by James Massey that talks about compression and security. The section that talks about this explains how redundancy in the data can be used to help break "an imperfect cipher". Since compression removes redundance the article suggests "...that data compression is a useful cryptographic tool." It goes on to imply that the practice of removing redundancy from data before encrypting has been going on for quite some time. I don't know if this has any relevance to current crypto algorithms such as DES. I just thought it was interesting that in some instances compression is/was used to improve security. Rob G. rob.glenn@nist.gov Received: from relay.tis.com by neptune.TIS.COM id aa13906; 23 May 96 14:32 EDT Received: by relay.tis.com; id OAA03177; Thu, 23 May 1996 14:33:43 -0400 From: wobber@pa.dec.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003163; Thu, 23 May 96 14:33:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07985; Thu, 23 May 96 14:33:23 EDT Received: by relay.tis.com; id OAA03160; Thu, 23 May 1996 14:33:12 -0400 Received: from mail1.digital.com(204.123.2.50) by relay.tis.com via smap (V3.1) id xma003140; Thu, 23 May 96 14:32:52 -0400 Received: from hickory.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA21843; Thu, 23 May 1996 11:25:25 -0700 Received: by hickory.pa.dec.com; id AA08189; Thu, 23 May 1996 11:25:23 -0700 Message-Id: <9605231825.AA08189@hickory.pa.dec.com> To: Bill Sommerfeld Cc: karn@qualcomm.com, rodney@sabletech.com, ipsec@TIS.COM Subject: Re: Whatever happend to compression? In-Reply-To: Message of Thu, 23 May 1996 12:17:49 -0400 from Bill Sommerfeld <199605231617.AA174718270@relay.hp.com> Date: Thu, 23 May 96 11:25:22 -0700 X-Mts: smtp Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> If the primary use of tunnel mode is for "road warriors" stringing up >> a tunnel to the home office, the "last hop" from the other tunnel >> endpoint to the application server will probably be over a LAN, which >> has effectively infinite bandwidth compared with 28.8k or even ISDN.. Agreed. Furthermore, the use of tunneled-mode encryption eliminates any benefit from network or link level compression (e.g. modem-based) since encrypted bytes aren't readily compressible. It takes payload compression prior to encryption to draw back even with non-encrypted performance over slow lines. Ted Wobber DEC Systems Research Center Received: from relay.tis.com by neptune.TIS.COM id aa14791; 23 May 96 15:11 EDT Received: by relay.tis.com; id PAA04818; Thu, 23 May 1996 15:12:43 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004805; Thu, 23 May 96 15:12:20 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09635; Thu, 23 May 96 15:12:28 EDT Received: by relay.tis.com; id PAA04793; Thu, 23 May 1996 15:12:13 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma004768; Thu, 23 May 96 15:11:54 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id PAA26869; Thu, 23 May 1996 15:13:08 -0400 (EDT) Message-Id: <199605231913.PAA26869@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Glenn Cc: ipsec@TIS.COM Subject: Re: Whatever happend to compression? In-Reply-To: Your message of "Thu, 23 May 1996 13:41:26 EDT." <199605231741.NAA15086@sloth.ncsl.nist.gov> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 23 May 1996 15:12:59 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Robert Glenn writes: > Actually, I have a paper here in front of me, "Contemporary > Cryptology: An Introduction" by James Massey that talks about > compression and security. The section that talks about this explains > how redundancy in the data can be used to help break "an imperfect > cipher". Since compression removes redundance the article suggests > "...that data compression is a useful cryptographic tool." It goes on > to imply that the practice of removing redundancy from data before > encrypting has been going on for quite some time. The problem is the way that many modern compression algorithms work, they leave lots of nearly known plaintext in the data stream. I don't know that this can be well exploited, but I suspect it can. Perry Received: from relay.tis.com by neptune.TIS.COM id aa15097; 23 May 96 15:28 EDT Received: by relay.tis.com; id PAA05611; Thu, 23 May 1996 15:30:13 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma005593; Thu, 23 May 96 15:29:49 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10348; Thu, 23 May 96 15:29:57 EDT Received: by relay.tis.com; id PAA05580; Thu, 23 May 1996 15:29:46 -0400 Received: from csmes.ncsl.nist.gov(129.6.54.2) by relay.tis.com via smap (V3.1) id xma005569; Thu, 23 May 96 15:29:40 -0400 Received: (konczal@localhost) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) id PAA27068; Thu, 23 May 1996 15:27:30 -0400 Date: Thu, 23 May 1996 15:27:30 -0400 Message-Id: <199605231927.PAA27068@csmes.ncsl.nist.gov> From: Joe Konczal To: perry@piermont.com Cc: Matt_Holdrege@ascend.com, ipsec@TIS.COM In-Reply-To: <199605231503.LAA26527@jekyll.piermont.com> (perry@piermont.com) Subject: Re: Whatever happend to compression? Sender: ipsec-approval@neptune.tis.com Precedence: bulk >>>>> "Perry" == Perry E Metzger writes: Perry> Matt Holdrege/Ascend/US writes: >> A few thoughts. >> >> In general, compression is nice in that it randomizes the data >> first, then encryption further scrambles the bits making it >> harder for anyone to make sense of it. It's another roadblock >> to the bad guy. Perry> Any compression scheme you can reverse doesn't randomize Perry> the data in any meaningful sense. The reason to want Perry> compression is to reduce bandwidth, not for security. Compression reduces the redundancy of the plaintext and increases the unicity distance of the cypher [1, p. 12]. This makes the cryptogram both smaller and stronger. [1] "Contemporary Cryptography: An Introduction" by James L. Massey (reprinted from "Contemporary Cryptography: the Science of Information Integrity" G.J. Simmons, editor. IEEE Press, 1991), in "Cryptography and Data Protection" J.H. van Lint and R. Tijdeman, editors, Konninklijke Nederlandse Akademie van Wetenshappen Verhandelingen, 1992. -- Joe Konczal National Institute of Standards and Technology Building 820, Room 410 Phone: (301) 975-3285 Gaithersburg, MD 20899 USA Fax: (301) 948-0279 Received: from relay.tis.com by neptune.TIS.COM id aa16273; 23 May 96 16:25 EDT Received: by relay.tis.com; id QAA07531; Thu, 23 May 1996 16:26:43 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007528; Thu, 23 May 96 16:26:15 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12887; Thu, 23 May 96 16:26:24 EDT Received: by relay.tis.com; id QAA07525; Thu, 23 May 1996 16:26:13 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma007522; Thu, 23 May 96 16:25:44 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id QAA17601; Thu, 23 May 1996 16:18:23 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.2.250.126]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id QAA61980; Thu, 23 May 1996 16:18:04 -0400 Message-Id: <199605232018.QAA61980@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3630; Thu, 23 May 96 16:17:59 EDT Date: Thu, 23 May 96 15:59:41 EDT To: rja@cisco.com, ipsec@TIS.COM Subject: WG Last Call: AH Transforms to Proposed Standard Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Tue, 21 May 1996 12:13:04 PDT I missed the "quick survey" (I was away from my email), anyway I want to repeat my opinion on this issue. Based on the message I sent to this list on May 8 I support using HMAC-MD5 for AH and ESP+AH. (I do this with my hat of "implementer" and the recognition of the need for best possible performance rather than with my more conservative hat of "pure cryptographer"). I recommend adding the following paragraph (or any correct English-variant of it) to the documents defining HMAC-MD5 as the default transform: The currently known cryptanalytic results on MD5 do not indicate a practical weakness of MD5 for its use with the HMAC construction. Due to this fact and the performance advantages of MD5 over other alternatives (e.g., SHA-1) this document defines MD5 as the basic hash function to be used with HMAC. However, implementers need to be aware that future cryptographic developments may call for the replacement of MD5 with other hash functions. In particular, implementers are strongly encouraged to provide support for SHA-1 with HMAC in addition to the required support for MD5. This will facilitate a future migration to SHA-1 without jeopardizing interoperability. Hugo Received: from relay.tis.com by neptune.TIS.COM id aa20219; 23 May 96 20:51 EDT Received: by relay.tis.com; id UAA12215; Thu, 23 May 1996 20:53:08 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012213; Thu, 23 May 96 20:52:39 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18953; Thu, 23 May 96 20:52:49 EDT Received: by relay.tis.com; id UAA12210; Thu, 23 May 1996 20:52:38 -0400 Received: from unknown(204.160.108.2) by relay.tis.com via smap (V3.1) id xma012205; Thu, 23 May 96 20:52:20 -0400 Received: from kind by enforcer.cylink.com with smtp (Smail3.1.29.1 #4) id m0uMl7K-000zUSC; Thu, 23 May 96 17:52 PDT Message-Id: <31A4E010.3BA9@cylink.com> Date: Thu, 23 May 1996 18:00:48 -0400 From: John Kennedy Organization: CYLINK X-Mailer: Mozilla 2.0 (Win16; I) Mime-Version: 1.0 To: HUGO@watson.ibm.com Cc: rja@cisco.com, ipsec@TIS.COM Subject: MD5 vs. SHA-1, Selection Criteria References: <199605232018.QAA61980@mailhub1.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk HUGO@watson.ibm.com wrote: {stuff deleted} > Due to this fact and the performance advantages of MD5 over other > alternatives (e.g., SHA-1)... I'm still not convinced that throughput performance should be a criteria for choosing a default hash function. Just for reference, could someone repost their best performance times for both algorithms? Are we talking about a factor of 2, 10, 100? My guess is that the difference in performance is not significant when compared with the security requirements for the algorithm. And one of those requirements most certainly is "user confidence". I think confidence in MD5 is falling rapidly in the cryptographic community. The fact that HMAC-MD5 is a mode for MD5 usage that doesn't *currently* seem susceptible to the recent attack described by Hans Dobbertin says more for the HMAC technique than the long-term viability of MD5. By not abandoning MD5 outright in favor of SHA-1, I think we are sending the wrong message to the not-so-crypto-saavy community. What about the people that missed this discussion and use MD5 in its native mode because they don't know any better? >From a commercial standpoint, I believe system designers are ill-advised to specify MD5 for new systems and should embrace SHA-1. Security is an endeavor that it best served by a conservative attitude. You certainly don't see anyone trying to keep MD2 and MD4 around as an option. And for good reason! It is interesting that that conservative (sometimes radically) posture usually exhibited by the IPSEC group is not showing up in this case. My position is that MD5 should be immediately abandoned for use in ANY mode. MD5 is a cryptographic algorithm the strength of which is serious dispute. It should be removed from consideration by IETF and other standards committee for use in any form. I also think that implementors should re-examine the cost to move to SHA-1 versus the cost of retaining a hash function that probably has a limited lifetime. And in case this applies to anyone, let me note that just because a company is using MD5 in a current system does not mean it is a good reason to lobby for it as an option in IETF IPSEC. Keeping it around in an existing system is a business decision; it should not be a consideration for a security standard with the longevity this one is expected to have. BTW, if/when SHA-1 begins to shows its age, I will be quite happy to see it retired in a timely manner. -John Kennedy jkennedy@cylink.com Received: from relay.tis.com by neptune.TIS.COM id aa20788; 23 May 96 21:44 EDT Received: by relay.tis.com; id VAA12565; Thu, 23 May 1996 21:45:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012563; Thu, 23 May 96 21:45:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19903; Thu, 23 May 96 21:45:19 EDT Received: by relay.tis.com; id VAA12560; Thu, 23 May 1996 21:45:08 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma012558; Thu, 23 May 96 21:45:04 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id SAA05793 for ipsec@tis.com; Thu, 23 May 1996 18:47:39 -0700 Message-Id: <199605240147.SAA05793@puli.cisco.com> From: Ran Atkinson Date: Thu, 23 May 1996 18:47:39 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: AH HMAC * Last Call Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve Bellovin has asked that both AH HMAC MD5 and AH HMAC SHA be made mandatory to implement. If others agree/disagree, that should be included in your WG Last Call response so Paul and I know what the consensus is. Thanks, Ran rja@cisco.com -- Received: from relay.tis.com by neptune.TIS.COM id aa21170; 23 May 96 22:19 EDT Received: by relay.tis.com; id WAA13106; Thu, 23 May 1996 22:21:23 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013102; Thu, 23 May 96 22:20:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20389; Thu, 23 May 96 22:21:04 EDT Received: by relay.tis.com; id WAA13099; Thu, 23 May 1996 22:20:53 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1) id xma013097; Thu, 23 May 96 22:20:37 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 23 May 1996 19:23:07 -0700 Date: Thu, 23 May 1996 19:23:05 -0700 Posted-Date: Thu, 23 May 1996 19:23:05 -0700 Message-Id: <199605240223.AA01746@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Thu, 23 May 1996 19:23:05 -0700 To: HUGO@watson.ibm.com, jkennedy@cylink.com Subject: Re: MD5 vs. SHA-1, Selection Criteria Cc: asachdev@isi.edu, ipsec@TIS.COM, rja@cisco.com, touch@isi.edu X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Date: Thu, 23 May 1996 18:00:48 -0400 > From: John Kennedy > Subject: MD5 vs. SHA-1, Selection Criteria > > HUGO@watson.ibm.com wrote: > {stuff deleted} > > Due to this fact and the performance advantages of MD5 over other > > alternatives (e.g., SHA-1)... > I'm still not convinced that throughput performance should be a > criteria for choosing a default hash function. Just for reference, > could someone repost their best performance times for both algorithms? > Are we talking about a factor of 2, 10, 100? 2. On A Sun SPARC 20/71 in SunOS 4.1.3, I have measured: stand-alone MD5 60 Mbps +/- 3 Mbps stand-alone SHA 30 Mbps +/- 2 Mbps Note that these are not the performance expected from IP. Our current measurements of MD5 in IPv4 depend on the MTU: 34 Mbps for 8 KB packets (upper bound on our system) 16 Mbps for 4 KB packets 0.6 Mbps for 1.5 KB (ethernet MTU) packets 0.5 Mbps for Internet MTU (512 B) packets > The fact that HMAC-MD5 is a mode for MD5 usage that doesn't > *currently* seem susceptible to the recent attack described by Hans > Dobbertin says more for the HMAC technique than the long-term > viability of MD5. How is HMAC affected by the properties of the hash function used? I have another hash which is admittedly weaker than MD5, but which runs twice as fast as MD5, each in IPv4, for large MTUs. For small MTUs (1KB or less), this is really moot. Three different hashes we tested all run down around 0.3-0.5 Mbps. Joe PS - this is in preparation for Infocomm. ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa21187; 23 May 96 22:20 EDT Received: by relay.tis.com; id WAA13128; Thu, 23 May 1996 22:22:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma013124; Thu, 23 May 96 22:21:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20407; Thu, 23 May 96 22:22:05 EDT Received: by relay.tis.com; id WAA13118; Thu, 23 May 1996 22:21:53 -0400 Received: from toadflax.cs.ucdavis.edu(128.120.56.188) by relay.tis.com via smap (V3.1) id xma013113; Thu, 23 May 96 22:21:29 -0400 Received: from rogaway.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA14534; Thu, 23 May 96 19:23:08 PDT Received: by rogaway.cs.ucdavis.edu (931110.SGI/UCD.CS.2.4) id AA02698; Thu, 23 May 96 19:23:04 -0700 Date: Thu, 23 May 96 19:23:04 -0700 From: Phil Rogaway Message-Id: <9605240223.AA02698@rogaway.cs.ucdavis.edu> To: hughes@network.com Subject: IV treatment in esp-des-md5-01.txt Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi John, I pulled down a copy of your "draft-ietf-ipsec-esp-des-md5-01.txt". I wanted to pass on a comment concerning the way which in you use the IV. It seems to be almost a tradition, but it is NOT correct in DES CBC encryption to use an adversarially-predictable IV (when the IV is used in the usual way). Nor is it correct if any two IVs differ by an adversarially-predictable amount. As a simple illustration, suppose the IV is a counter, initially 0. Then the length-2 sequence of encrypted messages whose plaintext blocks are 0, 0 is easy to differentiate from the length-2 sequence of encrypted messages whose plaintext blocks are 0, 1 (here 0 and 1 representing integers 0 and 1 encoded into 64 bits). Assume the adversary has a. priori. knowledge that the sequence of plaintexts will be one of the above. Then no "good" encryption scheme should be leaking which one; a "good" encryption scheme leaks only the length of each plaintext, even when the adversary has partial information about some of the plaintexts. A clean way to get around this is to define DES-CBC_{k,IV}(x_1 ... x_n) by y_i = DES_k(y_{i-1} xor x_i) where y_0 = DES_k(IV) // instead of y_0 = IV This would make a counter (or any other nonce) fine for an IV, releasing the burden on the user to construct a good-enough IV. It would also make 32 bits adequate for the IV. Under this change I don't know of a cryptographic justification in support of having both the long and short IVs of esp-DES-IV32 and esp-DES-IV64. Also, you could simply consider the replay prevention field as the IV in esp-DES-HMAC-RP. As it currently stands, you'd need to demand that the IV in esp-DES-IV32 and esp-DES-IV64 meet a property which is extremely hard to explain to the user of this document; and in esp-DES-HMAC-RP it looks like the IP isn't going to be right no matter what. Kind regards, Phil Rogaway Received: from relay.tis.com by neptune.TIS.COM id aa28352; 24 May 96 7:18 EDT Received: by relay.tis.com; id HAA16990; Fri, 24 May 1996 07:19:52 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xmaa16988; Fri, 24 May 96 07:19:23 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27884; Fri, 24 May 96 07:19:34 EDT Received: by relay.tis.com; id HAA16985; Fri, 24 May 1996 07:19:22 -0400 Received: from sundance.itd.nrl.navy.mil(132.250.92.89) by relay.tis.com via smap (V3.1) id xma016983; Fri, 24 May 96 07:19:09 -0400 Received: from beech.cs.nrl.navy.mil by sundance.itd.nrl.navy.mil id aa24902; 24 May 96 7:22 EDT To: John Kennedy Cc: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria In-Reply-To: Your message of "Thu, 23 May 1996 18:00:48 EDT." <31A4E010.3BA9@cylink.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Fri, 24 May 1996 07:27:18 -0400 From: Craig Metz Message-Id: <9605240722.aa24902@sundance.itd.nrl.navy.mil> Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <31A4E010.3BA9@cylink.com>, you write: >My position is that MD5 should be immediately abandoned for use in ANY mode. >MD5 is a cryptographic algorithm the strength >of which is serious dispute. It should be removed from consideration by IETF >and other standards committee for use in any >form. Then I trust you'd be happy to do a quick demonstration and hijack an AH HMAC-MD5 protected TCP connection? Until you can show me that, I believe that MD5 has value. The value is that random people cannot defeat it. Maybe major governments can. When it comes to MY traffic, *I* want to be able to make the trade-off between security and performance. I strongly oppose any efforts to completely scrap HMAC-MD5 because it's taking away a legitimate and reasonable choice for the end user. >I also think that implementors should re-examine the cost to move to SH >A-1 versus the cost of retaining a hash >function that probably has a limited lifetime. The flaw in this line of thinking should be obvious. -Craig Received: from relay.tis.com by neptune.TIS.COM id aa28424; 24 May 96 7:20 EDT Received: by relay.tis.com; id HAA17021; Fri, 24 May 1996 07:21:52 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma017011; Fri, 24 May 96 07:21:23 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27927; Fri, 24 May 96 07:21:34 EDT Received: by relay.tis.com; id HAA17005; Fri, 24 May 1996 07:21:22 -0400 Received: from sundance.itd.nrl.navy.mil(132.250.92.89) by relay.tis.com via smap (V3.1) id xma017001; Fri, 24 May 96 07:21:14 -0400 Received: from beech.cs.nrl.navy.mil by sundance.itd.nrl.navy.mil id aa24905; 24 May 96 7:23 EDT To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Re: AH HMAC * Last Call In-Reply-To: Your message of "Thu, 23 May 1996 18:47:39 PDT." <199605240147.SAA05793@puli.cisco.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Fri, 24 May 1996 07:27:58 -0400 From: Craig Metz Message-Id: <9605240723.aa24905@sundance.itd.nrl.navy.mil> Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199605240147.SAA05793@puli.cisco.com>, you write: >Steve Bellovin has asked that both AH HMAC MD5 and AH HMAC SHA be >made mandatory to implement. If others agree/disagree, that should >be included in your WG Last Call response so Paul and I know what >the consensus is. I fully agree. -Craig Received: from relay.tis.com by neptune.TIS.COM id aa00371; 24 May 96 9:24 EDT Received: by relay.tis.com; id JAA19187; Fri, 24 May 1996 09:25:54 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019181; Fri, 24 May 96 09:25:26 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01905; Fri, 24 May 96 09:25:36 EDT Received: by relay.tis.com; id JAA19176; Fri, 24 May 1996 09:25:24 -0400 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1) id xma019172; Fri, 24 May 96 09:25:07 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA19216; Fri, 24 May 1996 09:27:51 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma019214; Fri May 24 09:27:36 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA07809; Fri, 24 May 1996 09:23:56 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA07844; Fri, 24 May 1996 09:27:28 -0400 Date: Fri, 24 May 1996 09:27:28 -0400 From: "David P. Kemp" Message-Id: <199605241327.JAA07844@argon.ncsc.mil> To: rja@cisco.com, palamber@us.oracle.com, ipsec@TIS.COM Subject: Re: AH HMAC * Last Call X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Steve Bellovin has asked that both AH HMAC MD5 and AH HMAC SHA be >made mandatory to implement. If others agree/disagree, that should >be included in your WG Last Call response so Paul and I know what >the consensus is. I believe that HMAC SHA should be mandatory and HMAC MD5 should be optional. There may be performance reasons for preferring MD5 (although Joe Touch's recent data imply that both hashes are poor for ethernet MTUs due to long setup times), so MD5 certainly should not be removed as an option. But making it mandatory sends the wrong message in a protocol designed to be at the heart of Internet security. Conservative design would dictate that only the "most secure" option be mandatory, while still allowing implementors to make performance tradeoffs if they feel it's in their best interests. It appears *at this time* that the HMAC construct is powerful enough to resist Dobbertin's attacks against MD5. But there must be a limit to the ability of HMAC to hide weaknesses in the hash function - I wouldn't expect AH-HMAC-CRC16, for example, to be a useful mode :-). Based on current knowledge, it is reasonable to predict that MD5 will fall to a level where HMAC can't protect it before that happens to SHA. It is true that making MD5 mandatory to implement does not take away anyone's option to not use it. But a standards-track protocol will be at least referenced, if not read, by people with a wide range of expertise. The mandatory status of an algorithm will be easily understood by those not necessarily familiar with the qualifications attached to its use. For this reason MD5 should be optional. Received: from relay.tis.com by neptune.TIS.COM id aa00923; 24 May 96 9:57 EDT Received: by relay.tis.com; id JAA19944; Fri, 24 May 1996 09:58:42 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019933; Fri, 24 May 96 09:58:20 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03132; Fri, 24 May 96 09:58:30 EDT Received: by relay.tis.com; id JAA19924; Fri, 24 May 1996 09:58:18 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma019913; Fri, 24 May 96 09:57:50 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id KAA19434; Fri, 24 May 1996 10:00:38 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.2.250.126]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id KAA68393; Fri, 24 May 1996 10:00:17 -0400 Message-Id: <199605241400.KAA68393@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2169; Fri, 24 May 96 10:00:05 EDT Date: Fri, 24 May 96 09:44:48 EDT To: jkennedy@cylink.com Cc: ipsec@TIS.COM Subject: MD5 vs. SHA-1, Selection Criteria Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 23 May 1996 18:00:48 -0400 (attached) jkennedy@cylink.com wrote: > > HUGO@watson.ibm.com wrote: {stuff deleted} > And in case this applies to anyone, let me note that just because a company > is using MD5 in a current system does not mean it is a good reason to lobby for it as an option in IETF IPSEC. I'd like to believe this is not directed to me and IBM; I would have found such a suggestion personally insulting. Hugo PS: Well, the truth is that IBM was trying hard to buy MD5 for some time; since the coup didn't succeed we went and bought Lotus... Received: from relay.tis.com by neptune.TIS.COM id aa04263; 24 May 96 13:17 EDT Received: by relay.tis.com; id NAA24332; Fri, 24 May 1996 13:19:06 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024302; Fri, 24 May 96 13:18:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11203; Fri, 24 May 96 13:18:48 EDT Received: by relay.tis.com; id NAA24299; Fri, 24 May 1996 13:18:36 -0400 Received: from unknown(204.160.108.2) by relay.tis.com via smap (V3.1) id xma024289; Fri, 24 May 96 13:18:12 -0400 Received: from kind by enforcer.cylink.com with smtp (Smail3.1.29.1 #4) id m0uN0X1-000zUSC; Fri, 24 May 96 10:20 PDT Message-Id: <31A5C798.2CFA@cylink.com> Date: Fri, 24 May 1996 10:28:40 -0400 From: John Kennedy Organization: CYLINK X-Mailer: Mozilla 2.0 (Win16; I) Mime-Version: 1.0 To: HUGO@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria References: <199605241400.KAA68393@mailhub1.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk HUGO@watson.ibm.com wrote: > > Ref: Your note of Thu, 23 May 1996 18:00:48 -0400 (attached) > > jkennedy@cylink.com wrote: > > > > HUGO@watson.ibm.com wrote: > {stuff deleted} > > And in case this applies to anyone, let me note that just because a company > > is using MD5 in a current system does not mean it is a good reason to lobby for it as an option in IETF IPSEC. > > I'd like to believe this is not directed to me and IBM; I would have found > such a suggestion personally insulting. > > Hugo > > PS: Well, the truth is that IBM was trying hard to buy MD5 for some time; > since the coup didn't succeed we went and bought Lotus... Hugo, This comment was honestly not directed to you, IBM, or anyone else in particular. It was directed to the broad mailing list audience. It is merely my own opinion on the standards development process and something I wanted to open up dialog on. Personal attacks have no place in this process. The fact that I happened to respond to *your* message in that thread was just a matter of chance. Regards, -John Kennedy jkennedy@cylink.com Received: from relay.tis.com by neptune.TIS.COM id aa04871; 24 May 96 13:52 EDT Received: by relay.tis.com; id NAA25296; Fri, 24 May 1996 13:54:07 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025282; Fri, 24 May 96 13:53:38 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13031; Fri, 24 May 96 13:53:48 EDT Received: by relay.tis.com; id NAA25279; Fri, 24 May 1996 13:53:36 -0400 Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma025268; Fri, 24 May 96 13:53:10 -0400 Received: from sloth.ncsl.nist.gov (sloth.ncsl.nist.gov [129.6.55.36]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with ESMTP id NAA18764; Fri, 24 May 1996 13:55:35 -0400 (EDT) From: Robert Glenn Received: (from glenn@localhost) by sloth.ncsl.nist.gov (8.7.5/8.7.3) id NAA15403; Fri, 24 May 1996 13:54:59 -0400 (EDT) Date: Fri, 24 May 1996 13:54:59 -0400 (EDT) Message-Id: <199605241754.NAA15403@sloth.ncsl.nist.gov> To: rja@cisco.com, palamber@us.oracle.com Subject: Re: AH HMAC * Last Call Cc: ipsec@TIS.COM, rob.glenn@nist.gov Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm not sure of the benefit of having multiple AH transforms mandatory to implement. I thought the purpose of having *one* was to insure interoperability and to perhaps provide some kind of baseline. Having two will just muddy the waters, so to speak. On that note, I think selecting HMAC SHA as mandatory and HMAC MD5 as optional is best. Rob G. rob.glenn@nist.gov Received: from relay.tis.com by neptune.TIS.COM id aa04896; 24 May 96 13:54 EDT Received: by relay.tis.com; id NAA25349; Fri, 24 May 1996 13:56:06 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025346; Fri, 24 May 96 13:55:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13130; Fri, 24 May 96 13:55:49 EDT Received: by relay.tis.com; id NAA25338; Fri, 24 May 1996 13:55:37 -0400 Received: from park.interport.net(199.184.165.2) by relay.tis.com via smap (V3.1) id xma025327; Fri, 24 May 96 13:55:09 -0400 Received: from ferguson ([199.249.254.9]) by park.interport.net (8.7.3/8.7.3) with SMTP id NAA00859 for ; Fri, 24 May 1996 13:57:43 -0400 (EDT) Message-Id: <199605241757.NAA00859@park.interport.net> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 May 1996 13:57:46 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: sha vs. md5 Sender: ipsec-approval@neptune.tis.com Precedence: bulk After reading John Kennedy's comments on SHA-1 I decided I should share a couple of my thoughts. I don't mean to start a fight, just to offer some opinions... - I think it's architecturally unsound to mandate a protocol that can't be exported from the U.S. besides, I believe it violates 1825, which makes a comment on AH always being exportable. - I agree that I expect we should be conservative on crypto issues and an "it seems to be still ok" attitude sounds inappropriate. - as I recall the last time I got to fill out export paperwork there was no check-box marked "somebody on an IETF mailing list said the NSA said in a telephone call it was ok to export this" so I do think you need to get paperwork for this stuff, which makes it hard to move across country boundries, which impacts deployment, which impacts architecture, which makes exportability a technical issue -- sorry. Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" Received: from relay.tis.com by neptune.TIS.COM id aa05095; 24 May 96 14:02 EDT Received: by relay.tis.com; id OAA25683; Fri, 24 May 1996 14:04:09 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025679; Fri, 24 May 96 14:03:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13714; Fri, 24 May 96 14:03:53 EDT Received: by relay.tis.com; id OAA25667; Fri, 24 May 1996 14:03:39 -0400 Received: from baa01075.slip.digex.net(204.91.208.66) by relay.tis.com via smap (V3.1) id xma025654; Fri, 24 May 96 14:03:15 -0400 Received: (from karn@localhost) by baa01075.slip.digex.net (8.7.4/8.7.3) id NAA00260; Fri, 24 May 1996 13:33:31 -0400 (EDT) Date: Fri, 24 May 1996 13:33:31 -0400 (EDT) From: Phil Karn Jr Message-Id: <199605241733.NAA00260@baa01075.slip.digex.net> To: ylo@ssh.fi Cc: ipsec@TIS.COM In-Reply-To: <199605231753.UAA21385@pilari.ssh.fi> (message from Tatu Ylonen on Thu, 23 May 1996 20:53:26 +0300 (EET DST)) Subject: Re: Whatever happend to compression? Reply-To: karn@qualcomm.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk >My experience from SSH is that for terminal sessions, compression >reduces the amount of data transmitted in the server->client direction >to about a third. That is the direction in which most of the data >flows. You update the entire screen very often. I can buy that. Of course, you probably aren't saturating your link (unless it's very slow) since at some point you have to read the stuff you're receiving. Also, I'd expect that compression in ssh, which is the application layer, works much better than compression at a lower packet level since it can work on a very long stream. Anybody have more precise figures on this point? Phil Received: from relay.tis.com by neptune.TIS.COM id aa05059; 24 May 96 14:01 EDT Received: by relay.tis.com; id OAA25633; Fri, 24 May 1996 14:03:07 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025620; Fri, 24 May 96 14:02:40 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13619; Fri, 24 May 96 14:02:50 EDT Received: by relay.tis.com; id OAA25605; Fri, 24 May 1996 14:02:37 -0400 Received: from baa01075.slip.digex.net(204.91.208.66) by relay.tis.com via smap (V3.1) id xma025592; Fri, 24 May 96 14:02:11 -0400 Received: (from karn@localhost) by baa01075.slip.digex.net (8.7.4/8.7.3) id NAA00272; Fri, 24 May 1996 13:49:52 -0400 (EDT) Date: Fri, 24 May 1996 13:49:52 -0400 (EDT) From: Phil Karn Jr Message-Id: <199605241749.NAA00272@baa01075.slip.digex.net> To: jkennedy@cylink.com Cc: HUGO@watson.ibm.com, rja@cisco.com, ipsec@TIS.COM In-Reply-To: <31A4E010.3BA9@cylink.com> (message from John Kennedy on Thu, 23 May 1996 18:00:48 -0400) Subject: Re: MD5 vs. SHA-1, Selection Criteria Reply-To: karn@qualcomm.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk John, I'm all in favor of being conservative when it comes to choosing ciphers. My only concern is whether SHA-1 has had the level of intensive study as MD5. Would we be merely jumping from the frying pan into the fire? I really don't know the answer. Phil Received: from relay.tis.com by neptune.TIS.COM id aa06093; 24 May 96 14:49 EDT Received: by relay.tis.com; id OAA27206; Fri, 24 May 1996 14:51:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027182; Fri, 24 May 96 14:50:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16498; Fri, 24 May 96 14:50:51 EDT Received: by relay.tis.com; id OAA27179; Fri, 24 May 1996 14:50:39 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma027175; Fri, 24 May 96 14:50:23 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id OAA00221; Fri, 24 May 1996 14:52:50 -0400 (EDT) Message-Id: <199605241852.OAA00221@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: karn@qualcomm.com Cc: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria In-Reply-To: Your message of "Fri, 24 May 1996 13:49:52 EDT." <199605241749.NAA00272@baa01075.slip.digex.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 May 1996 14:52:49 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn Jr writes: > I'm all in favor of being conservative when it comes to choosing ciphers. > My only concern is whether SHA-1 has had the level of intensive study as > MD5. Would we be merely jumping from the frying pan into the fire? I really > don't know the answer. SHA-1 is a product of our friends at the NSA. Although I'm not always a fan of their export policies, they do appear to usually release algorithms of the highest possible quality. Perry Received: from relay.tis.com by neptune.TIS.COM id aa06174; 24 May 96 14:51 EDT Received: by relay.tis.com; id OAA27250; Fri, 24 May 1996 14:52:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027243; Fri, 24 May 96 14:52:12 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16578; Fri, 24 May 96 14:52:22 EDT Received: by relay.tis.com; id OAA27237; Fri, 24 May 1996 14:52:10 -0400 Received: from unknown(204.160.108.2) by relay.tis.com via smap (V3.1) id xma027232; Fri, 24 May 96 14:51:59 -0400 Received: from kind by enforcer.cylink.com with smtp (Smail3.1.29.1 #4) id m0uN1Zy-000zUUC; Fri, 24 May 96 11:27 PDT Message-Id: <31A5D755.796C@cylink.com> Date: Fri, 24 May 1996 11:35:49 -0400 From: John Kennedy Organization: CYLINK X-Mailer: Mozilla 2.0 (Win16; I) Mime-Version: 1.0 To: Craig Metz Cc: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria References: <9605240722.aa24902@sundance.itd.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Craig Metz wrote: > ---------- > In message <31A4E010.3BA9@cylink.com>, you write: > >My position is that MD5 should be immediately abandoned for use in ANY mode. > >MD5 is a cryptographic algorithm the strength > >of which is serious dispute. It should be removed from consideration by IETF > >and other standards committee for use in any > >form. > > Then I trust you'd be happy to do a quick demonstration and hijack > an AH HMAC-MD5 protected TCP connection? > > > Until you can show me that, I believe that MD5 has value. The value is > that random people cannot defeat it. Maybe major governments can. When it comes > to MY traffic, *I* want to be able to make the trade-off between security and > performance. > ---------- I agree that MD5 still has some value, but not as much long-term value as SHA-1. DES still has plenty of value, too, but new standards are moving away from DES to Triple-DES and other stronger algorithms. Not because DES is broken now, but because the safety margin seems to be shrinking. > ---------- > >I also think that implementors should re-examine the cost to move to SH > >A-1 versus the cost of retaining a hash > >function that probably has a limited lifetime. > > The flaw in this line of thinking should be obvious. > > -Craig >----------- I guess it wasn't obvious to me. :) If I gave you a free implementation of SHA-1 that ran as fast or faster than MD5, would that change your mind? My goal was to solicit debate on Performance vs. Perceived Strength vs. Utility. We all place different weight on these criteria depending on the task at hand. Finding a compromise is one of our unenviable tasks as a working group. Perhaps Steve Bellovin's suggestion of making both HMAC-MD5 and HMAC-SHA1 mandatory to implement is a suitable compromise. However, I think that by keeping HMAC-MD5 as an *optional* transform that we encourage the use of stronger cryptography over higher performance where it can be accomodated. -John Kennedy jkennedy@cylink.com Received: from relay.tis.com by neptune.TIS.COM id aa06172; 24 May 96 14:51 EDT Received: by relay.tis.com; id OAA27248; Fri, 24 May 1996 14:52:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027242; Fri, 24 May 96 14:52:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16577; Fri, 24 May 96 14:52:21 EDT Received: by relay.tis.com; id OAA27236; Fri, 24 May 1996 14:52:10 -0400 Received: from unknown(204.160.108.2) by relay.tis.com via smap (V3.1) id xma027231; Fri, 24 May 96 14:51:54 -0400 Received: from kind by enforcer.cylink.com with smtp (Smail3.1.29.1 #4) id m0uN1hy-000zUSC; Fri, 24 May 96 11:35 PDT Message-Id: <31A5D946.4F60@cylink.com> Date: Fri, 24 May 1996 11:44:06 -0400 From: John Kennedy Organization: CYLINK X-Mailer: Mozilla 2.0 (Win16; I) Mime-Version: 1.0 To: karn@qualcomm.com Cc: HUGO@watson.ibm.com, rja@cisco.com, ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria References: <199605241749.NAA00272@baa01075.slip.digex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn Jr wrote: > > John, > > I'm all in favor of being conservative when it comes to choosing ciphers. > My only concern is whether SHA-1 has had the level of intensive study as > MD5. Would we be merely jumping from the frying pan into the fire? I really > don't know the answer. > > Phil I have heard things regarding the MD5-to-SHA-to-SHA1 evolution in conversations with cryptographers at NIST and NSA that lead me to believe that SHA-1 has been very thoroughly reviewed and is much more robust than MD5. It is unfortunate that this review isn't as complete in the public arena. -John Received: from relay.tis.com by neptune.TIS.COM id aa06450; 24 May 96 14:56 EDT Received: by relay.tis.com; id OAA27355; Fri, 24 May 1996 14:57:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027345; Fri, 24 May 96 14:57:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16741; Fri, 24 May 96 14:57:24 EDT Received: by relay.tis.com; id OAA27325; Fri, 24 May 1996 14:57:10 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1) id xma027309; Fri, 24 May 96 14:56:40 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id OAA00253; Fri, 24 May 1996 14:57:29 -0400 (EDT) Message-Id: <199605241857.OAA00253@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: karn@qualcomm.com Cc: ylo@ssh.fi, ipsec@TIS.COM Subject: Re: Whatever happend to compression? In-Reply-To: Your message of "Fri, 24 May 1996 13:33:31 EDT." <199605241733.NAA00260@baa01075.slip.digex.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 May 1996 14:57:25 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn Jr writes: > Also, I'd expect that compression in ssh, which is > the application layer, works much better than compression at a lower > packet level since it can work on a very long stream. I would tend to believe that as well. Perry Received: from relay.tis.com by neptune.TIS.COM id aa07506; 24 May 96 15:40 EDT Received: by relay.tis.com; id PAA28289; Fri, 24 May 1996 15:42:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028279; Fri, 24 May 96 15:41:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18803; Fri, 24 May 96 15:41:52 EDT Received: by relay.tis.com; id PAA28274; Fri, 24 May 1996 15:41:40 -0400 Received: from sass165.sandia.gov(132.175.109.1) by relay.tis.com via smap (V3.1) id xma028268; Fri, 24 May 96 15:41:29 -0400 Received: from sahp356.sandia.gov (sahp356.sandia.gov [134.253.181.7]) by sass165.sandia.gov (8.6.12/8.6.12) with SMTP id NAA03051 for ; Fri, 24 May 1996 13:44:06 -0600 X400-Received: by /c=US/admd= /prmd=USDOE/; converted ( IA5-Text); Relayed; 24 May 1996 13:42:20 -0700 X400-Received: by mta mtaSNL in /c=US/admd= /prmd=USDOE/; converted ( IA5-Text); Relayed; 24 May 1996 13:42:20 -0700 X400-Mts-Identifier: [/c=US/admd= /prmd=USDOE/; 028FD31A6111C00C-mtaSNL] Content-Identifier: 028FD31A6111C00C Content-Return: Allowed X400-Content-Type: P2-1988 ( 22 ) Conversion: Allowed Original-Encoded-Information-Types: IA5-Text Priority: normal Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: GGISTRA@sandia.gov X400-Recipients: non-disclosure; Message-Id: <"028FD31A6111C00C*/c=US/admd= /prmd=USDOE/o=SNL/ou=msmail/s=GGISTRA/"@MHS> Date: 24 May 1996 13:42:20 -0700 From: "Istrail, Gabi 9417 M" To: ipsec Subject: Photuris implementations ? Mime-Version: 1.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk I am looking for implementations of the Photuris Session Key Management Protocol. Could you point me in the right direction ? Thanks, Gabi Istrail Received: from relay.tis.com by neptune.TIS.COM id aa07919; 24 May 96 15:57 EDT Received: by relay.tis.com; id PAA28673; Fri, 24 May 1996 15:59:10 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028668; Fri, 24 May 96 15:58:44 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19514; Fri, 24 May 96 15:58:53 EDT Received: by relay.tis.com; id PAA28665; Fri, 24 May 1996 15:58:40 -0400 Received: from ns.border.com(199.71.190.98) by relay.tis.com via smap (V3.1) id xma028659; Fri, 24 May 96 15:58:17 -0400 Received: by janus.border.com id <18434-1>; Fri, 24 May 1996 16:00:19 -0400 Message-Id: <96May24.160019edt.18434-1@janus.border.com> To: Rodney Thayer Cc: ipsec@TIS.COM Subject: Re: sha vs. md5 References: <199605241757.NAA00859@park.interport.net> In-Reply-To: Your message of "Fri, 24 May 1996 13:57:46 -0400". <199605241757.NAA00859@park.interport.net> From: "C. Harald Koch" Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Fri, 24 May 1996 15:59:14 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199605241757.NAA00859@park.interport.net>, Rodney Thayer writes: > > - I think it's architecturally unsound to mandate a protocol that can't be > exported from the U.S. besides, I believe it violates 1825, which makes a > comment on AH always being exportable. Several people on the list have pointed out that MD5 and SHA-1 are covered by the *same* U.S. export restrictions. So by your arguent, we should not mandate either algorithm. In message <199605241754.NAA15403@sloth.ncsl.nist.gov>, Robert Glenn writes: > > I'm not sure of the benefit of having multiple AH transforms mandatory > to implement. I thought the purpose of having *one* was to insure > interoperability and to perhaps provide some kind of baseline. Having > two will just muddy the waters, so to speak. We are creating standards here. It is not our job to dictate security v.s. performance tradeoffs to end users; it is our job to make it possible for end users to make these decisions for themselves. As such, mandating *both* algorithms is the only option that will support the choice, while still allowing full interoperability. [ Yes, I'm for making both algorithms mandatory. ] -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.tis.com by neptune.TIS.COM id aa08364; 24 May 96 16:18 EDT Received: by relay.tis.com; id QAA29080; Fri, 24 May 1996 16:19:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029073; Fri, 24 May 96 16:19:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20289; Fri, 24 May 96 16:19:22 EDT Received: by relay.tis.com; id QAA29070; Fri, 24 May 1996 16:19:10 -0400 Received: from sundance.itd.nrl.navy.mil(132.250.92.89) by relay.tis.com via smap (V3.1) id xma029067; Fri, 24 May 96 16:19:07 -0400 Received: from beech.cs.nrl.navy.mil by sundance.itd.nrl.navy.mil id aa25878; 24 May 96 16:22 EDT To: John Kennedy Cc: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria In-Reply-To: Your message of "Fri, 24 May 1996 11:35:49 EDT." <31A5D755.796C@cylink.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Fri, 24 May 1996 16:26:53 -0400 From: Craig Metz Message-Id: <9605241622.aa25878@sundance.itd.nrl.navy.mil> Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <31A5D755.796C@cylink.com>, you write: >If I gave you a free implementation of SHA >-1 that ran as fast or faster than MD5, >would that change your mind? I'd be very interested in seeing this. All of the SHA code I've seen thus far is slower than MD5. (Most of it's pretty poorly written, too.) >Perhaps Steve Bellovin's suggestion of making both HMAC-MD5 and HMAC-SHA1 mand >atory to implement is a suitable >compromise. However, I think that by keeping HMAC-MD5 as an *optional* transf >orm that we encourage the use of stronger >cryptography over higher performance where it can be accomodated. I think a strong argument in favor of making both mandatory is simply the desire to have at least two options available to the end user. If someone posted a short program to sci.crypt tomorrow that could recover a key from an AH HMAC-SHA stream (extremely unlikely, but just suppose), would you want to have to wait for a vendor to get you an update (and how long have certain vendors sat on security fixes in the past?) or would you like to twiddle a configuration knob to change your local default? I don't know about you, but I want to have a backup available in all cases that I can choose to use. Just in case. (We should do the same for encryption...) -Craig Received: from relay.tis.com by neptune.TIS.COM id aa10596; 24 May 96 18:20 EDT Received: by relay.tis.com; id SAA01219; Fri, 24 May 1996 18:22:11 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001214; Fri, 24 May 96 18:21:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24327; Fri, 24 May 96 18:21:52 EDT Received: by relay.tis.com; id SAA01211; Fri, 24 May 1996 18:21:40 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1) id xma001207; Fri, 24 May 96 18:21:32 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 24 May 1996 15:24:07 -0700 Date: Fri, 24 May 1996 15:24:00 -0700 Posted-Date: Fri, 24 May 1996 15:24:00 -0700 Message-Id: <199605242224.AA03131@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 24 May 1996 15:24:00 -0700 To: jkennedy@cylink.com, cmetz@inner.net Subject: Re: MD5 vs. SHA-1, Selection Criteria Cc: ipsec@TIS.COM, asachdev@isi.edu X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Date: Fri, 24 May 1996 16:26:53 -0400 > From: Craig Metz > > In message <31A5D755.796C@cylink.com>, you write: > >If I gave you a free implementation of SHA > >-1 that ran as fast or faster than MD5, > >would that change your mind? It may be surprising. Given that, according to "Applied Crypto", 2nd Ed., p445, (including recent Addenda), SHA is MD4 with an expanded transform, an extra round, and better avalanche effect MD5 is MD4 with improved bit-hashing, an extra round, and better avalanche effect The fact that SHA appears to be half as fast as MD5 hints that SHA's transform costs more than MD5's bit-hash improvements, but that they are algorithmically very similar, and that in fact SHA is slightly more work (expanded transform vs. different bit-hash function) than MD5. > I'd be very interested in seeing this. All of the SHA code I've seen > thus far is slower than MD5. (Most of it's pretty poorly written, too.) Even the MD5 code, however you consider it written, is within about 20% of it's analytical maximum, this seems moot. The overall performance isn't going to change by 1-2 orders of magnitude. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa12535; 24 May 96 21:00 EDT Received: by relay.tis.com; id VAA02050; Fri, 24 May 1996 21:01:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002046; Fri, 24 May 96 21:01:12 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27347; Fri, 24 May 96 21:01:22 EDT Received: by relay.tis.com; id VAA02040; Fri, 24 May 1996 21:01:10 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma002036; Fri, 24 May 96 21:00:44 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id SAA09022; Fri, 24 May 1996 18:03:19 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA28110; Fri, 24 May 1996 18:03:18 -0700 Message-Id: <9605250103.AA28110@maildig1.us.oracle.com> Date: Fri, 24 May 1996 18:03:18 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Yet another SHA/MD5 comment .... my last X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 24-May-96 07:27 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-20289777-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-20289777-0-0 >I strongly oppose any efforts to completely scrap HMAC-MD5 because .... It would seem easier to use SHA for all baseline specification under consideration, not because HMAC-MD5 has a specific vulnerability, but because we want to limit the number of choices. So, to clarify my earlier comments to this poll ... HMAC-SHA should be mandatory for AH and anything else should be elective. Protocol Mandatory Transform ---------------------------------- AH HMAC-SHA ESP SHA-DES (tbd - SHA inside or outside ... DES-SHA) Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-20289777-0-0 Content-Type: message/rfc822 Date: 24 May 96 07:27:18 From:"Craig Metz " To: John,Kennedy,jkennedy@cylink.com Subject: Re: MD5 vs. SHA-1, Selection Criteria Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: Your message of "Thu, 23 May 1996 18:00:48 EDT." X-Orcl-Application: In-Reply-To: <31A4E010.3BA9@cylink.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk In message <31A4E010.3BA9@cylink.com>, you write: >My position is that MD5 should be immediately abandoned for use in ANY mode. >MD5 is a cryptographic algorithm the strength >of which is serious dispute. It should be removed from consideration by IETF >and other standards committee for use in any >form. Then I trust you'd be happy to do a quick demonstration and hijack an AH HMAC-MD5 protected TCP connection? Until you can show me that, I believe that MD5 has value. The value is that random people cannot defeat it. Maybe major governments can. When it comes to MY traffic, *I* want to be able to make the trade-off between security and performance. I strongly oppose any efforts to completely scrap HMAC-MD5 because it's taking away a legitimate and reasonable choice for the end user. >I also think that implementors should re-examine the cost to move to SH >A-1 versus the cost of retaining a hash >function that probably has a limited lifetime. The flaw in this line of thinking should be obvious. -Craig --Boundary-20289777-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa12569; 24 May 96 21:01 EDT Received: by relay.tis.com; id VAA02065; Fri, 24 May 1996 21:02:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002063; Fri, 24 May 96 21:02:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27365; Fri, 24 May 96 21:02:22 EDT Received: by relay.tis.com; id VAA02060; Fri, 24 May 1996 21:02:10 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma002056; Fri, 24 May 96 21:01:58 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA29159; Fri, 24 May 1996 18:04:35 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id SAA04644; Fri, 24 May 1996 18:07:40 -0700 (PDT) Message-Id: <199605250107.SAA04644@mailsun2.us.oracle.com> Date: 24 May 96 18:04:54 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: Results of quick survey Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-5037284-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-5037284-0-0 I'll vote for SHA for all uses (AH, ESP) and hashing inside the encryption (ESP conf & integrity) ... Paul --Boundary-5037284-0-0 Content-Type: message/rfc822 Date: 22 May 96 17:40:32 From:"Uri Blumenthal " To: Phil,Karn,karn@qualcomm.com Subject: Re: Results of quick survey Cc: ipsec@tis.com Reply-to: uri@watson.ibm.com X-Orcl-Application: In-Reply-To: <199605222002.NAA29982@servo.qualcomm.com> from "Phil Karn" at May 22, 96 01:02:06 pm X-Mailer: ELM [version 2.4 PL25] X-Orcl-Application: Content-Type: text X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk Phil Karn says: > One point about the relative ordering of authentication and encryption. > Even though I can now do DES pretty fast, it's still true that if you > wrap encryption outside authentication then you still have to perform > both algorithms to determine that the packet is bogus. On the other hand, it is considered best to authenticate the "final result" date, which is the plaintext. For "proving" that this encrypted data was "kosher" strictly speaking, is NOT equivalent to "proving" that the decrypted data is what was sent (i.e. it may decrypt to different things under different keys and so on)... Do we care? [I understand your concern about performance.] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- --Boundary-5037284-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa13025; 24 May 96 21:38 EDT Received: by relay.tis.com; id VAA02348; Fri, 24 May 1996 21:39:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002346; Fri, 24 May 96 21:39:12 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27816; Fri, 24 May 96 21:39:22 EDT Received: by relay.tis.com; id VAA02343; Fri, 24 May 1996 21:39:10 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1) id xma002341; Fri, 24 May 96 21:39:08 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA25087; Fri, 24 May 1996 18:41:44 -0700 Received: by mailsun2.us.oracle.com (8.7.1/37.8) id SAA07223; Fri, 24 May 1996 18:44:49 -0700 (PDT) Message-Id: <199605250144.SAA07223@mailsun2.us.oracle.com> Date: 24 May 96 18:38:49 -0700 From: "PALAMBER.US.ORACLE.COM" To: rodney@wizard.pn.com Subject: Re: sha vs. md5 Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 24-May-96 13:57 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-5037796-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-5037796-0-0 Rodney, Your comments are not useful in the determination of the IPsec use of MD5 versus SHA: >- as I recall the last time I got to fill out export paperwork there was no >check-box marked "somebody on an IETF mailing list said the NSA said in a >telephone call it was ok to export this" so I do think you need to get >paperwork for this stuff, which makes it hard to move across country >boundries, which impacts deployment, which impacts architecture, which makes >exportability a technical issue -- sorry. My comments that you refer have never stated the above ... my point has always been that: - SHA and MD5 are both export controlled - SHA and MD5 when used only for integrity checks are "easy" to export (as compared to encryption). - export considerations are not consideration when comparing the use of SHA to MD5 So, please ... my e-mail box is filling with irrelevant SHA versus MD5 comments, please be concise in this polling of comments. Additional noise only obscures the legitimate points that people are trying to make. Paul --Boundary-5037796-0-0 Content-Type: message/rfc822 Date: 24 May 96 13:57:46 From:"Rodney Thayer " To: ipsec@tis.com Subject: sha vs. md5 X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 X-Orcl-Application: Mime-Version: 1.0 X-Orcl-Application: Content-Type: text/plain; charset="us-ascii" X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk After reading John Kennedy's comments on SHA-1 I decided I should share a couple of my thoughts. I don't mean to start a fight, just to offer some opinions... - I think it's architecturally unsound to mandate a protocol that can't be exported from the U.S. besides, I believe it violates 1825, which makes a comment on AH always being exportable. - I agree that I expect we should be conservative on crypto issues and an "it seems to be still ok" attitude sounds inappropriate. - as I recall the last time I got to fill out export paperwork there was no check-box marked "somebody on an IETF mailing list said the NSA said in a telephone call it was ok to export this" so I do think you need to get paperwork for this stuff, which makes it hard to move across country boundries, which impacts deployment, which impacts architecture, which makes exportability a technical issue -- sorry. Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" --Boundary-5037796-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa14920; 25 May 96 0:47 EDT Received: by relay.tis.com; id AAA02984; Sat, 25 May 1996 00:49:11 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma002982; Sat, 25 May 96 00:48:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29756; Sat, 25 May 96 00:48:52 EDT Received: by relay.tis.com; id AAA02979; Sat, 25 May 1996 00:48:41 -0400 Received: from baa01075.slip.digex.net(204.91.208.66) by relay.tis.com via smap (V3.1) id xma002977; Sat, 25 May 96 00:48:30 -0400 Received: (from karn@localhost) by baa01075.slip.digex.net (8.7.4/8.7.3) id AAA00389; Sat, 25 May 1996 00:29:55 -0400 (EDT) Date: Sat, 25 May 1996 00:29:55 -0400 (EDT) From: Phil Karn Jr Message-Id: <199605250429.AAA00389@baa01075.slip.digex.net> To: perry@piermont.com Cc: ipsec@TIS.COM In-Reply-To: <199605241852.OAA00221@jekyll.piermont.com> (perry@piermont.com) Subject: Re: MD5 vs. SHA-1, Selection Criteria Reply-To: karn@qualcomm.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk >SHA-1 is a product of our friends at the NSA. Although I'm not always >a fan of their export policies, they do appear to usually release >algorithms of the highest possible quality. Assuming, of course, that they are properly motivated to do so. They certainly know as well as we do that a well designed hash function can serve as the primitive of a strong cipher. I suspect they knew this well before they read it in Applied Cryptography and in Dan Bernstein's famous "snuffle" papers. So given NSA's well-documented reluctance to distribute strong ciphers without a back door, I am highly skeptical that they really made SHA-1 as strong as it could be. Or maybe I'm just paranoid. But it's a point worth considering. Phil Received: from relay.tis.com by neptune.TIS.COM id aa25749; 25 May 96 22:20 EDT Received: by relay.tis.com; id WAA06858; Sat, 25 May 1996 22:22:16 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006853; Sat, 25 May 96 22:21:47 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11839; Sat, 25 May 96 22:21:57 EDT Received: by relay.tis.com; id WAA06849; Sat, 25 May 1996 22:21:46 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma006847; Sat, 25 May 96 22:21:18 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id WAA10423; Sat, 25 May 1996 22:24:02 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA53605; Sat, 25 May 1996 22:23:43 -0400 From: Uri Blumenthal Message-Id: <9605260223.AA53605@hawpub.watson.ibm.com> Subject: Re: MD5 vs. SHA-1, Selection Criteria To: touch@isi.edu Date: Sat, 25 May 1996 22:23:43 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <199605240223.AA01746@ash.isi.edu> from "touch@isi.edu" at May 23, 96 07:23:05 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk touch@isi.edu says: > 2. On A Sun SPARC 20/71 in SunOS 4.1.3, I have measured: > > stand-alone MD5 60 Mbps +/- 3 Mbps > stand-alone SHA 30 Mbps +/- 2 Mbps I have similar data (factor of 2) on Pentium under Linux-1.2.13. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa05920; 26 May 96 19:19 EDT Received: by relay.tis.com; id TAA09159; Sun, 26 May 1996 19:21:19 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009157; Sun, 26 May 96 19:20:51 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23024; Sun, 26 May 96 19:20:59 EDT Received: by relay.tis.com; id TAA09152; Sun, 26 May 1996 19:20:49 -0400 Received: from park.interport.net(199.184.165.2) by relay.tis.com via smap (V3.1) id xma009148; Sun, 26 May 96 19:20:48 -0400 Received: from sabletech (sabletech.pn.com [204.96.41.98]) by park.interport.net (8.7.3/8.7.3) with SMTP id TAA10064 for ; Sun, 26 May 1996 19:23:14 -0400 (EDT) Message-Id: <199605262323.TAA10064@park.interport.net> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 26 May 1996 19:23:22 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: I love the IETF Sender: ipsec-approval@neptune.tis.com Precedence: bulk I can always tell I've succeeded in particiating in an IETF discussion when someone yells at me when I say something I thought was reasonable. that's why they call it "rough" concensus. Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" Received: from relay.tis.com by neptune.TIS.COM id aa06993; 26 May 96 21:09 EDT Received: by relay.tis.com; id VAA09474; Sun, 26 May 1996 21:11:19 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009472; Sun, 26 May 96 21:10:50 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24042; Sun, 26 May 96 21:10:59 EDT Received: by relay.tis.com; id VAA09469; Sun, 26 May 1996 21:10:49 -0400 Received: from optima.cs.arizona.edu(192.12.69.5) by relay.tis.com via smap (V3.1) id xma009467; Sun, 26 May 96 21:10:36 -0400 Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA04352; Sun, 26 May 1996 18:13:05 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA05688; Sun, 26 May 1996 18:13:04 -0700 Date: Sun, 26 May 1996 18:13:04 -0700 From: Hilarie Orman Message-Id: <9605270113.AA05688@uncial.CS.Arizona.EDU> To: ipsec@TIS.COM In-Reply-To: Yourmessage <199605242224.AA03131@ash.isi.edu> Subject: Re: MD5 vs. SHA-1, Selection Criteria Sender: ipsec-approval@neptune.tis.com Precedence: bulk Here's a question for crypto prognisticators. Which will craze first, HMAC MD5 or SHA-1? Received: from relay.tis.com by neptune.TIS.COM id aa16435; 27 May 96 12:24 EDT Received: by relay.tis.com; id MAA11601; Mon, 27 May 1996 12:26:20 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011597; Mon, 27 May 96 12:25:51 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04768; Mon, 27 May 96 12:25:59 EDT Received: by relay.tis.com; id MAA11594; Mon, 27 May 1996 12:25:50 -0400 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma011592; Mon, 27 May 96 12:25:26 -0400 Received: by interlock.ans.net id AA27397 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Mon, 27 May 1996 12:27:59 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 27 May 1996 12:27:59 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 May 1996 12:27:59 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 May 1996 12:27:59 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 May 1996 12:27:59 -0400 Date: Mon, 27 May 1996 12:27:13 -0400 X400-Originator: mleech@bcarh6dc.ott.bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<199605271627.AA144104433@bcarh6] X400-Content-Type: P2-1984 (2) Content-Identifier: IPSEC Key Man... From: "marcus (m.d.) leech" Message-Id: <199605271627.AA144104433@bcarh6dc.ott.bnr.ca> To: ipsec@ans.net Subject: IPSEC Key Management performance model Organization: Nortel Technologies, System Security Services X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1746 Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I'm growing increasingly concerned about the *potential* performance problems of PK-based key management in a large infrastructure like the Internet. Has anyone done any models, or is there any "real" data on the expected performance in performance-hungry situations like large servers with very large, dynamic client bases? How are existing SSL-based servers coping with large dynamic client bases (in which session-key caching doesn't do you very much good). Real-world numbers with large SSL servers can at least give us an approximation of the expected performance of IPSEC Key Management. If security association establishment takes 0.1 cpu-seconds, for example, then a server in which the arrival of new security association requests exceeds a handful per second will be completely unable to do its "real" work. Am I unduly pessimistic, or do "real-world" numbers with large SSL servers show that there's a potential problem? Is there a free lunch? Why does it always rain immediately after you've watered the lawn? If seven layers is the answer, what is the question? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBManX36p9EtiCAjydAQE78wIAsdOiP5MovTxuvc4SmV5VGK42qVRR5Yq7 D56RE9T39BE61Iuu11XXlOONSVsGAWQsz8JcqELeObEwTtq4J8B/bw== =65ox -----END PGP SIGNATURE----- -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 4C16, MS 238, CAR Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Systems Security Services Fax: (ESN) 393-7679 +1 613 763 7679 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ Received: from relay.tis.com by neptune.TIS.COM id aa18805; 27 May 96 16:09 EDT Received: by relay.tis.com; id QAA12611; Mon, 27 May 1996 16:11:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma012607; Mon, 27 May 96 16:10:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07021; Mon, 27 May 96 16:11:05 EDT Received: by relay.tis.com; id QAA12604; Mon, 27 May 1996 16:10:56 -0400 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1) id xma012602; Mon, 27 May 96 16:10:41 -0400 Received: by interlock.ans.net id AA00490 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Mon, 27 May 1996 16:13:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 May 1996 16:13:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 May 1996 16:13:10 -0400 Date: Mon, 27 May 1996 13:13:06 -0700 From: Hilarie Orman Message-Id: <9605272013.AA13565@uncial.CS.Arizona.EDU> To: mleech@nortel.ca Cc: ipsec@ans.net In-Reply-To: Yourmessage <199605271627.AA144104433@bcarh6dc.ott.bnr.ca> Subject: Re: IPSEC Key Management performance model Sender: ipsec-approval@neptune.tis.com Precedence: bulk I think that .1 CPU second is about right for a fast RISC machine to do a DH key exchange + PK mutual authentication. A server dealing with many new clients per second would need to throw on another CPU to handle the load. Such is the cost of security. Received: from relay.tis.com by neptune.TIS.COM id aa03806; 28 May 96 11:14 EDT Received: by relay.tis.com; id LAA22241; Tue, 28 May 1996 11:16:04 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022227; Tue, 28 May 96 11:15:45 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27938; Tue, 28 May 96 11:15:48 EDT Received: by relay.tis.com; id LAA22223; Tue, 28 May 1996 11:15:34 -0400 Received: from unknown(144.51.52.1) by relay.tis.com via smap (V3.1) id xma022219; Tue, 28 May 96 11:15:23 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA24568 for ; Tue, 28 May 1996 11:18:08 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma024564; Tue May 28 11:18:02 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA15871 for ; Tue, 28 May 1996 11:14:23 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA09790; Tue, 28 May 1996 11:17:55 -0400 Date: Tue, 28 May 1996 11:17:55 -0400 From: "David P. Kemp" Message-Id: <199605281517.LAA09790@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Date: Fri, 24 May 1996 16:26:53 -0400 > From: Craig Metz > > > I think a strong argument in favor of making both mandatory is simply > the desire to have at least two options available to the end user. > > [...] I don't know about you, but I want to have a backup available in > all cases that I can choose to use. Just in case. That would be a more convincing argument if you were a little more consistent about it. Back when there was just a vague feeling that the optional SHA was more secure than the mandatory MD5, you were absolutely *opposed* to making SHA mandatory, "just in case". Now that specific weaknesses have been demonstrated in MD5, and the working group has determined that SHA should be mandatory, your security philosophy has taken a remarkable turnaround. Is "choice" now a general design principle, or a special-case, politically-motivated, algorithm-specific position? For the record, I've previously stated my belief that MD5 should be optional; that opinion hasn't changed. Received: from relay.tis.com by neptune.TIS.COM id aa07008; 28 May 96 13:41 EDT Received: by relay.tis.com; id NAA04627; Tue, 28 May 1996 13:43:24 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004613; Tue, 28 May 96 13:42:56 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05771; Tue, 28 May 96 13:43:03 EDT Received: by relay.tis.com; id NAA04608; Tue, 28 May 1996 13:42:54 -0400 Received: from unknown(204.160.108.2) by relay.tis.com via smap (V3.1) id xma004598; Tue, 28 May 96 13:42:52 -0400 Received: from kennedy by enforcer.cylink.com with smtp (Smail3.1.29.1 #4) id m0uOSoZ-000zUWC; Tue, 28 May 96 10:44 PDT Message-Id: <31AB6574.7E04@cylink.com> Date: Tue, 28 May 1996 13:43:32 -0700 From: John Kennedy Organization: Cylink Corporation X-Mailer: Mozilla 2.01 (Win95; I; 16bit) Mime-Version: 1.0 To: uri@watson.ibm.com, touch@isi.edu Cc: ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria References: <9605260223.AA53605@hawpub.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Uri Blumenthal wrote: > > touch@isi.edu says: > > 2. On A Sun SPARC 20/71 in SunOS 4.1.3, I have measured: > > > > stand-alone MD5 60 Mbps +/- 3 Mbps > > stand-alone SHA 30 Mbps +/- 2 Mbps > > I have similar data (factor of 2) on Pentium under Linux-1.2.13. > -- > Regards, > Uri uri@watson.ibm.com > -=-=-=-=-=-=- > Someone else reported to me via private email that the difference in speed is basically a 5:4 ratio, due to the 80 rounds per 512-bit input block in SHA-1 vs. 64 rounds for MD5. I wonder why the empirical evidence doesn't seem to match. 99% of our work here at Cylink has been with SHA-1, so I can't offer performance times for SHA-1 and MD5 code of similar caliber. However, I will see if I can get a number for our production SHA-1 code on a Sun SPARC 20/71. Regards, -John jkennedy@cylink.com Received: from relay.tis.com by neptune.TIS.COM id aa08538; 28 May 96 14:42 EDT Received: by relay.tis.com; id OAA06502; Tue, 28 May 1996 14:44:15 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006482; Tue, 28 May 96 14:43:50 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08686; Tue, 28 May 96 14:43:54 EDT Received: by relay.tis.com; id OAA06475; Tue, 28 May 1996 14:43:45 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1) id xma006458; Tue, 28 May 96 14:43:22 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 28 May 1996 11:45:43 -0700 Date: Tue, 28 May 1996 11:45:37 -0700 Posted-Date: Tue, 28 May 1996 11:45:37 -0700 Message-Id: <199605281845.AA07593@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Tue, 28 May 1996 11:45:37 -0700 To: uri@watson.ibm.com, touch@isi.edu, jkennedy@cylink.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: Re: MD5 vs. SHA-1, Selection Criteria Cc: ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Date: Tue, 28 May 1996 13:43:32 -0700 > From: John Kennedy > Organization: Cylink Corporation > To: uri@watson.ibm.com, touch@ISI.EDU > Cc: ipsec@tis.com > Subject: Re: MD5 vs. SHA-1, Selection Criteria > > Uri Blumenthal wrote: > > > > touch@isi.edu says: > > > 2. On A Sun SPARC 20/71 in SunOS 4.1.3, I have measured: > > > > > > stand-alone MD5 60 Mbps +/- 3 Mbps > > > stand-alone SHA 30 Mbps +/- 2 Mbps > > > > Someone else reported to me via private email that the difference in > speed is basically a 5:4 ratio, due to the 80 rounds per 512-bit input > block in SHA-1 vs. 64 rounds for MD5. I wonder why the empirical > evidence doesn't seem to match. > Because rounds are only one measure. Also count the number of operations per round. SHA does more per round than MD5, i.e., MD5 SHA 32-bit adds 4 4 logical 2-3 2-4 (varies per step) rotates 1 2 total CPU 7-8 8-10 (15-20% higher, per round) mem reads 2 2 reg reads 4 5 reg writes 1 2 (others can be omitted via renaming) # rounds 64 80 (25% higher number of rounds). Overall CPU for SHA is 50% higher, and the register I/O is between 25-100% higher. The result, especially when considering the dataflow implications. I have not completed a detailed dataflow comparison, but it's easy to see why SHA is slower than MD5, even when neither is particularly optimized. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.tis.com by neptune.TIS.COM id aa29205; 29 May 96 12:20 EDT Received: by relay.tis.com; id MAA00739; Wed, 29 May 1996 12:21:46 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000728; Wed, 29 May 96 12:21:13 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22235; Wed, 29 May 96 12:21:20 EDT Received: by relay.tis.com; id MAA00725; Wed, 29 May 1996 12:21:11 -0400 Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1) id xma000716; Wed, 29 May 96 12:20:43 -0400 Received: from snail.rsa.com by RSA.COM with SMTP id AA25086; Wed, 29 May 96 09:20:29 PDT Received: from cc:Mail by snail.rsa.com id AA833387131; Wed, 29 May 96 09:24:43 PST Date: Wed, 29 May 96 09:24:43 PST From: baldwin Message-Id: <9604298333.AA833387131@snail.rsa.com> To: "Robert W. Baldwin" , ipsec@TIS.COM Subject: Re: MD5 vs. SHA-1, Performance & Pedigree Sender: ipsec-approval@neptune.tis.com Precedence: bulk For those interested in the pedigree of SHA1, you should know that Professor Rivest, the inventor of MD5, was also involved with the review/creation of SHA1. There are academic papers available that compare the two hash functions and make it clear that they have very similar design principles. SHA1 uses five rounds of an MD5 like round function to produce five 32 bit blocks, whereas MD5 uses four rounds to produce four 32 bit blocks. The new feature of SHA1 is an expansion step before the five rounds. It is a simple linear feedback shift register expansion that mixes all the bits of the input block. The difference between SHA0 and SHA1 is a change in the LSFR to ensure that each bit position in the expansion depends on each position of the input. For those who worry about weaknesses in MD5 please note that IPSec uses the HMAC transform not raw MD5. For those who think 128 bits is too small, then SHA1's 160 is a nice step up. For those who care about performance here are the numbers from the BSAFE 3.0 crypto toolkit on various platforms. The tests are run on very large input blocks. The speeds are in megabytes per second. Digest Performance in MegaBytes per Second Pentium P5 Power Mac SPARC 4 DEC Alpha 90 MHz 80 MHz 110 MHz 200 MHz MD5 13.1 3.1 5.1 8.5 SHA1 2.5 1.2 2.0 3.3 The number for the pentium is particularly high because extensive work was done to optimize the algorithm for the dual integer pipeline of the pentium. The rest are compiled from C code with speed optimization turned on. --Bob Baldwin RSA Data Security Inc. Received: from relay.tis.com by neptune.TIS.COM id aa29997; 29 May 96 13:13 EDT Received: by relay.tis.com; id NAA03093; Wed, 29 May 1996 13:15:21 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003080; Wed, 29 May 96 13:14:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24566; Wed, 29 May 96 13:15:02 EDT Received: by relay.tis.com; id NAA03071; Wed, 29 May 1996 13:14:54 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1) id xma003055; Wed, 29 May 96 13:14:45 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 29 May 1996 10:17:14 -0700 Date: Wed, 29 May 1996 10:17:08 -0700 Posted-Date: Wed, 29 May 1996 10:17:08 -0700 Message-Id: <199605291717.AA09044@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Wed, 29 May 1996 10:17:08 -0700 To: baldwin@rsa.com, ipsec@TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: Re: MD5 vs. SHA-1, Performance & Pedigree X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.tis.com Wed May 29 10:10:21 1996 > Date: Wed, 29 May 96 09:24:43 PST > From: baldwin > To: "Robert W. Baldwin" , ipsec@tis.com > Subject: Re: MD5 vs. SHA-1, Performance & Pedigree > > Digest Performance in MegaBytes per Second > > Pentium P5 Power Mac SPARC 4 DEC Alpha > 90 MHz 80 MHz 110 MHz 200 MHz > > MD5 13.1 3.1 5.1 8.5 > > SHA1 2.5 1.2 2.0 3.3 > > The number for the pentium is particularly high because > extensive work was done to optimize the algorithm for the > dual integer pipeline of the pentium. The rest are compiled > from C code with speed optimization turned on. NB: these numbers appear to be from stand-alone tests. Our measurements of in-situ IPv4 AH tests yield about half these rates at best (for large packets, about 4KB), and 1/100 these rates for either Ethernet-size (1.5 KB) or Internet-size packets (0.5KB). Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/