From ipsec-request@ans.net Mon May 1 04:46:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26930 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 00:55:39 -0400 Received: by interlock.ans.net id AA25690 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 00:47:05 -0400 Message-Id: <199505010447.AA25690@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 00:47:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 00:47:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 00:47:05 -0400 To: Mark H Linehan/Watson/IBM Research Cc: ipsec Subject: Re: Comments on latest IPSP drafts In-Reply-To: Your message of "11 Apr 1995 12:58:15." <199504111659.AA38422@interlock.ans.net> Date: Mon, 01 May 1995 00:46:59 -0400 From: "Donald E. Eastlake 3rd" From: Mark H Linehan/Watson/IBM Research To: ipsec Cc: "Donald E. Eastlake 3rd" Mime-Version: 1.0 Content-Type: Text/Plain }Donald Eastlake commented ("|") on some of my original comments ("}"). I'd }like to respond: } }} }}- I suggest that there should be a discussion of the impact of IP }}fragmentation. In particular: (a) performance is affected since IP packets }}that already equal the MTU size will overflow with the addition of the AH or }}ESP data; (b) I think there should be an implementation note that the sender of }}an IPSP packet should make sure to put it through the fragmentation process, }}and the destination of an IPSP packet must reassemble it before processing the }}AH header or ESP payload. } }| I actually think that any mature encryption standard has to include }| compression. It's one of the clear superiorities of PGP over PEM. }| But }| I recognize that most people consider it some sort of patent quirmire. }| Still, I hope the next generation of transformations include }| compression. } }I agree that there needs to be an IP compression function. It could be }incorporated into an ESP transform, but it makes more sense as another payload }type. That way we could specify compression functions independently of }encryption functions and could easily compose combinations of the two. A payload type is obviously possible but seems like a lot of overhead to me. There certainly should be independence of compression and encryption. Some time ago I floated an incomplete draft that handled this by having one header bit which, in on, meant the data was compressed and you could look at the first byte of the "data" to figure out how to uncompress it. (You could have a small number of standard compression algorithms (hopefully very small for interoperability, like one) and a further escape value so people can play with whatever private compression algorithms they want.) General compression of packets is increasingly being handled by the link hardware. }}... }} }}- Page 12 of the architecture document and various other places require }}user-oriented keying. It's not at all clear what that means for (a) systems }}that don't have userids (e.g. Windows); (b) services that operate on behalf of }}multiple users (e.g. nfsd); (c) systems that forward data between interfaces. }}I think (c) is supposed to be excluded by the words "... traffic originating at }}that system," but those words are not repeated in the several places that }}require user-oriented keying. At the least, I think there should be some text }}discussing these issues. }} }}In general, the network layer does not logically have access to user-related }}information, and some implementations may find it difficult or impossible to }}fulfill this requirement. I suggest that IPSP should not (a) force }}implementations to violate the usual separation between network layers by }}requiring the IP layer to know the relationship between packets and users; and }}(b) should not rule out implementations that simply can't meet this }requirement. } }| Maybe the wording need to be cleared up and maybe there are }| dedicated }| systems where this doesn't apply but the ability to use different keys }| on different conversations is essential. In general, the IETF }| concentrates on the bits on the wire while giving freedom for }| different arrangements within "operating systems" and the like. }| "Levels" a la OSI may be a useful model in some cases but they }| should }| be an aid to design, not a straight jacket. Some conversations, like }| NTP or routing, may be host level and servered apropriately by host }| level keys. But IPSEC will not have done its job if it can't stop the }| endless stream of end to end interactive application level security }| protocols (telnet, ftp, etc., etc.). (Note: this remark does not }| apply for store and forward services such as Mail, DNS, and HTTP }| which }| can not be adequately served by a simple "connection" oriented }| security protocol.) It should be possible on multi-user systems for }| the keying to authenticate different users and processes, even if this }| is just done in some cases by letting an application do the work }| itself. } }| Seems to me that a "Windows" system should have separate keys for }| different services it might offer so that if host A had several }| logical connections up with Windows machine B, one for ftp, one }| for a }| telnet session, one for news transfer, etc., they would be separately }| keyed. } }| Really, as long as a system is set up so there can be different keys, }| they most of the complexity here is at the session keying level, not }| in the packet formats. } }I suggest that this is what the drafts should say. Not "user-oriented keying" }but "multiple SPI's (and hence multiple keys) between pairs of hosts". The }question of whether the keys are user-oriented should be left to }implementations and possibly to the key management protocol. Fine. I think the key management protocol has to address this to some extent. }}... }} }}- There has been a lot of discussion about whether the DES-CBC transport should }}be required. I respectfully submit that there is a set of organizations and }}individuals who MUST (in a much more significant sense of "MUST") obey U.S. }}(and other nation's) laws and who will require an engineering solution to }}provide exportable encryption. Either this engineering group can provide that }}solution or someone will have to define an IPSECbis and an IPv6bis. The risk }}is fragmentation of standards. Since the set of people affected by the export }}laws is large, I argue that this working group should address the issue. } }| There are also lots of people that need to communicate securely }| within }| the United States and lots of people outside the United States }| unaffected by the US export laws who need to communicate }| securely. If }| someone want to define an insecure procotol that is freely exportable }| from the US, they certainly can but I would recommend that anyone }| who }| wants to communicate securly not use such an insecure protocol. } }I believe in "truth in advertising": as long as a vendor (or a standards body) }makes clear the weaknesses in any particular product or standard, then the }people paying for the product or using the standard can make their own decision. I sort of agree but you need at least one standard protocol so people can talk to each other. }In the real world, security is not binary. There is no such thing as a "secure }system" versus an "insecure system." There are just degrees of security. Let }me give a real-world analogy: if I buy a lock for my bicycle, I can buy one }that can be broken with a pair of pliers. Or I can buy one that takes a }cutting torch to break it. But there is no lock that can't be broken for }sufficient money and time. Now the market needs both types of locks, since no }one will spend $100 for a lock for a $100 bicycle, but someone who paid $3000 }for a bicycle might well spend $100 for a lock. } }You might argue that ESP cannot be broken given the appropriate choice of }encryption algorithm. This may be true, but that just diverts any attacks to }other aspects of the protocol or the implementations. Just like an attacker }faced with a really good bicycle lock will switch his attention to the chain }used with the lock. } }I dislike the export rules as much as you, and I sure hope that (and will work }to see that) they change sooner rather than later. But meanwhile, there is a }real market for exportable IP security implementations. Either the IETF can }standardize it, or it can see other parties do so. In the latter case, IETF is }not fulfilling its proper role, in my opinion. You aren't going to get very far, in my opinion, on this political argument. You are certainly right that there are different strengths of algorithsm. One could have any number of categories but let my use (1) trivial, someone with experience can solve with paper and pencil, (2) weak, breakable in a reasonable time by typical personal computer, (3) medium, breakable in a reasonable time by resources of typical large organization (ie, a general purpose massively parallel processor or a large network of personal computers, (4) hard, breakable in a reasonable time by a national cryptographic agency like NSA that can afford special purpose hardware, etc., and (5) very hard, computationally infeasiable to break with current knowledge. I realize these are very vague but they are to give an idea. DES was in 4 but is quickly slipping into category 3. There are lots of factors involved but since the US government requires export licenses for all cyrpto exports and some other countries ban all exports, there isn't any crypto algorithm that you can guarantee can be moved across boarders. Given that, the IETF need to pick something, what category do you think it should choose from? Given how widespread and standardized DES is for so many things, it seems like a reasonable choice to me. Restrictions on DES have been getting weaker and weaker and quite possibly this will push the government into removing the last ones. You can currently usually export full DES in binary to almost any US company or subsidiary in almost any country. Anyone who tries to "standardize on exportable crypto" will end up with some junk somewhere between category 2 and 3 and I'd be happy to help write some nice freeware to crack their stuff. It's sure going to be true that any decent sized government that wants to can read their messages and the situation will probably be worse than that. If the best the Software Publishers Association could get in their secretly negotiated secret deal was 40 bits if the algorithm was kept secret, what could the IETF get in open neogotations for an open algorithm? What's the use in standardizing on something which, following your truth in advertising, would have to say: "By the way, in 2 or 3 years you neighbor's kid will be able to break this in a few hours with their desktop computer using the cyryptanaysis algorithms developed by so-and-so as published in RFC xxx" or the like? }| It }| would certainly be a bad idea for the IETF to endorse such an }| insecure }| protocol as providing people with security. In fact, my understanding }| of the current situtaion is that, while individual export approval is }| required, it is easy to get permission to export DES-CBC }| confidentiality from the US to any US company including any US }| subsidiary abroad unless it is in one of a few countries that are }| specially restricated. } }I've gone through the process of getting an export license. From my }experience, I believe that the export rules are not actually published by the }government. And they don't apply to non-US companies. And they apply }differently for banking versus non-banking companies. And they apply }differently for different countries, even non-embargoed countries. All in all, }they are a significant barrier to commercial exploitation of IPSEC. As in some other areas (see the "insider trading rules" of the SEC) the government tries hard not to be pinned down in this area for a number of reasons one of which is that the lack of clear rules gives the government lots of discrition to reward and punish companies/people. (Other reasons might be that the full rules would reveal too much about code breaking ability, etc.) Since there aren't any clear rules, any attempt too negotiate them will be hard and will lead to especially limited permissions. 40 bit keys have generally been allowed in export for 15 years. How much faster have computers become in 15 years? It's not the IETF's job to come to some secret accomodation with the US government or any other particular government or all governments put together. I think its job is the somewhat self-referential one of engineering protocols to implement the rough consensus shared vision of the Internet community. That includes the ability to send private messages, credit card numbers, etc., without substantial fear of eavesdropping. I consider that you do not share this vision but consider the job of the IETF to be to limit the Global Internet to whatever the US Government happens to want to let through its border filters acording to today's whim to be your loss. Since software can be written in any country to meet open standards, such as those set by the IETF, I believe, as does the IAB and IESG as far as I can tell, that these stupid export rules should be substantially ignored in the standards process. }| People who want security need to use strong algorithms. I can't see }| why adopting a strong algorithm would cause anyone any difficult in }| secure communications. If they need the protocol implemented }| some }| place to which it can not be exported from the US, they will be }| trivially able to get it from elsewhere. } }People want different degrees of security depending upon what it costs (in }performance as well as vendor price) and what they need to protect. Sure, but there are usually reasonable points that cover 80 to 90% and finding simple ways to do that and avoiding much greater complexity to try to cover 98%+ is something the IETF usually (though not always) does. I think DES qualifies that way. And there is an expense in having lots of different algoorithms. Everyone who is serious is going to implement DES (except maybe certain goverment agencies who want to use their own classified stronger algorithms). }U.S. vendors cannot sell products to international companies on the basis that }"we'll sell you the complete package in North America, but you're on your own }overseas." That's a complete non-starter. US vendors already lose sales due to these stupid export rules. If things get worse, they will squak louder and the probability of the rules being liberalized will go way up. (If in fact the international companies are US, I think they can sell them DES in almost all countries, after going thorugh the required paperwork.) }| All levels of the IETF has considered this problem and the strong }| consensus in the IPng working group, the IESG, the IETF plenary, }| etc., }| etc., has consistently been that the IETF standard should require }| strong security. } }I really wish I could agree with the IETF community on this point. I see the }arguments being made here. I just don't think they are realistic in the real }world. The real world is what we make it. Donald From ipsec-request@ans.net Mon May 1 10:27:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23038 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 10:27:58 -0400 Received: by interlock.ans.net id AA16577 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 10:19:23 -0400 Message-Id: <199505011419.AA16577@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Mon, 1 May 1995 10:19:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 1 May 1995 10:19:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 1 May 1995 10:19:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 10:19:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 10:19:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 10:19:23 -0400 To: "Donald E. Eastlake 3rd" Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 1 May 95 10:17:32 Subject: Re: Comments on latest IPSP drafts Mime-Version: 1.0 Content-Type: Text/Plain Donald Eastlake said: General compression of packets is increasingly being handled by the link hardware. Link-layer compression is useless when encryption is done at the network layer. The motivation for considering network-layer compression is to do the compression before the encryption. Otherwise, the compression function gets uncompressable input. I consider that you do not share this vision but consider the job of the IETF to be to limit the Global Internet to whatever the US Government happens to want to let through its border filters acording to today's whim to be your loss. This is not a fair representation of what I have been saying. I am not arguing that we should "... limit the Global Internet ..." and I am happy to see DES or other strong encryption as an optional part of the standard. I simply that making it a **required** part of the standard is ignoring a fact of the world that is real, whether we like it or not. I would prefer to standardize on two encryption transforms: one (relatively) weak and one strong. We should make the comparative strengths of these transforms clear in the standards, so that potential users can assess for themselves the tradeoffs among security, technology, and governmental constraints. Perhaps changing the IETF from an engineering to a political body is an effective way to proceed. I disagree. --------------------------------------------------------------------------------- Mark H. Linehan IBM T. J. Watson Research Center, Hawthorne, New York linehan@watson.ibm.com; LINEHAN at WATSON http://w3.watson.ibm.com/~linehan/home.html (inside IBM only) (914) 784-7860; 8-863-7860; fax (914) 784-7484 From ipsec-request@ans.net Mon May 1 14:56:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22016 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 11:13:20 -0400 Received: by interlock.ans.net id AA12673 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 10:57:05 -0400 Message-Id: <199505011457.AA12673@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 1 May 1995 10:57:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 10:57:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 10:57:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 10:57:05 -0400 To: Mark H Linehan/Watson/IBM Research Cc: ipsec Subject: Re: Comments on latest IPSP drafts In-Reply-To: Your message of "01 May 1995 10:17:32." <199505011419.AA16577@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 01 May 1995 10:56:46 -0400 From: "Perry E. Metzger" Mark H Linehan/Watson/IBM Research says: > Perhaps changing the IETF from an engineering to a political body is an > effective way to proceed. I disagree. And then says > This is not a fair representation of what I have been saying. I am > not arguing that we should "... limit the Global Internet ..." and I > am happy to see DESor other strong encryption as an optional part of > the standard. I simply that making it a **required** part of the > standard is ignoring a fact of the world that is real, whether we > like it or not. Sorry, but government regulations aren't an engineering problem, they are a political problem. They are not "real" the way that engineering problems are real -- they are something that exists at the whim of a government, unlike our systems, which have to obey the laws of physics and the problems of what we know how to do. We can't change the laws of physics, but the laws of government are subject to arbitrary revision. I and others have favored ignoring the regulations while standardizing precisely because we are an engineering body. We engineer the best system we can. If the politicians then decide that they don't want us to have the best, they get to go in front of their people and justify the fact that they want their people to be crippled. We will have our hands clean -- we will not have violated our sacred duty as engineers. I mean that last bit quite literally. Just as a doctor has a duty to do the best job he can, I believe that it is my duty as an engineer to always do the absolutely best job that I can. I feel that my personal honor would be violated by anything less. I refuse to support something crippled that gives people a false sense of security simply to satisfy politicians. The politicians have to be the ones to tell the users of my design that they can't import it or export it or whatever. The blood is then on their hands, not mine. Perry From ipsec-request@ans.net Mon May 1 15:36:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12933 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 11:48:45 -0400 Received: by interlock.ans.net id AA22344 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 11:36:18 -0400 Message-Id: <199505011536.AA22344@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 11:36:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 11:36:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 11:36:18 -0400 X-Mailer: exmh version 1.6 4/21/95 To: Mark H Linehan/Watson/IBM Research Cc: "Donald E. Eastlake 3rd" , ipsec Subject: Re: Comments on latest IPSP drafts In-Reply-To: linehan's message of 01 May 1995 10:17:32. <199505011419.AA16577@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 May 1995 11:36:10 -0400 From: Bill Sommerfeld I would prefer to standardize on two encryption transforms: one (relatively) weak and one strong. We should make the comparative strengths of these transforms clear in the standards, so that potential users can assess for themselves the tradeoffs among security, technology, and governmental constraints. Sounds good to me: let's standardize on single DES as the weak algorithm and triple DES as the strong one. :-) - Bill From ipsec-request@ans.net Mon May 1 18:50:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28775 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 14:04:58 -0400 Received: by interlock.ans.net id AA26513 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 13:57:27 -0400 Message-Id: <199505011757.AA26513@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 13:57:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 13:57:27 -0400 Date: 1 May 1995 13:50:05 -0500 From: "FreedmanJ" Return-Receipt-To: "FreedmanJ" Subject: RE: Comments on latest IPSP drafts To: "ipsec" X-Mailer: Mail*Link SMTP-MS 3.0.2 >- we will not have violated our sacred duty as engineers. >I mean that last bit quite literally. Just as a doctor has a duty to >do the best job he can, I believe that it is my duty as an engineer to >always do the absolutely best job that I can. I feel that my personal >honor would be violated by anything less. I refuse to support >something crippled that gives people a false sense of security simply >to satisfy politicians. The politicians have to be the ones to tell >the users of my design that they can't import it or export it or >whatever. The blood is then on their hands, not mine. Perry I am having a real hard time swallowing this. The IETF is a standards body whose duty is to develop high quality, implementable standards. Its members may be implementors but the IETF implements nothing. If the IETF chooses not to make DES a requirement and is up front about it then where is the "false sense of security" coming from. If you personally or your company feel strongly then you may implement the DES ESP and your hands can be as clean as you want. If the IETF so decrees that that the DES-CBC is a MUST, and if companies choose to build and sell an IPv6-like product without this (which will probably happen - if there is a demand for IPv6 -if not then who cares), then the IETF has just taken another step along the path to irrelevance Jerry Freedman From ipsec-request@ans.net Mon May 1 10:00:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28856 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 14:07:12 -0400 Received: by interlock.ans.net id AA64523 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 14:01:13 -0400 Message-Id: <199505011801.AA64523@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 14:01:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 14:01:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 14:01:13 -0400 Date: Mon, 1 May 95 14:00:00 EDT X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bill Sommerfeld From: shirey@mitre.org (Robert W. Shirey) Subject: Re: Comments on latest IPSP drafts Cc: ipsec At 11:36 AM 5/1/95, Bill Sommerfeld wrote: >Sounds good to me: let's standardize on single DES as the weak >algorithm and triple DES as the strong one. :-) > > - Bill Seriously, though, that is an excellent suggestion. From ipsec-request@ans.net Mon May 1 20:36:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17432 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 17:27:44 -0400 Received: by interlock.ans.net id AA13868 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 16:37:41 -0400 Message-Id: <199505012037.AA13868@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 16:37:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 16:37:41 -0400 Date: Mon, 1 May 1995 13:36:08 -0700 (PDT) From: Everett F Batey WA6CRE X-Sender: efb@slced1 To: FreedmanJ Cc: ipsec Subject: RE: Comments on latest IPSP drafts In-Reply-To: <199505011757.AA26513@interlock.ans.net> X-Phone: +1 805 982-7180 DSN: 551-7180 Pgr: +1 805 655-2017 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII NOT AN OFFICIAL US GOV EMPLOYER RESPONSE / OPINION .. I think I heard the majority opinion at the IETF IPv6 Review (try pretty nearly UNANIMOUS) at InterOP was on the same wavelength as Mr Freedman, below. If it is not secure for all .. it is not part of the work of a secure standards body for all. Did I say that so it was clear ? I hope the implication is obvious. /ev/ On 1 May 1995, FreedmanJ wrote: > >- we will not have violated our sacred duty as engineers. > > >I mean that last bit quite literally. Just as a doctor has a duty to > >do the best job he can, I believe that it is my duty as an engineer to > >always do the absolutely best job that I can. I feel that my personal > >honor would be violated by anything less. I refuse to support > >something crippled that gives people a false sense of security simply > >to satisfy politicians. The politicians have to be the ones to tell > >the users of my design that they can't import it or export it or > >whatever. The blood is then on their hands, not mine. > > Perry > > > I am having a real hard time swallowing this. The IETF is a standards body > whose duty is to develop high quality, implementable standards. Its members > may be implementors but the IETF implements nothing. If the IETF chooses not > to make DES a requirement and is up front about it then where is the "false > sense of security" coming from. If you personally or your company feel > strongly then you may implement the DES ESP and your hands can be as clean as > you want. If the IETF so decrees that that the DES-CBC is a MUST, and if > companies choose to build and sell an IPv6-like product without this (which > will probably happen - if there is a demand for IPv6 -if not then who cares), > then > the IETF has just taken another step along the path to irrelevance > > Jerry Freedman > + efb@suned1.nswses.Navy.MIL efb@gcpacix.cotdazr.org efb@uvsi.jpl.nasa.gov + + efb@nosc.mil efb@oxnardsd.org [EFB15] WA6CRE Gold Coast Sun Users + + The Genie is Out of the Bottle! :-) CANT Put it Back, Nor even Nuke It + + Opinions, MINE, NOT Uncle_s | WWW b-news innd postmaster XNTP3 DNS GNU + From ipsec-request@ans.net Mon May 1 21:25:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29523 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 17:31:26 -0400 Received: by interlock.ans.net id AA08785 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 17:25:52 -0400 Message-Id: <199505012125.AA08785@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 1 May 1995 17:25:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 1 May 1995 17:25:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 17:25:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 17:25:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 17:25:52 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: "FreedmanJ" Cc: "ipsec" , jis@mit.edu Subject: Re: Comments on latest IPSP drafts In-Reply-To: Your message of "01 May 1995 13:50:05 CDT." <199505011757.AA26513@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 01 May 1995 17:25:12 -0400 From: Amir Herzberg Jerry, You replied to Perry, ... > The IETF is a standards body > whose duty is to develop high quality, implementable standards. Its members > may be implementors but the IETF implements nothing. If the IETF chooses not > to make DES a requirement and is up front about it then where is the "false > sense of security" coming from. If you personally or your company feel > strongly then you may implement the DES ESP and your hands can be as clean as > you want. If the IETF so decrees that that the DES-CBC is a MUST, and if > companies choose to build and sell an IPv6-like product without this (which > will probably happen - if there is a demand for IPv6 -if not then who cares), > then > the IETF has just taken another step along the path to irrelevance I agree, and I believe that the IETF would be better served by having the ESP optional (requiring DES, and with AUTH as a MUST), or allowing weak DES for ESP. The issue was raised in the open security area meeting and voted on (OK, a `show of hand'). There were quite a few - maybe a third - but as Jeff Schiller put it, a `rough consensus' decided that DES and ESP MUST be implemented in IPv6. Jeff now takes this to the IESG, and I'm not sure we should continue to discuss this on this list. Maybe there is still value to let Jeff, or other IESG members, know how you feel. Best, Amir From ipsec-request@ans.net Mon May 1 14:19:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24195 (5.65c/IDA-1.4.4 for ); Mon, 1 May 1995 19:28:41 -0400 Received: by interlock.ans.net id AA75621 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 1 May 1995 19:20:48 -0400 Message-Id: <199505012320.AA75621@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 1 May 1995 19:20:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 1 May 1995 19:20:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 1 May 1995 19:20:48 -0400 Date: Mon, 1 May 1995 19:19:13 +0500 From: Theodore Ts'o To: Everett F Batey WA6CRE Cc: FreedmanJ , ipsec In-Reply-To: Everett F Batey WA6CRE's message of Mon, 1 May 1995 13:36:08 -0700 (PDT), <199505012037.AA13868@interlock.ans.net> Subject: Re: Comments on latest IPSP drafts Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2630 Date: Mon, 1 May 1995 13:36:08 -0700 (PDT) From: Everett F Batey WA6CRE I think I heard the majority opinion at the IETF IPv6 Review (try pretty nearly UNANIMOUS) at InterOP was on the same wavelength as Mr Freedman, below. If it is not secure for all .. it is not part of the work of a secure standards body for all. Did I say that so it was clear ? But it *can* be secure for all; it's just that U.S. companies won't be able to provide the security for European customers, that's all. People keep forgetting the the IETF is an international organization, and there *are* companies that are located outside of the bounds of the U.S. borders, who would be more than happy to supply products to customers who can't receive them from U.S. manufacturers due to U.S. export regulations. Seems to me that the argument is mostly being made by U.S. companies who are too lazy to do the necessary lobbying to protect their interests --- actually, it probably has nothing to do with being lazy. They just clearly believe that it would be easier to lobby the IETF to compromise on our standards than it is to lobby the government to do the right thing. That's a rational decision, assuming that they believe that it is easier to make the IETF cave in. However, I believe we need to design what is in the best interests of the Internet, and that should take priority over what might be in the best interests of some companies who happen to be located in the United States of America. Jeff Schiller took a poll during his security session at Interop, and the conensus there was apparently (I wasn't there) in favor of making encryption a requirement, no matter what the export regulations might say. I *was* there when Jeff took a similar poll at the Security Area Advisory Group, and then at the IESG open meeting, and at the IESG open meeting, it was fairly clear that the overwhelming majority, even more so than at the SAAG meeting, favored requiring encryption, although there was a significant (and vocal) minority who believed otherwise. - Ted P.S. At least at one point, it was illegal to export any device the could do dynamic routing --- on the theory that it could be used by an enemy (read: Iraq) to make it more difficult for U.S. forces to deny them their command and control ability by bombing out communications links. Hence, any sort of device which could do dynamic network routing was on the controlled munitions list. Does that mean that the IETF therefore shouldn't have done any standards works on the Router Requirements RFC while that was true?!? From ipsec-request@ans.net Tue May 2 16:49:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16835 (5.65c/IDA-1.4.4 for ); Tue, 2 May 1995 13:08:30 -0400 Received: by interlock.ans.net id AA55368 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 2 May 1995 12:51:11 -0400 Message-Id: <199505021651.AA55368@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 2 May 1995 12:51:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 2 May 1995 12:51:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 2 May 1995 12:51:11 -0400 To: Mark H Linehan/Watson/IBM Research Cc: ipsec Subject: Re: Comments on latest IPSP drafts In-Reply-To: Your message of "01 May 1995 10:17:32." <199505011419.AA16577@interlock.ans.net> Date: Tue, 02 May 1995 12:49:23 -0400 From: "Donald E. Eastlake 3rd" Seems to me that what you are saying and what you are replying too are hard to distinguish below.. From: Mark H Linehan/Watson/IBM Research To: "Donald E. Eastlake 3rd" Cc: ipsec Mime-Version: 1.0 Content-Type: Text/Plain }Donald Eastlake said: } }General compression of packets is increasingly being handled by the link }hardware. I said the above. }Link-layer compression is useless when encryption is done at the network }layer. The motivation for considering network-layer compression is to do the }compression before the encryption. Otherwise, the compression function gets }uncompressable input. In reply to your response, my comment on link level compression was to indicate that a general payload type for compression was made less necessary by link encryption. Of course you can't compress after encrypting but if almost all the non-link level compression you wanted to do was in conjunction with encryption, why not do something like I had previously described and efficiently have a way of inidcationg compression algorithm in the ESP or whatever payload? }I consider that you do not share this vision but consider the job of }the IETF to be to limit the Global Internet to whatever the US }Government happens to want to let through its border filters acording to }today's whim to be your loss. I said the above. }This is not a fair representation of what I have been saying. I am not arguing }that we should "... limit the Global Internet ..." and I am happy to see DES or }other strong encryption as an optional part of the standard. I simply that }making it a **required** part of the standard is ignoring a fact of the world }that is real, whether we like it or not. I would prefer to standardize on two }encryption transforms: one (relatively) weak and one strong. We should make }the comparative strengths of these transforms clear in the standards, so that }potential users can assess for themselves the tradeoffs among security, }technology, and governmental constraints. Weak encryption you could get by the NSA with an open algorithm would be sufficiently useless that I see no reason for using it, let alone making it madatory. It sure is a real world fact that there are export restriction from the US but this is of absolutely no practical effect since people can write or get their software form elsewhere. Since the consensus is entirely on my side, this issue is not much of a fight at this point. But if it were not, I would fight for a network that matched a vision where privacy was a key principle. ... }--------------------------------------------------------------------------------- }Mark H. Linehan }IBM T. J. Watson Research Center, Hawthorne, New York }linehan@watson.ibm.com; LINEHAN at WATSON }http://w3.watson.ibm.com/~linehan/home.html (inside IBM only) }(914) 784-7860; 8-863-7860; fax (914) 784-7484 Donald From ipsec-request@ans.net Tue May 2 18:03:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21176 (5.65c/IDA-1.4.4 for ); Tue, 2 May 1995 15:08:03 -0400 Received: by interlock.ans.net id AA75992 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 2 May 1995 14:58:24 -0400 Message-Id: <199505021858.AA75992@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 2 May 1995 14:58:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 2 May 1995 14:58:24 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-cbc-encrypt-00.txt Date: Tue, 02 May 95 14:03:28 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : CBC Encryption Author(s) : P. Rogaway Filename : draft-ietf-ipsec-cbc-encrypt-00.txt Pages : 11 Date : 05/01/1995 A privacy transform is a pair of algorithms intended to support message privacy. This document defines the F-CBC transform for an arbitrary block cipher F. Three particular transforms are then singled out, including the DES-CBC transform. 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-cbc-encrypt-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-cbc-encrypt-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts 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-cbc-encrypt-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: <19950501160334.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-cbc-encrypt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-cbc-encrypt-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950501160334.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue May 2 19:29:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16655 (5.65c/IDA-1.4.4 for ); Tue, 2 May 1995 15:41:32 -0400 Received: by interlock.ans.net id AA71361 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 2 May 1995 15:31:50 -0400 Message-Id: <199505021931.AA71361@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 2 May 1995 15:31:50 -0400 From: Ran Atkinson Date: Tue, 2 May 1995 15:29:45 -0400 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: ADMINISTRATIVE: On Naming of Internet Drafts Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil IP Security WG Folks, People must not submit Internet drafts having a name prefix of "draft-ietf-ipsec-*" unless their draft is an official WG base document and this fact has been sorted out with both of the WG Chairs. Also, submissions having the prefix "draft-ietf-ipsec-*" must be made to the co-chairs email address at the same time (ie in the same message) as the email which submits the draft to the Internet Drafts folks at the IETF Secretariat. This is done so that official WG drafts are clearly distinguishable from individual/private/other contributions. Anyone may at any time make a submission of an Internet Draft having a filename of the form "draft--*.txt" as a personal comment or contribution. Consequently, the recent draft by Phil Rogaway and the earlier draft by Ashar Aziz will be deleted soon. Those individuals may resubmit their drafts as "draft-rogaway-*" or "draft-aziz-*" if they wish to do so. Thank you, Randall Atkinson Paul Lambert Co-Chairs, IP Security WG From ipsec-request@ans.net Tue May 2 19:32:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22115 (5.65c/IDA-1.4.4 for ); Tue, 2 May 1995 15:53:08 -0400 Received: by interlock.ans.net id AA21417 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 2 May 1995 15:42:36 -0400 Message-Id: <199505021942.AA21417@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 2 May 1995 15:42:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 2 May 1995 15:42:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 2 May 1995 15:42:36 -0400 Date: 2 May 1995 12:32:13 -0700 From: "Joe Tardo" Subject: Re: Comments on latest IPSP To: "Donald E. Eastlake 3rd" Cc: "ipsec" X-Mailer: Mail*Link SMTP-QM 3.0.2 Reply to: RE>>Comments on latest IPSP drafts Donald: You said: >Weak encryption you could get by the NSA with an open algorithm would >be sufficiently useless that I see no reason for using it, let alone >making it madatory. I agree, but am compelled to ask, do you not lock your car (which, I believe, presents a much greater inconvenience if compromised than the typical mail messages) because car locks can be easily defeated? Lofty principles are fine, I even have them, but holding out for perfection is one reason why interaction over the Internet is unprotected today. The other, of course, is that nobody wants to pay extra for it (much like auto security systems). OK, so flame me, but, having watched this business for 10 years, I'd hate to see IETF fail for the same reasons others have. If there's no "good enough, easy for vendors to build in for free" option, I'd expect to put my RFC's on the same shelf with SDNS. Joe From ipsec-request@ans.net Tue May 2 07:55:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16300 (5.65c/IDA-1.4.4 for ); Tue, 2 May 1995 18:08:00 -0400 Received: by interlock.ans.net id AA42038 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 2 May 1995 17:55:13 -0400 Message-Id: <199505022155.AA42038@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 2 May 1995 17:55:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 2 May 1995 17:55:13 -0400 Date: Tue, 2 May 95 14:55:05 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: ipsec@ans.net Subject: CBC encryption document Dear colleagues, Just posted is my (apparently misnamed) working draft draft-ietf-ipsec-cbc-encrypt-00.txt. This document constitutes a "counter-proposal" to draft-ietf-ipsec-esp-des-cbc-04.txt. Please understand that the former document is not a "peer" of the latter, in the sense that the former document functions at a decidedly lower level. It specifies ONLY a transform. This is quite intentional. (It is an implementation of Recommendation 5 of my April 3 comments.) Why should the lowest-level IPSEC documents describe ONLY a transform? (Here I mean "transform" in a technical sense: this is a certain particular pair of functions.) There are several reasons. One is thta it is virtually impossible for a cryptographer to assess (or change) the proposals' cryptography when it is intermixed with the use of that cryptography. As a consequence of maintaining a rigid abstraction boundary at the level of a transform, a transform-specifying document should be silent about things like the structure of an IP packet. This is the business of the higher-level document which uses a transform. Thus implicit in this CBC encryption document is the understanding that draft-ietf-ipsec-esp-01.txt be reworked to be truly generic, specifying how to use an arbitrary encryption transform to accomplish its job. Phil Rogaway From ipsec-request@ans.net Wed May 3 12:28:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12696 (5.65c/IDA-1.4.4 for ); Wed, 3 May 1995 08:43:45 -0400 Received: by interlock.ans.net id AA53907 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 3 May 1995 08:33:13 -0400 Message-Id: <199505031233.AA53907@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 3 May 1995 08:33:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 3 May 1995 08:33:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 3 May 1995 08:33:13 -0400 To: ipsec@ans.net Subject: Re: ADMINISTRATIVE: On Naming of Internet Drafts In-Reply-To: Your message of "Tue, 02 May 95 15:29:45 EDT." <199505021931.AA71361@interlock.ans.net> Date: Wed, 03 May 95 08:28:59 -0400 From: bound@zk3.dec.com X-Mts: smtp Phil/Ashir, I encourage you to submit your drafts as WGs drafts per accoradance with the rules. thanks /jim From ipsec-request@ans.net Tue May 2 20:42:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12808 (5.65c/IDA-1.4.4 for ); Wed, 3 May 1995 11:47:38 -0400 Received: by interlock.ans.net id AA15788 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 3 May 1995 11:40:07 -0400 Message-Id: <199505031540.AA15788@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 3 May 1995 11:40:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 3 May 1995 11:40:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 3 May 1995 11:40:07 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 3 May 1995 11:40:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 3 May 1995 11:40:07 -0400 Date: 2 May 95 15:42:00 -0500 To: dee@world.std.com, linehan@watson.ibm.com Cc: ipsec@ans.net Subject: Compression - was Re[2]: Comments on latest IPSP drafts Donald, > Of course you can't compress after >encrypting but if almost all the non-link level compression you wanted >to do was in conjunction with encryption, why not do something like I >had previously described and efficiently have a way of inidcationg >compression algorithm in the ESP or whatever payload? Why not create another Security Transform that first compresses and then encrypts outgoing traffic. All algorithms need to be negotiated (encryption, compression, integrity) so it would seem that comnpression becomes part of the transform selected in the establishment of the Security Association. Paul From ipsec-request@ans.net Wed May 3 16:15:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06878 (5.65c/IDA-1.4.4 for ); Wed, 3 May 1995 12:33:53 -0400 Received: by interlock.ans.net id AA62267 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 3 May 1995 12:19:48 -0400 Message-Id: <199505031619.AA62267@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 3 May 1995 12:19:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 3 May 1995 12:19:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 3 May 1995 12:19:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 3 May 1995 12:19:48 -0400 To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Compression - was Re[2]: Comments on latest IPSP drafts In-Reply-To: Your message of "02 May 1995 15:42:00 CDT." <199505031540.AA15788@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 03 May 1995 12:15:48 -0400 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > > Of course you can't compress after > >encrypting but if almost all the non-link level compression you wanted > >to do was in conjunction with encryption, why not do something like I > >had previously described and efficiently have a way of inidcationg > >compression algorithm in the ESP or whatever payload? > > Why not create another Security Transform that first compresses and > then encrypts outgoing traffic. All algorithms need to be > negotiated (encryption, compression, integrity) so it would seem > that comnpression becomes part of the transform selected in the > establishment of the Security Association. This indeed seems like the most reasonable course, at least to me. Perry From ipsec-request@ans.net Thu May 4 17:02:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16176 (5.65c/IDA-1.4.4 for ); Thu, 4 May 1995 13:19:56 -0400 Received: by interlock.ans.net id AA76345 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 4 May 1995 13:07:54 -0400 Message-Id: <199505041707.AA76345@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 4 May 1995 13:07:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 4 May 1995 13:07:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 4 May 1995 13:07:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 4 May 1995 13:07:54 -0400 X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 04 May 1995 13:02:50 -0400 To: perry@imsi.com, Paul_Lambert-P15452@email.mot.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Compression - was Re[2]: Comments on latest IPSP drafts Cc: ipsec@ans.net At 12:15 PM 5/3/95 -0400, Perry E. Metzger wrote: > >Paul_Lambert-P15452@email.mot.com says: >> > Of course you can't compress after >> >encrypting but if almost all the non-link level compression you wanted >> >to do was in conjunction with encryption, why not do something like I >> >had previously described and efficiently have a way of inidcationg >> >compression algorithm in the ESP or whatever payload? >> >> Why not create another Security Transform that first compresses and >> then encrypts outgoing traffic. All algorithms need to be >> negotiated (encryption, compression, integrity) so it would seem >> that comnpression becomes part of the transform selected in the >> establishment of the Security Association. > >This indeed seems like the most reasonable course, at least to >me. I read draft-ietf-pppext-compression-04.txt, draft-ietf-pppext-dce-compress-00.txt, and draft-ietf-pppext-bsd-compress-02.txt. It seems that there is much here that can be used directly. The bsd compress sounds best due to licensing issues, yes? I'd try my hand at cobbling something together, but I am overdue on 1597bis :( Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu May 4 11:19:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17433 (5.65c/IDA-1.4.4 for ); Thu, 4 May 1995 17:25:45 -0400 Received: by interlock.ans.net id AA14134 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 4 May 1995 17:20:40 -0400 Message-Id: <199505042120.AA14134@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 4 May 1995 17:20:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 4 May 1995 17:20:40 -0400 Date: Thu, 4 May 95 16:19:20 CDT From: stroh@VNET.IBM.COM To: ipsec@ans.net Subject: ipsec compression support >> Robert Moskowitz writes: >> >> I read draft-ietf-pppext-compression-04.txt, >> draft-ietf-pppext-dce-compress-00.txt, and >> draft-ietf-pppext-bsd-compress-02.txt. >> >> It seems that there is much here that can be used directly. The bsd >> compress sounds best due to licensing issues, yes? I'd try my hand at >> cobbling something together, but I am overdue on 1597bis :( >> >> Robert Moskowitz >> Chrysler Corporation >> (810) 758-8212 >> I am the lossless data compression algorithm architect for IBM Microelectronics Division (IMD), which provides IC hardware and software implementations of a family of algorithms called ALDC. My department also offers DES macros. I have been attending and following this group for over a year, waiting quietly while you cryptography experts mostly debate the technicalities of key management and algorithm strength, and rightly so. But I have been looking forward to the day when it is time to provide for data compression in IPSEC. Obviously encryption and compression are very closely related. As has been commented, the protocol issues with compression, such as requiring mech- anisms for keeping synchronized contexts, etc, are very similar to those for encryption, and that encryption will draw compression back from the WAN data links to the security boundaries, which in many cases should be the end user. Compression even makes the encryption slightly stronger. From the point of view of enabling IC technology, there is also a close relationship. For instance, our compression chips and macros run at 1 cycle/byte, up to 40-60 MByte/sec, performing exhaustive LZ77 compression, in lowcost devices on about 4 square mm of Silicon. We can put our DES macro in spare space on the chip and encrypt the compressed data at 32 cycles per 16 byte block. This averages half a byte per clock cycle, but since there is typically only about half as much data at the output of the compressor, it is still at 20,40.. MByte/s and up referred to the raw data stream. My purpose for being here is mainly to make sure you do not lock our algorithms out of a market (again) where we want to compete and we have a lot to offer. All I want is a reserved value for compression algorithm somewhere in the header, and if there is going to be a default compression algorithm, to compete for that designation. When the PPP algorithm selection was done we did not participate fully. I think it would be foolish for this group to simply adopt their algorithm selection, which was at a different point in time, with both its own politics and its own technical criteria. For instance an important issue to many vendors for PPP compression algorithm selection was availability and performance in software on a 68302 in mid 1994. The performance requirements on systems where security is needed, such as LANS, are orders of magnitude higher. This is not vaporware, Network Systems is already using IMD's compression hardware and software in their ip security implementation, which is a real product. Please don't argue key management and encryption algorithms for a year and decide the compression algorithm supported with less consideration and fairness than a coin flip. regards, Oscar Strohacker Advisory Engineer/Scientist Data Compression Systems Architecture IBM Microelectronics Division 11400 Burnet Road Austin Texas 78758 o (512) 838-4077 f (512) 838-7004 Internet: stroh @ vnet.ibm.com From ipsec-request@ans.net Thu May 4 20:20:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24692 (5.65c/IDA-1.4.4 for ); Thu, 4 May 1995 18:29:13 -0400 Received: by interlock.ans.net id AA22419 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 4 May 1995 18:20:59 -0400 Message-Id: <199505042220.AA22419@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 4 May 1995 18:20:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 4 May 1995 18:20:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 4 May 1995 18:20:59 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 4 May 1995 18:20:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 4 May 1995 18:20:59 -0400 Date: 4 May 95 15:20:00 -0500 To: stroh@VNET.IBM.COM, ipsec@ans.net Subject: Re: ipsec compression support Oscar, Glad to see you jump in to help out on compression. I have a small comment on your request. >>>>>>Oscar Strohacker >All I want is a reserved value for compression algorithm somewhere in the >header, and if there is going to be a default compression algorithm, to >compete for that designation. Ipsec currently does not have any "clear header" fields to describe the encryption, integrity, or compression algorithm. Our approach has been to bundle all of the negotiated attributes of the "security transform" into a single identifier (SPI or SAID) that determines the "security association" (SA). The use of compression with encryption needs to be defined as a new security transformation. These transformations are currently identified in the documentation as a arbitrary string of characters (e.g. DES-CBC-FOO). It might be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation. The working group will soon have to address in more detail the registration of these transforms for use in the IKMP negotiation process. This will likely yield a large space for new transformation so there will be plenty of room for LZ77. The more difficult issue is whether there should be a "recommended" compression algorithm. A rough first cut at the IPSEC requirements for compression are: The compression algorithm shall: 1) work effectively on IP packets. 2) work well combined with a selected encryption algorithm 3) not adversely decreases the "strength" of the selected encryption algorithm 5) be easily and effectively implemented in software. Software processing time should not be excessive. 5) be easily and effectively implemented in hardware to support high speeds 6) have well defined and accepted licensing terms It is not a requirement, but it also helps in the process to have openly available software implementations I assume that the IBM technology you are proposing must be patented. Has LZ77 been placed into the public domain? Are there well defined and acceptable licensing terms? Is there a publically available software implementation? Why is this algorithm better then others? What other algorithm should we consider? Does LZ77 provide any integrity checking (we might then only need to define DES- CBC-LZ77 instead of DES-CBC-MD5-LZ77)? Regards, Paul PS - I am out 5/7,8,9,10... From ipsec-request@ans.net Fri May 5 12:32:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24656 (5.65c/IDA-1.4.4 for ); Fri, 5 May 1995 08:57:58 -0400 Received: by interlock.ans.net id AA37485 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 5 May 1995 08:50:56 -0400 Message-Id: <199505051250.AA37485@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 5 May 1995 08:50:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 5 May 1995 08:50:56 -0400 Date: Fri, 5 May 95 12:32:44 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: ipsec compression support The next version of Photuris (this weekend) will have transform numbers allocated for compression. I will use the same option formats as we used for PPP. Compression is orthogonal to encryption and authentication. So, all three can be selected in the same message. You'll like it. Compression will not be required to be supported. We went through this with PPP. After a year and a half of testing and argument, we could not agree on a required protocol. We agreed on a negotiation mechanism. And then we've been blocked from publishing that mechanism (CCP) for another year and a half by a threatening letter to IETF from Motorola. I posted that problem to this list over a year ago. Motorola has patented Van Jacobson Header Compression (using addresses to select compression histories, and using any compression over unreliable links). These are bogus patents. So, Lambert, when are you going to handle the Motorola patent problem? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri May 5 19:01:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17402 (5.65c/IDA-1.4.4 for ); Fri, 5 May 1995 15:15:40 -0400 Received: by interlock.ans.net id AA24161 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 5 May 1995 15:01:39 -0400 Message-Id: <199505051901.AA24161@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 5 May 1995 15:01:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 5 May 1995 15:01:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 5 May 1995 15:01:39 -0400 To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: ipsec compression support In-Reply-To: Your message of "04 May 1995 15:20:00 EDT." <199505042220.AA22419@interlock.ans.net> Date: Fri, 05 May 1995 15:01:29 -0400 From: "Donald E. Eastlake 3rd" Paul, From: Paul_Lambert-P15452@email.mot.com To: stroh@VNET.IBM.COM, ipsec@ans.net } }Oscar, } } }Glad to see you jump in to help out on compression. } }I have a small comment on your request. } }>>>>>>Oscar Strohacker }>All I want is a reserved value for compression algorithm somewhere in the }>header, and if there is going to be a default compression algorithm, to }>compete for that designation. } }Ipsec currently does not have any "clear header" fields to describe the }encryption, integrity, or compression algorithm. Our approach has been to }bundle all of the negotiated attributes of the "security transform" into a }single identifier (SPI or SAID) that determines the "security association" (SA). } }The use of compression with encryption needs to be defined as a new security }transformation. These transformations are currently identified in the }documentation as a arbitrary string of characters (e.g. DES-CBC-FOO). It might }be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation. Nope, compression is of the clear data and is totally independent of any encryption that might follow. }The working group will soon have to address in more detail the registration of }these transforms for use in the IKMP negotiation process. This will likely }yield a large space for new transformation so there will be plenty of room for }LZ77. } }The more difficult issue is whether there should be a "recommended" compression }algorithm. A rough first cut at the IPSEC requirements for compression are: } }The compression algorithm shall: } }1) work effectively on IP packets. This is significant since many compression algorithms are optimized for long files. }2) work well combined with a selected encryption algorithm I can't see how any of the discussed encryption algorithms could fail to work well with any compression algorithm I know about. }3) not adversely decreases the "strength" of the selected encryption algorithm This would be really hard to do. Almost any compression algorithm will effectively strengthen almost any strong encryption algorithm in that the enemy at least has less cyphertext to play with. }5) be easily and effectively implemented in software. Software processing time } should not be excessive. } }5) be easily and effectively implemented in hardware to support high speeds 5(4)&5 are unlikley to be problems. }6) have well defined and accepted licensing terms } }It is not a requirement, but it also helps in the process to have openly }available software implementations If 6 is true, then publishing an implementation should not be too hard. }I assume that the IBM technology you are proposing must be patented. Has LZ77 }been placed into the public domain? Are there well defined and acceptable }licensing terms? Is there a publically available software implementation? Why }is this algorithm better then others? What other algorithm should we consider? }Does LZ77 provide any integrity checking (we might then only need to define DES- }CBC-LZ77 instead of DES-CBC-MD5-LZ77)? } }Regards, } }Paul } }PS - I am out 5/7,8,9,10... Donald From ipsec-request@ans.net Fri May 5 10:25:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24675 (5.65c/IDA-1.4.4 for ); Fri, 5 May 1995 20:30:55 -0400 Received: by interlock.ans.net id AA10677 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 5 May 1995 20:25:19 -0400 Message-Id: <199505060025.AA10677@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 5 May 1995 20:25:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 5 May 1995 20:25:19 -0400 Date: Fri, 5 May 95 17:25:14 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: ipsec@ans.net Subject: compression, privacy, and authenticity transforms Paul writes: > The use of compression with encryption needs to be defined as a new security > transformation. These transformations are currently identified in the > documentation as a arbitrary string of characters (e.g. DES-CBC-FOO). It might > be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation. I don't quite agree. Encryption, authentication, and compression are mechanisms intended for three orthogonal purposes. When (i) the individual mechanisms are correct, (i) key-separation has been properly performed (for encryption and authentication), and (iii) the mechanisms are applied in the correct order, these mechanisms can not "interfere" with one another. So wouldn't it be better to treat all of these types of transforms completely separately -- i.e., no "composite" transforms? If we start supporting transforms like DES-CBC-MD5-LZ77, we're going to get a real explosion in the number of transforms we'd feel it useful to provide. We're also unlikely to "get right" these composite transforms. Better is to regard "DES-CBC-MD5-LZ77" as three different transforms: first an LZ77 Transform (used in the context of ); then a DES-CBC Transform (used in the context of an ESP); then an MD5-KXK Transform (for example) (used in the context of an AH). The only "integration" issue we would have to worry about is (key separation and) a statement in the architecture document explaining that you should not use a compression transform after an encryption transform, and you should not use an encryption transform after an authentication transform. Phil From ipsec-request@ans.net Fri May 5 16:53:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21049 (5.65c/IDA-1.4.4 for ); Fri, 5 May 1995 22:58:57 -0400 Received: by interlock.ans.net id AA09812 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 5 May 1995 22:54:43 -0400 Message-Id: <199505060254.AA09812@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 5 May 1995 22:54:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 5 May 1995 22:54:43 -0400 Date: Fri, 5 May 95 21:53:28 CDT From: stroh@VNET.IBM.COM To: ipsec@ans.net Subject: compression, responses to q's Paul, thanks for the instruction on the SAID. I promise to do my required reading before class next time. Here are some responses to your questions and the followups. They reflect only my personal opinion and not the policies or attitudes of IBM, etc. Also, I apologize if company references in this note are in breach of netiquette. I don't know how to talk about the issues meaningfully totally in the abstract. Background The abbreviation LZ77 refers to a class of algorithms set forth in a 1977 Limpel-Ziv paper in IEEE Transactions on Information Theory. The key concept is to use a "sliding window" of previously seen text as a dictionary, where (optimally) one conceptually "looks ahead" in the input, finds the longest string (sequence of bytes) matching it in the previously seen data, and encodes the input by indicating the starting point and length rather than literally. This type of algorithm is lossless, works on data of different kinds, and adapts to changing data. Several vendors have proprietary algorithms of the LZ77 type, including IBM, STAC, and Motorola Codex. The name of IBM's version is ALDC, or Adaptive Lossless Data Compression. The algorithm used in BSD Unix compress is a member of another family, based upon a later paper, called LZ78. The LZ78 class is somewhat more algorithmically complex, does not have as efficient an implementation in hardware, performs no better in software, and has the same kind of intellectual property law problems as the LZ77 class. Intellectual Property Issues and Licensing To the best of my knowledge when compression algorithm have been made part of a standard, it is the binary encoding formats that have been placed in the public domain. For instance ALDC is the Quarter Inch Tape Standard designated as QIC-154, STAC is QIC-122, etc. and only the binary encoding format definitions became public domain. Pseudocode is provided to illustrate the operation of the codec. PC "Demo disks" are available which perform the same data transformations. You have all you need technically to write your own codec. There are three good reasons I would not suggest it. #3, some of the state paths an LZ77 codec can go through are very long, and the boundary conditions very infrequent, so that it is rather difficult to be absolutely certain your code is correct, #2, our code is rather well optimized, and #1 the Top reason, patents have been granted for the best apparatus and algorithms used in hardware and software e.g. to search for the best string matches, to use a bit in the compressed data stream to indicate token type, etc. We do not own all of these patents. But we indemnify you, if you license our software or buy our hardware, from potential damages resulting from patent infringement claims. IBM is able to do that due not only to our own patents in the compression area but to preexisting cross license agreements with every major computer company which exist on account of our large portfolio including fundamental computer patents, and specific cross license agreements with companies which only do compression. In a nutshell, IBM paid, and still pays, heavily to be able to business in compression, and to be able to indemnify licensees of its algorithms. Listing patent numbers for you would not help. Patent protection begins when patents are applied for, not when they are granted. The patent office is years behind, and the filings in the field are voluminous. This leads to what has been called the submarine patent attack. Also, although patents or claims may have been mistakenly granted where there already exist conflicting patents or prior applications or where there was there was well known prior art which was not disclosed in the application, it takes tens of millions of dollars, years of time, and still it's a crapshoot to overturn one. So it is best to learn to live with them. Software Availability and Contract Terms IBM currently offers it ALDC software codecs in binary and source form (at our discretion) at no charge under an NDA or CEA for bona fide R & D of protocol and product development. We sell them under a software license agreement for integration into a product, i.e. if you are using the code under NDA you have to license it before the product is sold. For source code the agreements provide that the user will not functionally modify the algorithm, i.e. change the encoding format, but only make modifications for integration or packaging purposes. The software license fees are cheaper than for IDEA or RSA. Effectiveness in Conjunction with IP No problem. Anything with recent repeats of byte sequences in the data stream is compressible. Incompressible data can expand by one part in eight, worstcase. Thus the protocol should be able to indicate incompressible data and send it the data without compression. Pertaining to this point, Don Eastlake mentions the topic of how well a specific algorithm works on short messages. There are two issues: if the entire message is actually short ALDC does relatively well, as it is designed to ramp up to its asymptotic compression ratio limit rapidly. (The rapidity with which the asymptote is reached is very data dependent.) If the individual packets are just short segments of a long stream, as a rule you would prefer to compress the data before segmenting it, and decompress it after collecting it. ( I would think this would also be true for encryption and decryption.) However, if this is not possible to collect reasonable size buffers of data, you can use a codec which supports segmented compression. This means that it can flush its output, indicate an end of segment, and remember the context or "history" across the segment boundarys. Effectiveness in Conjunction with Encryption There would be two concerns: one that it would make it the output too easy to cryptanalyse, and the other (bearing on export restrictions) that it would make it too hard by reducing the redundancy in the data, making a system with ALDC and DES unexportable. As to the former, it is most unlikely that reducing the information theoretic redundancy of the payload would make an attack easier. As to the latter, after being called to talk to the NSA we have not been prohibited from offering a product internationally using ALDC followed by DES. Easily and Effectively Implemented in software I covered part of this question above in "Intellectual property and Licensing." ALDC software yields essentially the same speed and compression ratio as STAC or BSD. There are also some tuning tradeoffs available between compression ratio, speed, and memory usage in our software codecs. Decompression is several times as fast as compression, much moreso than with LZ78. The asymmetry is nice for such applications as storage and multicast communications systems, where you encode once, decode many times. Easily and effectively implemented in hardware Exceedingly effectively. To me, this is why LZ77 is golden: The concept looks rather brute force, and indeed for software the more intricate LZ78 class of algorithms superceded it for many years. About 13 years later, we ( and apparently some others ) discovered an elegant hardware embodiment which uses a CAM to perform progressive string matching in parallel, effectively removing what is the greatest computational bottleneck. And our search is exhaustive ( always returning the longest possible string match) which permits better compression ratios with the same history buffer length, in turn permitting smaller silicon implementations and ramping up to the maximum compresson ratio faster as mentioned above. Combined with careful pipelining of the encoder, etc, we get to one input byte per clock cycle with very few gate delays ( high speed clock ) using very little silicon area. One datum per cycle at very few gate delays, that's the speed of light for compression. Give me an order and I'll build a 500 MByte/sec version in GaAs. Integrity Checking As with decryption, the ALDC decoders need a reliable data stream. No forward error correction, etc is provided by ALDC, because the additional redundancy required would reduce compression, and the tradeoffs to be made would be highly application specific. However, in particular, our hardware and software codecs can check for and avoid input buffer underrun and output buffer overflow which could result from being provided with corrupted input data. regards, Oscar Strohacker Advisory Engineer/Scientist Data Compression Systems Architecture IBM Microelectronics Division 11400 Burnet Road Austin Texas 78758 o (512) 838-4077 f (512) 838-7004 Internet: stroh @ vnet.ibm.com From ipsec-request@ans.net Fri May 5 19:24:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04339 (5.65c/IDA-1.4.4 for ); Sat, 6 May 1995 01:24:44 -0400 Received: by interlock.ans.net id AA76013 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 6 May 1995 01:20:28 -0400 Message-Id: <199505060520.AA76013@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 6 May 1995 01:20:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 6 May 1995 01:20:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 6 May 1995 01:20:28 -0400 To: "Joe Tardo" Cc: "ipsec" Subject: Re: Comments on latest IPSP In-Reply-To: Your message of "02 May 1995 12:32:13 EDT." <199505021942.AA21417@interlock.ans.net> Date: Fri, 05 May 1995 15:24:07 -0400 From: "Donald E. Eastlake 3rd" Joe, From: "Joe Tardo" To: "Donald E. Eastlake 3rd" Cc: "ipsec" X-Mailer: Mail*Link SMTP-QM 3.0.2 } Reply to: RE>>Comments on latest IPSP drafts } }Donald: } }You said: } }>Weak encryption you could get by the NSA with an open algorithm would }>be sufficiently useless that I see no reason for using it, let alone }>making it madatory. } }I agree, but am compelled to ask, do you not lock your car (which, I believe, }presents a much greater inconvenience if compromised than the typical }mail messages) because car locks can be easily defeated? Lofty principles }are fine, I even have them, but holding out for perfection is one reason why }interaction over the Internet is unprotected today. The other, of course, is }that nobody wants to pay extra for it (much like auto security systems). Well, Joe, I'm willing to admit that things a bit more complex than I have made out, due mostly to a desire on my part for brevity. In answer to the above, things really are different in differnt media. There are people who would spend days developing code breaking tools (which could then be almost infinitely replicated for almost no cost) who would not break my car's window and vice versa. Furthermore, I've very likely to know that someone has broken into my car or stolen it. If someon broke my master key, I might not know while they read *all* my mail, financial transactions, etc., for years or, in the future, be able to transfer all my funds out of all my bank accounts, etc. I'm certainly not holding out for "perfection", whatever that is. I'm calling for the one required standard interoperable crypto algoithm to be the most widely implemented most standard encyrption algorithm there is, namely DES. It is adequately strong for most things. I'd be pusing for DES-IDEA-DES or something if I wanted "perfection". }OK, so flame me, but, having watched this business for 10 years, I'd hate to }see IETF fail for the same reasons others have. If there's no "good enough, }easy for vendors to build in for free" option, I'd expect to put my RFC's on }the }same shelf with SDNS. But I think there more or less is. Essentially any vendor doing anything much with security has DES code. It's been freely ftp'able for years. There are many hardware implementations. It is good enough, in my opinion. IT WILL ONLY BE (imcrementally) FREE (to the customer) IF IT IS MANDATED. Even Jim Bounds, the strongest opponent of mandating DES I've even seen, said he was implementing it. I can't see just what social/deployment failure would be likely. I suppose most industrial governments could get together and ban encryption or mandate clipper but short of that export policies will make little difference. Vendors will implement DES domestically in enough countries that border barriers to export/import just won't matter. }Joe Donald From ipsec-request@ans.net Sat May 6 12:53:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23445 (5.65c/IDA-1.4.4 for ); Sat, 6 May 1995 08:05:34 -0400 Received: by interlock.ans.net id AA47119 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 6 May 1995 07:56:09 -0400 Message-Id: <199505061156.AA47119@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 6 May 1995 07:56:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 6 May 1995 07:56:09 -0400 X-Mailer: WordPerfect Office 4.0 Date: Sat, 6 May 1995 08:53:01 -0400 From: JAW@magna.telco.com To: ipsec@ans.net Subject: subscribe subscribe From ipsec-request@ans.net Sun May 7 22:32:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13040 (5.65c/IDA-1.4.4 for ); Sun, 7 May 1995 21:07:17 -0400 Received: by interlock.ans.net id AA42199 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 7 May 1995 21:00:13 -0400 Message-Id: <199505080100.AA42199@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 7 May 1995 21:00:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 7 May 1995 21:00:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 7 May 1995 21:00:13 -0400 Date: Sun, 7 May 1995 18:32:45 -0400 From: *Hobbit* To: ipsec@ans.net Subject: compression reality check Has anyone implemented ZIP in silicon yet? _H* From ipsec-request@ans.net Mon May 8 03:40:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20138 (5.65c/IDA-1.4.4 for ); Sun, 7 May 1995 23:39:42 -0400 Received: by interlock.ans.net id AA11840 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 7 May 1995 23:34:43 -0400 Message-Id: <199505080334.AA11840@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 7 May 1995 23:34:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 7 May 1995 23:34:43 -0400 X-Sender: hughes@129.191.63.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 7 May 1995 22:40:36 -0500 To: stroh@vnet.ibm.com, ipsec@ans.net From: hughes@hughes.network.com (James P Hughes) Subject: Re: compression, and other issues. I have been quiet, but here I go again. First, let me assure you that NSC will implement what the working group ends up with regardless. There are several issues that I would like to raise. First issue, patents. NSC is not offering patent protected stuff. We are a user of patents, not a provider of patented technology (at this time). In all the discussions, there seems to be only one side being argued. This side has many valid points. I am not disagreeing with anyone. Pleae do not Flame me about this. What I would like to add is two things reflecting on the successfull negotiation of 3 licenses (RSA, IBM's ALDC and Ascom's IDEA). Thing one, something that no one has brought up, when you buy a license you contractually get legal indemnification from patent claims. That is, if someone claims that NSC's compression product violates Stacker's compression patents, and, if the claims go back to the IBM code, IBM will be there to defend NSC (This is also true for RSA and IDEA). If we had gone around and decided to see if we can skirt around a patent (such as RSA's), this can open a whole can of worms, not only from RSA, but of all other holders of authenticaion patents. (NSC has experiance with the FDDI standard that was determined it violated a patent). Thing two, the price has been very reasonable. NSC still bought IBM's compression code even after we found out that STK (NSC's parent) already had cross lecene of the patents in question. We did this for the code itself. Compared to the price of the chips that go into the units we have now, the costs of these algorithms compare favorably. Second issue. Compression is indeed technologically orthoginal to encryption, but the placement of encrypting routers can be at the edge (baud rate choke point) of a network. From a customers perspective, this is a win. I wholely support adding compresion. The statement of compression adding another variant, compression should be a negotiated option of the standard encryption variant. Third issue. Replay prevenion. While NFS and TCP all provide some sort of sequencing, all UDP (and some IP?) applications do not. Not having replay prevention forces all application to provide some sort of replay prevention and thus the probelms with upgrading many application with security. NSC would like to see replay prevention as another option in the security transform. This is spendy in terms of size (4 to 8 bytes), but it is the customers shoice to see if they want it turned on. Fourth issue. Proprietary algorithms. For experimental reasons, performance reasons and even for political reasons, proprietary algorithms are needed. I do not want to (and will not answer flames on this subject) defend thi need, but to be agile to a changing technological env I think that the number of transforms reserved in photuris is too small. 256 combinations of encryption, compression, replay pervention, hashing, etc will run out especially if proprietary algorithms are required. Right now NSC needs 2 encryption and 1 authentication numbers. Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon May 8 10:38:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20032 (5.65c/IDA-1.4.4 for ); Mon, 8 May 1995 06:48:09 -0400 Received: by interlock.ans.net id AA54504 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 8 May 1995 06:38:35 -0400 Message-Id: <199505081038.AA54504@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 8 May 1995 06:38:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 8 May 1995 06:38:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 8 May 1995 06:38:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 8 May 1995 06:38:35 -0400 X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 08 May 1995 06:38:09 -0400 To: hughes@hughes.network.com (James P Hughes), stroh@vnet.ibm.com, ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: compression, and other issues. At 10:40 PM 5/7/95 -0500, James P Hughes wrote: > >Second issue. Compression is indeed technologically orthoginal to >encryption, but the placement of encrypting routers can be at the edge >(baud rate choke point) of a network. From a customers perspective, this is >a win. I wholely support adding compresion. The statement of compression >adding another variant, compression should be a negotiated option of the >standard encryption variant. For many of us, the compression will be needed in thousands of notebooks, in their TCP/IP stack. Software speeds, for now, should be able to keep up with 28.8 comm rates (128 for ISDN). So for companies like FTP/Software, Novell, and Microsoft (and NetManage, etc) the number of copies to license will be large... Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Mon May 8 21:39:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13026 (5.65c/IDA-1.4.4 for ); Mon, 8 May 1995 21:39:56 -0400 Received: by interlock.ans.net id AA22988 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 8 May 1995 21:32:08 -0400 Message-Id: <199505090132.AA22988@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 8 May 1995 21:32:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 8 May 1995 21:32:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 8 May 1995 21:32:08 -0400 Date: Mon, 08 May 95 18:07:00 From: "Housley, Russ" Encoding: 2375 Text To: ipsec@ans.net, rogaway@cs.ucdavis.edu (Phil Rogaway) Subject: Re: compression, privacy, and authenticity transforms Phil: I strongly disagree. We can take advantage of the properties of the encryption algorithm and mode to reduce the requirements on the complexity of the integrity mechanism iff the integrity check value is protected by the encryption. This also means that one key can be used to provide confidentiality and integrity. The reduced computation and reduced key management complexity make this type of combination very attractive. Russ ______________________________ Reply Separator _________________________________ Subject: compression, privacy, and authenticity transforms Author: rogaway@cs.ucdavis.edu (Phil Rogaway) at internet Date: 5/5/95 5:25 PM Paul writes: > The use of compression with encryption needs to be defined as a new security > transformation. These transformations are currently identified in the > documentation as a arbitrary string of characters (e.g. DES-CBC-FOO). It migh t > be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation. I don't quite agree. Encryption, authentication, and compression are mechanisms intended for three orthogonal purposes. When (i) the individual mechanisms are correct, (i) key-se paration has been properly performed (for encryption and authentication), and (iii) the mechanisms are applied in the correct order, these mechanisms can not "interfere" with one another. So wouldn't it be better to treat all of these types of trans forms completely separately -- i.e., no "composite" transforms? If we start supporting transforms like DES-CBC-MD5-LZ77, we're going to get a real explosion in the number of transforms we'd feel it useful to provide. We're also unlikely to "get right" these composite transforms. Better is to regard "DES-CBC-MD5-LZ77" a s three different transforms: first an LZ77 Transform (used in the context of ); then a DES-CBC Transform (used in the context of an ESP); then an MD5-KXK Transfo rm (for example) (used in the context of an AH). The only "integration" issue we would h ave to worry about is (key separation and) a statement in the architecture document explaining that you should not use a compression transform after an encryption transform, and you should not use an encryption transform after an authentication transform. Phil From ipsec-request@ans.net Mon May 8 22:10:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16343 (5.65c/IDA-1.4.4 for ); Mon, 8 May 1995 22:10:42 -0400 Received: by interlock.ans.net id AA21270 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 8 May 1995 22:03:22 -0400 Message-Id: <199505090203.AA21270@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 8 May 1995 22:03:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 8 May 1995 22:03:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 8 May 1995 22:03:22 -0400 Date: Mon, 08 May 95 18:31:44 From: "Housley, Russ" Encoding: 809 Text To: ipsec@ans.net, hughes@hughes.network.com (James P Hughes) Subject: Re[2]: compression, and other issues. Jim said: Fourth issue. Proprietary algorithms. For experimental reasons, performance reasons and even for political reasons, proprietary algorithms are needed. I do not want to (and will not answer flames on this subject) defend thi need, but to be agile to a changing technological env I think that the number of transforms reserved in photuris is too small. 256 combinations of encryption, compression, replay pervention, hashing, etc will run out especially if proprietary algorithms are required. Right now NSC needs 2 encryption and 1 authentication numbers. And, he is correct. If you consider that every Government on earth is likely to use its own confidentiality algorithm, we are already almost out of numbers.... Russ From ipsec-request@ans.net Tue May 9 05:47:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16263 (5.65c/IDA-1.4.4 for ); Tue, 9 May 1995 09:58:30 -0400 Received: by interlock.ans.net id AA35330 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 9 May 1995 09:49:35 -0400 Message-Id: <199505091349.AA35330@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 9 May 1995 09:49:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 9 May 1995 09:49:35 -0400 Date: Tue, 9 May 95 09:47:59 EDT From: hugo@watson.ibm.com To: housley@spyrus.com Cc: IPSEC@ans.net, ROGAWAY@CS.UCDAVIS.EDU, PAUL_LAMBERT-P15452@email.mot.com Subject: compression, privacy, and authenticity transforms Ref: Your note of Mon, 08 May 95 18:07:00 (attached) > > I strongly disagree. We can take advantage of the properties of the > encryption algorithm and mode to reduce the requirements on the complexity > of the integrity mechanism iff the integrity check value is protected by > the encryption. This also means that one key can be used to provide > confidentiality and integrity. > > The reduced computation and reduced key management complexity make this > type of combination very attractive. > > Russ > Russ, can you explain *exactly* how are you going to take advantage of the compression together with encryption in order to provide for *secure* integrity check? This issue of using key-less algorithms (CRC, non-cryptographic checksums, etc.) to provide integrity was extensively discussed in the past in this WG and fortunately abandoned due to the existing evidence that these schemes are insecure. This new (?) idea of using compression with encryption for that purpose is as unacceptable as the above ones. Hugo PS: For some examples on the vulnerabilities of the key-less approach, see mail by Colin Plumb to this list on Jan 16, 1995, and the papers by Jueneman, Matyas and Meyer, "Message Authentication", IEEE Comm. Magazine, Vol 23, No.9, 9/85, pp. 29-40, and the more recent by Stubblebine and Gligor in Oakland Conference, 1992. From ipsec-request@ans.net Tue May 9 01:26:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14679 (5.65c/IDA-1.4.4 for ); Tue, 9 May 1995 11:33:48 -0400 Received: by interlock.ans.net id AA42814 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 9 May 1995 11:27:10 -0400 Message-Id: <199505091527.AA42814@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 9 May 1995 11:27:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 9 May 1995 11:27:10 -0400 Date: Tue, 9 May 95 08:26:55 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: housley@spyrus.com, ipsec@ans.net, rogaway@cs.ucdavis.edu Subject: Re: compression, privacy, and authenticity transforms Hi, Russ. You write: > We can take advantage of the properties of the > encryption algorithm and mode to reduce the requirements on the complexity > of the integrity mechanism iff the integrity check value is protected by > the encryption. But I believe that every time a "more efficient" integrity-using-encryption mechanism has been suggested, it does not actually work. (As a well-known example, adding a simple Modification Detection Code (MDC) (like a CRC) in the scope of DES-CBC encrypted text won't somehow make "authenticated" the message.) > This also means that one key can be used to provide > confidentiality and integrity. You should not use the same *operational* key to encrypt and authenticate a message. If you do this, for many pairs of mechanisms, the encryption (resp., authentication) essentially invalidates the authentication (resp., encryption). Nonetheless ... > The reduced computation and reduced key management complexity make this > type of combination very attractive. There is no extra key management cost involved in doing the right thing. Only one key needs to be distributed. Each mechanism uses its own "key variant." Key variants are produced with no significant overhead. Phil From ipsec-request@ans.net Wed May 10 18:10:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24968 (5.65c/IDA-1.4.4 for ); Wed, 10 May 1995 14:22:37 -0400 Received: by interlock.ans.net id AA05727 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 10 May 1995 14:10:34 -0400 Message-Id: <199505101810.AA05727@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 10 May 1995 14:10:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 10 May 1995 14:10:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 10 May 1995 14:10:34 -0400 Date: Wed, 10 May 1995 11:10:27 -0700 From: Sean O'Malley To: ipsec@ans.net Subject: Peeking into TCP header Getting this news group back on the subject of security!. At the recent Hot OS conference there were at least two papers with proposals for supporting mobile computing by peaking into the transport (TCP) layer header at intermediate hosts to improve performance. Peeking into the TCP header has a long history but I had assumed that the addition of flow id to IP v6 would get rid of the problem. Unfortunately these new proposals look at the TCP sequence numbers in addition to the ports. Hence the flow IDs in IP v6 will not help. Since IPSEC and IP v6 security will be encrypting the TCP header if any encryption is performed this could be a problem. There are three possible approaches to this problem: 1. Tough luck. We are going to encrypt the transport headers and the Internet will have to live with it. This is a strong justification for coming up with some form of very cheap privacy, authentication, and key management scheme to use as the IPSEC default. In addition to what protection such weak security would offer against attackers it would provide absolute protection against protocol designers violating layering constraints. The longer we wait to encrypt transport headers the more difficult it will be to do. This is the x-kernel solution. If you want to put encryption at a higher layer... put encryption at a higher layer. You might want to make sure you definitions of encryption protocols can be inserted anywhere in the protocol graph (However because TCP does not preserve packet boundaries it is hard to get the same crypto-protocol to work both above TCP and below it). We have done this with our x-kernel security protocol library. Thus the action item here might be to form some kind of working group to standardize upper layer crypto. But it is a problem distinct from IPSEC. 2. support non-end-to-end encryption. We will encrypt TCP headers but some intermediate hosts will have access to the keys in order to decrypt enough of the packets to make decisions. This sounds insecure and will complicate key management especially where the intermediate host changes over time (as it will with mobile computing). It would also probably slow done packet processing at the intermediate host enough to make intermediate processing an untenable option. 3. Modify IPSEC to encrypt only part of the outgoing packet. This essentially allows IPSEC to pretend to be higher in the protocol suit then it actually is. Thus you could encrypt the data portion of the TCP packet without encrypting the header. This sounds intensely ugly. Given variable size headers the offset into the packet where encryption begins would have to be calculate on a per packet basis. However if the goal of IPSEC is to provide a single point for doing all network authentication (which I think some people believe it is) it is necessary. That is if you don't do this some applications will require encryption modules to be inserted in the protocol suite in the higher layers. For example above TCP or above Sun RPC. Sean O'Malley From ipsec-request@ans.net Fri May 12 15:42:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25997 (5.65c/IDA-1.4.4 for ); Fri, 12 May 1995 12:54:09 -0400 Received: by interlock.ans.net id AA30819 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 12 May 1995 12:43:56 -0400 Message-Id: <199505121643.AA30819@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 12 May 1995 12:43:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 12 May 1995 12:43:56 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-arch-02.txt Date: Fri, 12 May 95 11:42:14 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-02.txt Pages : 21 Date : 05/11/1995 This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. This document also describes key management requirements for systems implementing those security mechanisms. This document is not an overall Security Architecture for the Internet and is instead focused on IP-layer security. 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-arch-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-02.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: <19950511161827.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950511161827.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri May 12 18:47:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08081 (5.65c/IDA-1.4.4 for ); Fri, 12 May 1995 16:55:42 -0400 Received: by interlock.ans.net id AA55303 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 12 May 1995 16:50:22 -0400 Message-Id: <199505122050.AA55303@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 12 May 1995 16:50:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 12 May 1995 16:50:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 12 May 1995 16:50:22 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 12 May 1995 16:50:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 12 May 1995 16:50:22 -0400 Date: 12 May 95 13:47:00 -0500 To: dee@world.std.com Cc: ipsec@ans.net Subject: Re[2]: ipsec compression support Donald, Thanks for the comments. >Author: dee@world.std.com@INTERNET >Date: 5/5/95 2:01 PM >}Ipsec currently does not have any "clear header" fields to describe the >}encryption, integrity, or compression algorithm. Our approach has been to >}bundle all of the negotiated attributes of the "security transform" into a >}single identifier (SPI or SAID) that determines the "security association" >(SA). >} >}The use of compression with encryption needs to be defined as a new security >}transformation. These transformations are currently identified in the >}documentation as a arbitrary string of characters (e.g. DES-CBC-FOO). It might >}be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation. > >Nope, compression is of the clear data and is totally independent of >any encryption that might follow. > Yes, I believe I agree, but my point was that our current design approach does not place any "clear" bits in a header that indicate the type of processing. So for transmit processing (esp with compression, encryption): - determine the correct Security Association for source and destination - use SA to determine the Security Transform and keys to use (for example let's assume DES-CBC-LZ77) - compress the payload ("clear data") - encrypt - add header SPI/SAID (aka a "clear header") and IV fields - send it ... >}The working group will soon have to address in more detail the registration of >}these transforms for use in the IKMP negotiation process. This will likely >}yield a large space for new transformation so there will be plenty of room for >}LZ77. >} >}The more difficult issue is whether there should be a "recommended" compression >}algorithm. A rough first cut at the IPSEC requirements for compression are: >} >}The compression algorithm shall: >} >}1) work effectively on IP packets. > >This is significant since many compression algorithms are optimized >for long files. Yes. >}2) work well combined with a selected encryption algorithm > >I can't see how any of the discussed encryption algorithms could fail >to work well with any compression algorithm I know about. > >}3) not adversely decreases the "strength" of the selected encryption algorithm > >This would be really hard to do. Almost any compression algorithm will >effectively strengthen almost any strong encryption algorithm in that the >enemy at least has less cyphertext to play with. Ok, 2 and 3 above are not very good requirements. Our "good" security pratices already prescribe that the encryption mechanisms should be secure for know plaintext attacks. >}5) be easily and effectively implemented in software. Software processing time >} should not be excessive. >} >}5) be easily and effectively implemented in hardware to support high speeds > >5(4)&5 are unlikley to be problems. Maybe, but the IBM proposal did indicate the advantages of existing hardware. It is also possible to make some very computationaly difficult designs that we should try to avoid. These requirements (4 & 5) really should be criteria by which we compare the performance of proposals. >}6) have well defined and accepted licensing terms >} >}It is not a requirement, but it also helps in the process to have openly >}available software implementations > Paul PS - I will read mail next 5/24 From ipsec-request@ans.net Fri May 12 19:08:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26101 (5.65c/IDA-1.4.4 for ); Fri, 12 May 1995 17:22:19 -0400 Received: by interlock.ans.net id AA31872 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 12 May 1995 17:11:00 -0400 Message-Id: <199505122111.AA31872@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 12 May 1995 17:11:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 12 May 1995 17:11:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 12 May 1995 17:11:00 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 12 May 1995 17:11:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 12 May 1995 17:11:00 -0400 Date: 12 May 95 14:08:00 -0500 To: rogaway@cs.ucdavis.edu, ipsec@ans.net Subject: Re: compression, privacy, and authenticity transforms Phil, We seem to disagree, but have the same goals to: - limit the number of "Security Transforms" - ensure that combinations of security services are provided correctly I also have one additional requirement that you seem to not worry about: - limit the overhead required to provide a set of security services >Encryption, authentication, and compression are mechanisms intended for three >orthogonal purposes. When (i) the individual mechanisms are correct, (i) >key-separation >has been properly performed (for encryption and authentication), and (iii) the >mechanisms are applied in the correct order, these mechanisms can not >"interfere" with one another. So wouldn't it be better to treat all of >these types of transforms completely separately -- i.e., no "composite" >transforms? If we start supporting >transforms like DES-CBC-MD5-LZ77, we're going to get a real explosion in the >number of transforms we'd feel it useful to provide. I disagree! In general your approach of providing complete flexibility by creating "single service" security transformations is interesting, but if I need DES with authentication the system is burdened with the extra header overhead. This is obviously worse when you have three sets of headers for confidentiality, integrity (aka authentication), and compression. These service should be able to be combined in a manner that provides the services in a single transformation. The definition of the transformation will include the order of processing, the transform specific field locations, and so forth. Users need security and typically will not care how the theoretical pieces of the mechanisms are put together. Efficiency is important. Combining the processing and the construction of transform specific fields improves efficiency. We're also unlikely to >"get right" these composite transforms. Better is to regard "DES-CBC-MD5-LZ77" >as three different transforms: first an LZ77 Transform (used in the context of >);then a DES-CBC Transform (used in the context of an ESP); then an MD5- KXK >Transform (for example) (used in the context of an AH). Yes, we will get the transforms "right" by definition. They will be constructed with the processing defined in a specific order to provide specific services. An interesting example is the The only >"integration" issue we would have to worry about is (key separation >and) a statement in the architecture document >explaining that you should not use a compression transform after an encryption >transform, and you should not use an encryption transform after an >authentication >transform. There are times that encryption after an integrity (aka authentication) computation might be desirable. To define such broad rules limits the functionality of the system. It is better to precisely define a set of processing steps (transforms, fields, key usage, etc.) and document the expected services for the transformation. Paul PS - I might read mail again May 24 From ipsec-request@ans.net Mon May 15 13:03:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06897 (5.65c/IDA-1.4.4 for ); Mon, 15 May 1995 13:03:43 -0400 Received: by interlock.ans.net id AA21369 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 15 May 1995 12:50:35 -0400 Message-Id: <199505151650.AA21369@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 15 May 1995 12:50:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 15 May 1995 12:50:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 15 May 1995 12:50:35 -0400 Date: Mon, 15 May 95 09:12:24 From: "Housley, Russ" Encoding: 2458 Text To: hugo@watson.ibm.com Cc: IPSEC@ans.net Subject: Re: compression, privacy, and authenticity transforms Hugo: >> I strongly disagree. We can take advantage of the properties of the >> encryption algorithm and mode to reduce the requirements on the complexity >> of the integrity mechanism iff the integrity check value is protected by >> the encryption. This also means that one key can be used to provide >> confidentiality and integrity. >> >> The reduced computation and reduced key management complexity make this >> type of combination very attractive. > > Russ, can you explain *exactly* how are you going to take advantage of the > compression together with encryption in order to provide for *secure* > integrity check? > > This issue of using key-less algorithms (CRC, non-cryptographic checksums, > etc.) to provide integrity was extensively discussed in the past in this > WG and fortunately abandoned due to the existing evidence that these > schemes are insecure. This new (?) idea of using compression with > encryption for that purpose is as unacceptable as the above ones. Hugo, please reread my original message. I did not say anything about compression. Aside from that nit pick, I will demonstrate an example of a confidentiality mechanism and a keyless integrity mechanism being used together in a pairwise (not multicast) scenario. As pointed out by Colin, the CRC is not appropriate for this environemnt. However, another integrity check value (ICV) might be more compatible with DES CBC. I found an example where one's complement addition and a constant are used together. Before encryption, an ICV is appended to the data. The ICV is 64 bits long (and thus does not change the pad requirement). The first 32 bits are a checksum: the one's complement sum of all of the 32-bit words in the packet. The second 32 bits are all zero. Upon decryption, the recipient checks that the second 32 bits of the ICV are zero. If they are, then the checksum is computed. If the received checksum is the same as the computed checksum, then the ICV check passes. Unlike the MIT PCBC or Xerox CBCC, the technique discussed above adds a check value prior to encryption. I know that the MIT PCBC, Xerox CBCC, and DES with CRCs were shown to be insufficient, but I missed something if there is a problem with the technique discussed above. Clearly, a keyed ICV would be even stronger, but I am hoping to avoid the key management complexity of an additional key. Russ From ipsec-request@ans.net Mon May 15 09:51:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22177 (5.65c/IDA-1.4.4 for ); Mon, 15 May 1995 14:59:47 -0400 Received: by interlock.ans.net id AA31949 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 15 May 1995 14:54:13 -0400 Message-Id: <199505151854.AA31949@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 15 May 1995 14:54:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 15 May 1995 14:54:13 -0400 Date: Mon, 15 May 95 13:51:05 EDT From: hugo@watson.ibm.com To: housley@spyrus.com Cc: IPSEC@ans.net Subject: compression, privacy, and authenticity transforms Ref: Your note of Mon, 15 May 95 09:12:24 (attached) Russ, > Hugo, please reread my original message. I did not say anything about > compression. Aside from that nit pick, I will demonstrate an example of a I am sorry if I misread your message. The discussion was following Paul Labert's comments in the direction of taking advantage of compression together with encryption in order to provide integrity. So I was probably confused about your comments. In any case, to the main issue of key-less ICV's, the paper by Jueneman et al. that I referenced in my previous note shows weaknesses of these schemes in general. These attacks may appear as not the most realistic ones in the world but when you get to multi-user scenarios as described by Steve Bellovin they may become a real concern. A simple illustrative attack on appended key-less checksums (not described in that paper) is that I can produce a message M of the form M= M1|CS1|M2, where CS1 is the (keyless) checksum of M1. When M is transmitted then a CS2 checksum is appended to the whole message M and all of it encrypted. However, I can selectively choose to cut the message after CS1 and still be authenticated (CS1 needs to fall in the boundary of a CBC block). This attack is more useful against off-line authenticated information like files, rather that IP packets (which solve this attack by having the total length of the authenticated information PREpended). Still these weaknesses show that these mechanisms are not secure enough. (BTW, they are trivially breakable under stream cipher modes of encryption.) In some constrained situations one may think of using less secure mechanisms to gain in performance. I doubt this is critical here. As for key management, the cost of deriving an *additional* key is negligible, just an additional application of a pseudorandom function (based on DES, MD5, etc). Computation time of cryptographic checksums is more significant here since they usually take more time than a non-cryptographic checksum. In the current combination of DES and key-ed MD5 it is the time of DES which largely dominates the performance penalty while the effect of MD5 is secondary. Therefore, I see no justification to go to an insecure cehcksum. Hugo From ipsec-request@ans.net Mon May 15 05:49:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25252 (5.65c/IDA-1.4.4 for ); Mon, 15 May 1995 15:58:07 -0400 Received: by interlock.ans.net id AA43539 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 15 May 1995 15:49:37 -0400 Message-Id: <199505151949.AA43539@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 15 May 1995 15:49:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 15 May 1995 15:49:37 -0400 Date: Mon, 15 May 95 12:49:16 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: Paul_Lambert-P15452@email.mot.com Subject: Re: compression, privacy, and authenticity transforms Cc: ipsec@ans.net Hi, Paul, I think we can actually agree here. As you point out, there are (at least) three goals for supporting compression + privacy + authenticity: 1 - limit the number of "Security Transforms" 2 - ensure that combinations of security services are provided correctly 3 - limit the overhead required to provide a set of security services. Let me expand on 3: 3a - limit the added computational complexity 3b - limit the added communication complexity (= total # of bits) My earlier note claimed that (3a) is NOT better achieved by supporting "composite" transforms. (As a timely example, the suggestion just posted by Russ Housley is not correct.) But you are right to suggest that I didn't think much about (3b). Thus I wrongly concluded that it is just as well to wrap your packets with independent carriers for privacy, authenticity, and compression. You observe, correctly, that this would result in extra bytes of header -- overhead which we can avoid by having a single carrier with implicit instructions about what transforms to apply in what order. I find your approach perfectly acceptable (in fact, better than mine). Of course I'd say that one must implement this suggestion in a way that provides orthogonality in the transforms the user wishes to select (but it sounds like that was exactly your intent). I would like to make a minor suggestion on nomenclature: that we reserve the word "transform" to apply only to the "lower-level" meaning -- a function for privacy or authenticity or compression divorced of details of packet formats, etc. A Protected Packet Header (or whatever phrase you like) would specify what sequence of transforms to apply to its payload. Let's use a word different from "transform", like "encapsulation mapping", for the function you get by applying, in order, the specified sequence of transforms. Under the above approach I see no reason why we would maintain two distinct concepts (or documents) for ESP and AH: the encapsulation mapping would be computed in one packet type. A final comment: near the end of your note you say that there are times that an encryption computation after an integrity/authenticity computation might be desirable. Though I haven't seen such example, I have no reason to believe that one can't exist. So I too favor an approach in which the underlying transforms can be applied in an arbitrary order. The "customary" order should be made clear, and there should be a comment on possible problems which could result from deviating from this customary order. Regards, Phil From ipsec-request@ans.net Tue May 16 07:04:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06669 (5.65c/IDA-1.4.4 for ); Tue, 16 May 1995 03:22:09 -0400 Received: by interlock.ans.net id AA18467 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 16 May 1995 03:12:30 -0400 Message-Id: <199505160712.AA18467@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 16 May 1995 03:12:30 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 16 May 1995 03:12:30 -0400 Date: Tue, 16 May 1995 00:04:02 -0700 From: Phil Karn To: bound@zk3.dec.com Cc: hugo@watson.ibm.com, IPSEC@ans.net In-Reply-To: <9504060255.AA29605@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: fast re-keying >Can we have a well known port to send the ICMP Unreachable to regardless >of the key management used? Or will they all use different ports do you >think? In IP4 (don't know IPv6), ICMP Unreachables don't have "port" numbers. ICMP messages do include the IP header of the offending packet, plus 8 bytes of the transport header. This is sufficient in ESP for the original sender to identify the security association in question and to take appropriate action, such as possibly clearing the security association and creating a new one. The denial-of-service opportunities are apparent here, so this needs some more thought. Yet we need a way to clear out half-open security associations to recover from system crashes. Phil From ipsec-request@ans.net Thu May 18 20:11:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21225 (5.65c/IDA-1.4.4 for ); Thu, 18 May 1995 18:18:55 -0400 Received: by interlock.ans.net id AA53316 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 18 May 1995 18:09:56 -0400 Message-Id: <199505182209.AA53316@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 18 May 1995 18:09:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 18 May 1995 18:09:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 18 May 1995 18:09:56 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 18 May 1995 18:09:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 18 May 1995 18:09:56 -0400 Date: 18 May 95 15:11:00 -0500 To: hugo@watson.ibm.com, housley@spyrus.com Cc: ipsec@ans.net Subject: Re: compression, privacy, and authenticity transforms Hugo, >Author: hugo@watson.ibm.com@INTERNET >Date: 5/15/95 12:51 PM >In any case, to the main issue of key-less ICV's, the paper by Jueneman et >al. that I referenced in my previous note shows weaknesses of these schemes >in general. These attacks may appear as not the most realistic ones in the >world but when you get to multi-user scenarios as described by Steve Bellovin >they may become a real concern. I agree that they are not very realistic. > >A simple illustrative attack on appended key-less checksums (not described >in that paper) is that I can produce a >message M of the form M= M1|CS1|M2, where CS1 is the (keyless) checksum >of M1. When M is transmitted then a CS2 checksum is appended to the whole >message M and all of it encrypted. However, I can selectively choose to >cut the message after CS1 and still be authenticated (CS1 needs to fall >in the boundary of a CBC block). This attack is more useful against off-line >authenticated information like files, rather that IP packets (which >solve this attack by having the total length of the authenticated >information PREpended). Yes, these threats can be countered by including the length of the data! >Still these weaknesses show that these mechanisms >are not secure enough. (BTW, they are trivially breakable under >stream cipher modes of encryption.) Yes, key-less checksums under a stream cipher can be manipulated (not secure). No, one example of an attack does not imply that all use of key-less checksums is insecure. > >In some constrained situations one may think of using less secure mechanisms >to gain in performance. I doubt this is critical here. Performance is very important! >As for key management, the cost of deriving an *additional* key is negligible, >just an additional application of a pseudorandom function (based on DES, >MD5, etc). Computation time of cryptographic checksums is more significant >here since they usually take more time than a non-cryptographic checksum. Yes, but ... >In the current combination of DES and key-ed MD5 it is the time of DES >which largely dominates the performance penalty while the effect of MD5 is >secondary. Therefore, I see no justification to go to an insecure cehcksum. This is not correct for "high speed" implementations. When DES is implemented in hardware the software processing for the integrity processing has the greatest performance impact. This is a good reason to have a efficient integrity mechanism I am not proposing a particular new integrity mechanism at this time, but I do object to key-less ICV's being thrown out in total as a viable mechanism. > >Hugo Paul PS - I might be able to read mail again May 26. From ipsec-request@ans.net Thu May 18 17:45:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15598 (5.65c/IDA-1.4.4 for ); Thu, 18 May 1995 23:15:00 -0400 Received: by interlock.ans.net id AA19409 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 18 May 1995 21:49:42 -0400 Message-Id: <199505190149.AA19409@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 18 May 1995 21:49:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 18 May 1995 21:49:42 -0400 Date: Thu, 18 May 95 21:45:28 EDT From: hugo@watson.ibm.com To: Paul_Lambert-P15452@email.mot.com, housley@spyrus.com Cc: ipsec@ans.net Subject: compression, privacy, and authenticity transforms Ref: Your note of 18 May 95 15:11:00 -0500 >I am not proposing a particular new integrity mechanism at this time, but I do >object to key-less ICV's being thrown out in total as a viable mechanism. This is fine with me under the following interpretation: Whoever wants to register a key-less ICV to have it as an option, welcome. Whoever wants to propose such a mechanism as *default* transformation will need to provide evidence for the acceptable security of that mechanism. Hugo From ipsec-request@ans.net Wed May 24 11:20:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29328 (5.65c/IDA-1.4.4 for ); Wed, 24 May 1995 15:36:58 -0400 Received: by interlock.ans.net id AA67891 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 24 May 1995 15:24:26 -0400 Message-Id: <199505241924.AA67891@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 24 May 1995 15:24:26 -0400 To: ipsec@ans.net Subject: Stockholm Agenda Content-Length: 837 Date: Wed, 24 May 95 15:20:27 EDT From: Ran Atkinson Sender: rja@bodhi.cs.nrl.navy.mil Folks, Paul Lambert and I need to put together the Stockholm agenda very soon. People with proposed agenda items should email them to both of us. Proposals should include: short title short 1 paragraph synopsis of what is to be presented speaker time requested As there will only be one session in Stockholm, I believe time will be limited. Priority will be given to items that are directly on the workplan at this time. I have requested that the IPsec session be multicast but final decisions on which sessions will be multicast have not yet been made by the scheduling folks. Because so few people attended Amsterdam, we have only asked for a small meeting room in Stockholm. Thanks, Ran rja@cs.nrl.navy.mil PS: In case anyone has misplaced it, Paul Lambert's email address is: paul_lambert@email.mot.com From ipsec-request@ans.net Wed May 31 19:56:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15174 (5.65c/IDA-1.4.4 for ); Wed, 31 May 1995 16:57:27 -0400 Received: by interlock.ans.net id AA23115 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 31 May 1995 16:40:27 -0400 Message-Id: <199505312040.AA23115@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 31 May 1995 16:40:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 31 May 1995 16:40:27 -0400 Date: Wed, 31 May 1995 12:56:16 -0700 From: Phil Karn To: ipsec@ans.net Reply-To: karn@qualcomm.com Subject: Choice of strong primes for Photuris Colin Plumb, who did much of the modular exponentiation code for PGP, has recently developed a fast algorithm for the special case when the base is 2. This speeds up one part of Diffie-Hellman, the precomputation of the public component from the private component (but not the computation of the actual session key). The strong prime currently in the Photuris draft has generator 5. To accomodate Colin's work I'm going to change to another 1024-bit strong prime with a generator of 2. I'd already generated several strong primes with generators of 2, but not having any reason to prefer one over another I originally chose another one at random. As far as anyone knows, all these generator/prime pairs are equally secure, but of course if anyone has heard anything to the contrary I would like to know. Phil