consensus on pgp? can we consolidate for action?

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

    two of the things I was trying to do in my rant "GET WITH
    IT" on the issues may not have been clear:

     1. as Tim says, let's make sure the OpenPGP standard (which
        in itself I did not address) is for PGP by itself, none
        of the peripheral issues or means of implementing
        GAK/CAK/CMR or the rest of the faloderol.  now, if PGP,
        under market pressure wishes to allow hooks for each of
        the sins from the necessary to the unpardonable GAK
        --that is a business decision.

     2. as far as the proposed SNMP "enforcer" --that is also a
        business consideration.  however, the more PGP is
        willing to listen to some of our voices of reason[1], 
        the more likely PGP is going to be in the rather 
        enviable position which at least permits companies to 
        make a choice.

            [1] by and large, despite the polarity of the
            arguments, this issue with PGP has been one of our
            memorably sane and polite debates with so many
            threads I may need to establish a separate text
            retrievable database!  and it involves one of our
            most emotional issues:  privacy.

    the second point is critical to our interests as well as for
    PGP's stand in the industry as a whole. if the SNMP enforcer 
    product is carefully designed, it can not only provide 
    warnings for each level of security but even more 
    importantly, it does not necessarily need to provide GAK
    functionally in the standard product:

        browsers use plugins --so why not security level 
        plugins for the "Bad Daddy" SNMP enforcer?

    essentially, the SNMP is a network connected, ie- 
    communication system, supervisor to one or more "clients"
    scattered anywhere in the network which recognizes Bad 
    Daddy. some of the PGP control functions are basic, but the
    rest should go on plugin, each relating to a different level
    of sin, forgivable to abominable.

    likewise, the local PGP crypto engine should be built around
    plugins. in this manner, anyone concerned with privacy can 
    easily check for the presence of the dirty little black 
    boxes, or hopefully PGP will display a panel of "features"
    (if you can ever call invasion of absolute privacy that).

    plugins today are a nobrainer.

    personally, I would not be willing to endorse a system which
    gives the SNMP Bad Daddy the ability to retrieve my secret
    keys and PGP should permit holding my secret keys on a flop
    of some type -in other words specify a separate location 
    for the secring which we can not do now unless we move the 
    rest of PGP environment (at least as far as I have read). 

    however, if I am stupid enough to put them in a network
    accessible position for the superuser to scarf -- that's my
    problem. for use on network machines, I have a c program 
    which is effectively a one time pad to make the ring 
    accessible for as short a time as possible. I was writing
    a c code supervisor which took care of this task rather 
    neatly with an out of place checksum passwd for the pad 
    keys but have been sidetracked.

    I think we have all pretty much agreed on the necessity of
    separate signature, communication, and storage keys; Adam
    Back convinced me rather quickly (I was using only a
    separate storage key). there is less agreement on the 
    effectiveness of GAKing the communications key since some
    form of DH session keys could be deployed and mail is
    transient; eg: GAK only serves the Fed in this case, which, 
    of course, is what they want.

    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, 

    I also agree with Adam's design on isolating the recovery 
    aspect from possible GAK outreach. although I will cop a
    plea to sometimes in the back and forth Adam was grasping
    for something which was never going to be there <g>

    bottom line: I think the consensus has already formed that
    PGP is not going to be the pristine voice crying in the 
    wilderness we all hoped to hear; now the issue is, how can
    we shape the product to have a) the most flexibility, 
    realizing full well there will be brain dead organizations
    who will insist on ordering GAK; and b) have the fewest
    potholes unknowingly enabling some level of pseudoGAK, etc.]
    again, that means focusing the pressure on PGP to keep the
    basic crypto engine pristine, and do the dirty work in Bad 
    Daddy --and use "visible" plugins.

    I can only presume PGP 5.5 is a fair ways down the pipe to
    delivery, complete with its Big Daddy SNMP enforcer; this 
    will make it all the harder to influence changes as PGP, Inc.
    appears to have grown enough in size to contain too many
    non-caring v/v real privacy (I have nothing to hide type 
    ignorance), and even more disappointing, not only technically
    ignorant, but distrustful of technology bureaucrats that 
    arrive with corporate growth -focused on 

        a)  closing off the design cycle; 
        b)  stifling the debate over methods; 
        c)  shipping product (oh, hell, we can listen to their
            complaints and make changes later...); and,
        d)  recover the vulture capital investors money.  

    if the foregoing is true, I hope PRZ has the good sense to
    take a walk, selling his stock (to do otherwise would be
    complicit in the deception of PGP's reputation capital).

    regardless of the above, if we as a group, with reasonable
    consensus, are willing to make an assault on the powers that
    be at PGP, Inc. including whatever relevant public publicity
    to heat the fire, there may be action.  hell, if we could 
    afford it (or Tim feels _real_ generous <g>), buy a NYTimes 
    page and all of us sign the "selling out our the constitution"
    with cute little graphics of children being tortured for 
    their keys.

    another point to consider:  if a majority of cypherpunks as
    a group are willing to "endorse" the pgp product, that may 
    be an issue worth discussing with pgp.  the only problem
    may be the level of the outside managers and bean counters
    which hold down the front offices, totally ignorant of 
    anything but feeelthy money; or, more probable, some cp
    subset who have been the primary contributors historically
    on these issues, and I think most of us know who the primary
    thinkers are on this issue are.  obviously we must be fully
    informed and our opinions assessed --even with divergences.
    in the end, I would like to think decisions could be settled
    by consensus, rather than Supreme Court style. <g>

    if we (and I say this as: "who's this we...")....

    despite the cynical contempt with which the mass media often
    displays to our attitudes, even resorting to name calling,
    reputation capital is not necessarily gained from main line
    press popularity, and certainly not from government
    "popularity" in this issue [particularly cogent to those of
    us "fortunate" to have received the IRS spam].  FWIW

    of course, I may be presumptuous PGP would even want to hear
    from us, let alone have any form of "Cypherpunks Inside" 
    (yuk) label on the box! particularly with the round robin 
    multi-teaming of the sleepless Jon Callas.

        this has been an attila rant...

        attila, out, one more time....

    and: it aint over 'til the fat lady sings, vahalla burning!

 "attila" sig: 1024/C20B6905/23D0 FA7F 6A8F 6066 BCAF AE56 98C0 D7B0 

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

iQCVAwUBNEXXkb04kQrCC2kFAQHD1wQAiAMt4qP+GX0SXpF9XSuWbJc38tBWFD+U
ErAn5iAhrWkzl1/HpkmxDb8qUS9fh1fTsUjTihTOCSU8RwvtkBuzkhMm02MXxxyK
eJndaYgdpt+pluGYfrDIj9Vd3QDQVlJ0gf+o+CQ+pwQUJxYjmI/oELb0jBDnOwek
EUl1MAszW90=
=EulT
-----END PGP SIGNATURE-----

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.
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

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)

-----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)

At 02:39 AM 10/18/1997 +0000, Attila T. Hun wrote:
>    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. 

Besides doing things at the SMTP, IPSEC, or SSL layers,
another approach is SSH.  You could build an application-specific
relay (e.g. something sitting on your machine receiving SMTP
and something sitting on your mailhost relaying it to sendmail),
but SSH does close enough to that that it may be the way to go,
except for occasional annoyances about who can use Port 25.

Also, there are two mail protocols to address - 
smtp for sending, but pop3 (or imap4) for mailbox-retrieval.
Using either SSH or IPSEC or something SSL-based
can help you cover the POP3 end as well.

On the other hand, you can also use Hotmail or a Hotmail clone
with SSL and bypass the whole process.  Or you can use a
PGP-equipped remailer.
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

On Sat, 18 Oct 1997, Bill Stewart wrote:
> 
> Also, there are two mail protocols to address - 
> smtp for sending, but pop3 (or imap4) for mailbox-retrieval.
> Using either SSH or IPSEC or something SSL-based
> can help you cover the POP3 end as well.

I encrypt both my SMTP and POP links using SafePassage Secure Tunnel.
128 bit SSL v3 with client certs. You can download a free eval copy of
SPST at http://www.c2.net/products/spst/ Without the certs, it shouldn't
take longer than 15 min. to set this up at your site.


Disclaimer: I work for C2.

-- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred. 
   "Tonga? Where the hell is Tonga? They have Cypherpunks there?"