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