From: "Attila T. Hun" <attila@hun.org>
Date: Sat, 18 Oct 1997 10:47:26 +0800
To: Jon Callas <jon@pgp.com>
Subject: Re: consensus on pgp? can we consolidate for action?
In-Reply-To: <19971016.032545.attila@hun.org>
Message-ID: <34482161.4AD6@hun.org>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

    alas, I must have been less than clear with the 
    statement "sendmail type" daemon.

    as Bill Stewart so aptly stated:

>   sendmail is such a wretched hive of
>   crime, corruption, and villainy that nobody in their right mind
>   really wants to mess with it. 

    is an abomination; in fact, about 1980/1 or such, I had a
    reason to carefully exam a few of the internals;
    subsequently, Eric Allman had good reason to be very
    circumspect where he crossed the street. <g> that
    and the rules set of the M4 macro processor --an even worse 
    abomination. speaking of Eric, I have not seen or heard for
    many years...?

    as Bill also pointed out, somethings could be done via the
    EHLO extensions, but the limitations would be to great.

    secondly, as Jon Callas points out, there is the option of
    TLS via SSL. however, that takes the wrapper off in a store 
    and forward situation and you can not control the hops.

    ** what I had in mind: **

    literally a point to point, port to port daemon pair 
    --operating in a trusted pair mode. 

    if store and forward was necessary, there would be a
    requirement for a dynamically maintained table similar
    to DNS, and a means of securing the data.  in order to
    implement store and forward, a web of trust would be
    essential, otherwise only point to point is feasible.

    in other words, a system similar in function to MixMaster
    except that it is fully end to end secure --well, as secure 
    as one can be using the IP carriers, SSL or not. 

    the are many nuances: for instance, provisions for key 
    lookup. 

    in all honesty, I have not been as concerned with all the 
    possibilities, just the design of and easily installable and
    maintainable daemon to satisfy the basic requirement, and 
    sufficient hooks to implement functionality without 
    compromising security.

    meanwhile, our hands are full with the PGP sell-out to the
    man, willing, or kicking and screaming, or even sold out by 
    the vultures and beancounters with an agenda: money. even 
    without presuming a current sellout, I suspect the whole
    affair was compromised from the gate --money talks, shit
    walks; and, there are many other unanswered questions, 
    some which I floated a year ago; regardless, someone is 
    schilling for uncle.

    in any event, all feedback is sincerely appreciated; none of
    us, weathered and scratched old grizzlies like me, or 
    cheetahs new to the veldt, have a corner on ideas. to 
    survive, the old just get meaner, and trade on their 
    experience. <g>

        attila


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be

iQCVAwUBNEggyL04kQrCC2kFAQGI0wP+JPI1v675+hdVRpXGr9dnI/XBqPHbPIMk
v4PA4eIqFEVbH2j5jWXsG9pEK1DrGdFwJl26DSeV7dgkQAqOWNUdsNML2w+L8tiw
Vr+VFGBznv+1BmxoyPskWAddTtXxqKO9i6kHbNcwE2nKBG1SoxLWF6uCZdQClwME
VS5RC3jRTTQ=
=uOdC
-----END PGP SIGNATURE-----

Jon Callas wrote:
> 
> At 01:18 AM 10/17/97 -0700, Bill Stewart wrote:
>    At 08:40 AM 10/16/1997 +0000, Attila T. Hun wrote:
>    >    I have not seen any further discussion on my suggestion to
>    >    create a sendmail type daemon which implements DH between
>    >    mail clients. this, of course, is on the presumption that DH
>    >    is a wrapper for an already encrypted packet,
> 
>    DH between mail clients and servers is a really fine idea if you're
>    starting from scratch, but sendmail is such a wretched hive of
>    crime, corruption, and villainy that nobody in their right mind
>    really wants to mess with it.  You could implement it as a sendmail
>    extension using the EHLO stuff, but you'd have to go get people
>    to adopt it widely once you'd done it; I suppose if you could talk
>    Netscape and Eudora into adding DH exchange to their client code
>    and get it into a few popular servers, you'd have a large fraction
>    of the Internet's email encrypted, which would be a Good Thing.
>    It'd still have some major traffic analysis issues,
>    and if you want to deal with the Man In The Middle problem,
>    you need a key distribution infrastructure, which is much harder.
> 
>    An alternative approach is to encrypt everything using IPSEC,
>    and you don't have to mess with Sendmail, but there are
>    performance issues, and there's a lot of work getting it deployed also.
> 
> There's another solution too -- make your mail servers talk with TLS
> (Transport Level Security, a.k.a. SSL).
> 
> This solves some problems and not others. If your SMTP path includes any
> hops, then the message is in plaintext on that machine. Complicating it
> further, you cannot reliably enforce what the hops will be.
> 
> This is one of the reasons that email keys are sometimes considered comm
> keys and sometimes storage keys.
> 
>         Jon
> 
> -----
> Jon Callas                                  jon@pgp.com
> Chief Scientist                             555 Twin Dolphin Drive
> Pretty Good Privacy, Inc.                   Suite 570
> (415) 596-1960                              Redwood Shores, CA 94065
> Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
>               665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)