Re: The future will be easy to use
At 9:26 AM 11/28/95, Perry E. Metzger wrote:
Jonathan Zamick writes:
I can't agree. The model of a successful enterprise includes feedback from different levels of participants.
This isn't an enterprise. The government is not a participant except by their own desire to interfere.
Regardless, the government will be taking a role in encryption.
What makes you say that? Besides, why would that be desirable on any level?
The Government will try to set standards and we will ignore them until they try to force them on us by law, period.
This discussion was based on a group of people getting together to create a new easy to use package for handling keys and such. The government is going to try to take a dominant stance, and mandate elements of it. That has to be assumed. Those elements we don't agree with will be ignored or worked around (depending if its government opinion or government law.) However, it is possible, even in an antagonistic relationship, to develop positive feedback. I may be cracked, but I'd like to think that it would be an advantage to find some area where the government and the Cypherpunk members do agree, to minimize the conflict over the areas where we don't. Still, this is getting past the original topic, and gets more into the religious level of whether there can be any cooperation when the two sides are Government and Good/Widespread Encryption. My stance is that currently, no, but that doesn't preclude it in the future. Others don't see it happening at all, or don't see it worth the investment to achieve. That is perfectly valid. --- Returning to the original topic though, do we want to get a smaller list together to spec out some ideas for the project that was discussed? A simple, transparent, tool which would allow people to use strong encryption without having to think about it? I don't have much time to contribute right now, but I can at least put together the list, and some ideas. Jonathan ------------------------------------------------------------------------ ..Jonathan Zamick Consensus Development Corporation.. ..<JonathanZ@consensus.com> 1563 Solano Ave, #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. ..Mosaic/WWW Home Page: .. .. Consensus Home Page ..
On Tue, 28 Nov 1995, Jonathan Zamick wrote:
Returning to the original topic though, do we want to get a smaller list together to spec out some ideas for the project that was discussed? A simple, transparent, tool which would allow people to use strong encryption without having to think about it?
It should be worth noting that I hope to put out the next version of SSLeay in less that a week (I hope, depending on how many nights I don't sleep :-) and it should include a 'demo' CA application. It will probably only use simple text indexes and directorys for storage but I intend it to be able to generate CRL and process certificate requests. The only question is do I put in support to ouput the certificate using a netscape/verisign compatable format :-). If nothing else, this should be a good starting point for adding a nice GUI front end and a real database backend. The application will be mostly a front-end to the SSLeay library so if I finish most of my documentation by then, others should be able to write a real CA application. eric -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups than the message contents :-)
Jonathan Zamick writes:
This discussion was based on a group of people getting together to create a new easy to use package for handling keys and such. The government is going to try to take a dominant stance, and mandate elements of it.
So we can ignore tem. Big deal. They have no laws with which to enforce their desires.
However, it is possible, even in an antagonistic relationship, to develop positive feedback.
Who cares? An hour spent talking to an idiot from Washington is better spent writing good code unless there is a law pending in congress, in which case you are probably better off paying someone who knows what they are doing to do the talking for you.
Returning to the original topic though, do we want to get a smaller list together to spec out some ideas for the project that was discussed? A simple, transparent, tool which would allow people to use strong encryption without having to think about it?
You mean, like IPSEC/Photuris? I'll be running IPSEC (but sadly not Photuris, although I'll be trying to port Aggelos Keromytis' version at some point) on my laptop at the IETF meeting in Dallas (provided that I can buy a laptop in time.) There are three things we are currently missing in the architecture, IMHO. 1) We need a certificate system to replace X.509 and that plays nicely with distributed databases. 2) We need to implement the Eastlake/Kaufman method for embedding certificates in the DNS or something similar. 3) We need a good entity naming model. Given all those being implemented, sometime soon I can see people telnetting or ftping hither and thither without ever noticing or caring that their sessions are completely encrypted. We also have the following need: 4) A good MIME mailer (that looks like NeXT Mail or something like it) which has hooks for something MOSSlike that uses the same certificate infrastructure described in 1-3 above. 5) SHTTP capable browsers that also use 1-3 listed above. .pm
what about the Sun release announced today? --it is fully functional with DES and 3xDES, DH negotiation, etc. and is coded for either sun 4.1.3 or gcc compilers? Check out http://skip.incog.com. source to the SKIP key management and IP layer encryption package for SunOs 4.x. On Tue, 28 Nov 1995, Perry E. Metzger wrote:
Jonathan Zamick writes:
This discussion was based on a group of people getting together to create a new easy to use package for handling keys and such. The government is going to try to take a dominant stance, and mandate elements of it.
So we can ignore tem. Big deal. They have no laws with which to enforce their desires.
However, it is possible, even in an antagonistic relationship, to develop positive feedback.
Who cares? An hour spent talking to an idiot from Washington is better spent writing good code unless there is a law pending in congress, in which case you are probably better off paying someone who knows what they are doing to do the talking for you.
Returning to the original topic though, do we want to get a smaller list together to spec out some ideas for the project that was discussed? A simple, transparent, tool which would allow people to use strong encryption without having to think about it?
You mean, like IPSEC/Photuris? I'll be running IPSEC (but sadly not Photuris, although I'll be trying to port Aggelos Keromytis' version at some point) on my laptop at the IETF meeting in Dallas (provided that I can buy a laptop in time.)
There are three things we are currently missing in the architecture, IMHO.
1) We need a certificate system to replace X.509 and that plays nicely with distributed databases. 2) We need to implement the Eastlake/Kaufman method for embedding certificates in the DNS or something similar. 3) We need a good entity naming model.
Given all those being implemented, sometime soon I can see people telnetting or ftping hither and thither without ever noticing or caring that their sessions are completely encrypted.
We also have the following need:
4) A good MIME mailer (that looks like NeXT Mail or something like it) which has hooks for something MOSSlike that uses the same certificate infrastructure described in 1-3 above. 5) SHTTP capable browsers that also use 1-3 listed above.
.pm
attila writes:
what about the Sun release announced today? --it is fully functional with DES and 3xDES, DH negotiation, etc. and is coded for either sun 4.1.3 or gcc compilers? Check out http://skip.incog.com. source to the SKIP key management and IP layer encryption package for SunOs 4.x.
Ah, yes. The non-standard from Sun. It doesn't do D-H negotiation, by the way. It uses something I'd call inferior. Read the flames in ipsec and ipsec-dev for details. .pm
On Wed, 29 Nov 1995, Perry E. Metzger wrote:
attila writes:
what about the Sun release announced today? --it is fully functional with DES and 3xDES, DH negotiation, etc. and is coded for either sun 4.1.3 or gcc compilers? Check out http://skip.incog.com. source to the SKIP key management and IP layer encryption package for SunOs 4.x.
Ah, yes. The non-standard from Sun.
It doesn't do D-H negotiation, by the way. It uses something I'd call inferior. Read the flames in ipsec and ipsec-dev for details.
.pm
figures. I'll give ipsec and ipsec-dev a look. However, SUN does have the power to make something happen on the high-power workstations, and the fact they are making a portable package available in source code is farther than anyone else has gone. my experience over the last 15 years with Sun is that they do listen to outside "noise" and will move forward. I for one will be contacting my Catalyst rep and the software develop group; the time has passed when you could get Andy, Bill, or Scott on the squawker. I did complain to Scott about Catalyst changes --I did get a nice letter back, but I doubt it was authored by Scott. Andy resigned last year, and I have not heard from Bill for years. other than the inferior method v. DH, is there anything else missing; I will probably pull the code package of the developers' access machine before the week is out just to take a look.
attila writes:
figures. I'll give ipsec and ipsec-dev a look. However, SUN does have the power to make something happen on the high-power workstations, and the fact they are making a portable package available in source code is farther than anyone else has gone.
Unfortunately, an internetworking protocol used by only one vendor gets nowhere.
my experience over the last 15 years with Sun is that they do listen to outside "noise" and will move forward.
I doubt it. Ashar Aziz and company at Sun are pretty much ego-committed to SKIP. Their group might not have nearly as much justification for its existance without it. That probably makes them reluctant to go in the right direction.
other than the inferior method v. DH, is there anything else missing; I will probably pull the code package of the developers' access machine before the week is out just to take a look.
SKIP is really very alien from the direction most of IPSEC is taking. It sacrifices a lot of functionality for the perceived benefit of being able to send an encrypted packet to a host "without prior negotiation". Unfortunately, that benefit turns out to be a mirage because in any real network you would need to do a certificate lookup in order to actually decrypt the packet, at which point you've lost any advantage. SKIP requires all sorts of hooks into the ESP/AH packet formats which makes it essentially incompatbile with ESP/AH implementations. SKIP uses long term keys which could really hurt if they were compromised. SKIP doesn't do perfect forward secrecy. I could go on and on. Ashar keeps answering every criticism with "well, you COULD do X in SKIP if you just hung this kludge onto it, but of course we hope most people would never do that". I started with a lot for respect for the guys and lost most of it through time. Ah, well. Perry
OK, I have not seen it (like I said, I will get it) or read ipsec. However, despite the group ego, Sun _does_ listen and Sun does wish to be the leader. If the rest of ipsec group has a specific list, maybe it needs to presented higher up the pole. As fun as it might be to code it, you have enough on your plate with pgp alone. Sun's resources for a directed course are hard to beat; this is just another repeat of the first go around. SKIP obviously will not fly outside of Sun without industry support and if it has long term keys and can be compromised, it will be a tough row to how. time for a little pressure where it counts. the fact Sun released source indicates they are open enough to expect criticism. attila
participants (4)
-
attila -
Eric Young -
Jonathan Zamick -
Perry E. Metzger