Design proposal: crypto-capable generic interface

Hi to cypherpunks who write code,

   The recent discussion of "plug-in" crypto is reminding me of some
design work I did earlier this year. This post presents the motivation
and some of the details of that design, slightly updated.

   First, a few words about what I consider to be good interface that
can support plug-in crypto. It has to support both email and the Web;
I feel that everything else follows. It should support completely
transparent integration, by which I mean no extra clicking or commands
or anything like that. Finally, it should be generic in that it will
support a number of other plug-in applications besides
cryptography. Two specific applications which interest me are file
format conversions and external-body resolving.

   The design is based partly upon .mailcap, which is perhaps the best
example of a generic interface we have today. However, while .mailcap
is a nice interface for popping up windows to present semi-interesting
multimedia types, it certainly cannot support transparent
cryptography. I feel that its primary weakness is the inability to
support MIME to MIME rewriting. However, .mailcap has some good ideas
which are worth stealing.
   For the purposes of this proposal, I will assume that all objects
are MIME encapsulated. I think that's a reasonable assumption, as it
handily covers all cryptographic protocols that have any hope of
surviving.

   I will propose my design at a very high level. Please forgive me
for leaving out the juicy details.

   I propose that the new interface lives as a sort of daemon, rather
than a static collection of command line script pieces. A reasonable
way for applications to talk to the daemon would be Unix domain
sockets, or whatever the equivalent is on Mac and Windows
platforms. There should be a simple protocol for automatically
starting up a daemon if there isn't one already running.

   The first part of the interface is the negotiation. The daemon
tells the application what MIME types it can understand (this part is
very similar to the .mailcap file, but doesn't include the
corresponding command lines). In reply, the application tells the
daemon what MIME types it can understand (this is like the
Http-Accept: field in HTTP).

   Once the negotation has been established, the application can send
the daemon MIME objects that the app does not understand but the
daemon does (for example, an image/fractal). The daemon can return a
MIME object that the app does understand (for example, an image/ppm).

   Alternatively, the daemon may request an authentication. This is
useful when resolving external bodies that require authentication,
including non-anonymous FTP, and standard authenticated HTTP. In this
case, the daemon sends a message to the app requesting the
authentication. It specifies whether it needs both username and
password, or just password. In the latter case, it hands a username to
the application.
   The application can then query the user for the authentication
data. It hands this back to the daemon. In reply, the daemon indicates
success or failure. In case of success, it hands the object back to
the app.

   I'm quite pleased with this protocol as outlined. It's fairly
simple, which means it might actually get implemented. It's also easy
to see that it does exactly what you want for file format conversions,
external body resolving, and decryption of encrypted messages.

   Encryption is a bit more tricky, but in essence you just hang a
premail-alike off this kind of protocol. The hard part is specifying
the key, but you just call it a "parameter" and put in hooks for the
daemon to ask for whatever parameters it needs. This requires that
keys have some nonforgeable names, which is unfortunately not a
feature of PGP 2.6.2. S/MIME will do it just fine, if you buy into the
Certifcation Authority (<wink> at Nick Szabo).

   One final aside: I've been fairly frustrated with this mailing list
as a forum for talking about real design proposals and implementation
issues. Ignorant posts by the likes of Dr. Fred and Alice d'Clueless
tend to attract far more attention than real crypto work. I want a
forum for, and just for, cypherpunks who write code. If I had just a
smidgen more free time (as if), I'd be trying to start one
myself. Anyone else?

Raph

Raph Levien wrote:

|    I propose that the new interface lives as a sort of daemon, rather
| than a static collection of command line script pieces. A reasonable
| way for applications to talk to the daemon would be Unix domain
| sockets, or whatever the equivalent is on Mac and Windows
| platforms. There should be a simple protocol for automatically
| starting up a daemon if there isn't one already running.

	A daemon per user, or per machine?  Either way, I think you
run into problems on a big multi-user machine.  (Either its an extra
process or two per person, or its a great target for attack &
subversion.

	Its an interesting proposal, but let me ask you this--Why is
it better than a libpgp (or pgp.dll) that offers a variety of services
to programs at multiple levels (ie, offers full one call RSA/IDEA
encryption and compression, as well as ascii armoring, or offers each
of those as a seperate function.




-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

On Sat, 18 Nov 1995, Adam Shostack wrote:

> Raph Levien wrote:
> 
> |    I propose that the new interface lives as a sort of daemon, rather
	[snip]
> | 
> 
> 	A daemon per user, or per machine?  Either way, I think you
> run into problems on a big multi-user machine.  (Either its an extra
> process or two per person, or its a great target for attack &
> subversion.
> 
        _anything_ that has open access on a piece of hardware is a point
     of intrustion --sendmail for instance, or open password files, etc. 
     the issue is trading off risks to _maximize_ security and 
     impenatrable access.

        even assuming we were to post 100% of the source code, a
     translation daemon is a _translation_ model --even if it is capable
     of translating pgp, garbage in equals nothing out...

        one of the biggest problems with _any_ crypto system, and pgp is 
     no exception, is tmp files, followed closely by insecure memory.
     insecure memory is a separate issue, but some of the temporary file
     problems can be relegated to reduced risk by passing the daemon the
     user's preferred location for tmp file --for instance, on any net
     access machine, I globally specify TMP, TEMP, etc to a local tmp
     directory which is at least somewhat safer than public tmp files.
     obviously, you expect the daemon to wipe clean each memory block 
     before it free()s it --I's sure we all have routines handy for that.

        presuming the daemon is constructed so it can only respond to its
     current process owner, this leaves the security problem of swapping 
     in a daemon which also responds to an interloper --and this same risk
     applies to a libppg or a .dll file (more so to a .dll file) to an 
     even greater degree.  However, if a daemon is swapped, the system has
     a more _serious_ problem with the system administrator, not the
     daemon.

        if the IPC strings are intercepted in the daemon initializtion, 
     again we have a basic hardware and system security problem.

     Even If Ralph Levian believes daemons are serious risk problems 
     (which they can be if not properly implemented), I do not agree that 
     the libppg() or .dll offer anything additional.  I dont presume to 
     believe that anything is safe anyway, just safer than the alter-
     native.

        NB:  _nothing_ should ever be assumed secure! 

             assumption is fuckup's mother.  

        one must hope to have considered every possible line of attack, 
     and a few which have not been conceived, which goes back to our
     cypherpunk "credo" which says that private standards are not safe
     --let's all have at it --even if we break it, there probably is a way
     to block the attack, we just did not block it or consider it the
     first time,
     
        I have been playing with all three approaches, and I keep going 
     back to the daemon despite the fact it is not portable to the brain
     dead. 

             I don't know if W95 permits daemons as I have ignored MS
             for a number of years --if I can not run as many processes
             as I want without some MickeySoft program blowing away a
             day's work.... I prsume NT will run 'em, and maybe the 
             next release of NT will be more useable, more secure, and
             more stable.

        Since pgp() has been pulled from crypto10, I need to modularize 
     pgp to a pgp() and include the relevant goodies such as MIME and its 
     variations.  And, of course, we need all the "we do it here" types to
     buy into a standard interface.

        And, to add fuel:  the module needs the ability to encode and 
     place clear text into a MIME format specified by the calling program.

> 	Its an interesting proposal, but let me ask you this--Why is
> it better than a libpgp (or pgp.dll) that offers a variety of services
> to programs at multiple levels (ie, offers full one call RSA/IDEA
> encryption and compression, as well as ascii armoring, or offers each
> of those as a seperate function.
> 
	not necessarily better. but a valid approach IMHO.  I for one 
     think it would be easy enough to sell IAPs on a daemon.

> 
> 
> 
> -- 
> "It is seldom that liberty of any kind is lost all at once."
> 					               -Hume
>

atilla brings up many good points, including:
> one of the biggest problems with _any_ crypto system, and pgp is 
> no exception, is tmp files, followed closely by insecure memory.
> insecure memory is a separate issue, but some of the temporary file
> problems can be relegated to reduced risk by passing the daemon the
> user's preferred location for tmp file --for instance, [...]

   An even better solution is to design the cryptosystem so that it
doesn't _need_ temp files int he first place. MOSS wins, PGP loses. I
don't know enough about S/MIME to say.

   In a related vein, Darren New <dnew@sgf.fv.com> sent me a pointer
to First Virtual's SMXP (Simple Mime eXchange Protocol). This is a
cool protocol that does about 50% of what I'm talking about. If you're
interested, here it is:
      ftp://ftp.fv.com/pub/docs/smxp-spec.{ps,txt}

   In order to adapt SMXP into something that's useful for what I've
proposed, numerous changes would need to be made:

* Unix Domain Sockets instead of TCP

* Add negotiation

* Add authentication

   Without these three changes, the system is nearly useless for
crypto. Further, there are two "aesthetic" points I'd like to see
claned up given the chance. First, SMXP makes the "ASCII assumption."
Since the daemon and app will be tightly coupled, definitely running
on the same machine, there is no reason to exclude binary MIME
objects. On the other hand, as far as I know, all of the MIME crypto
protocols are ASCII based (somebody please correct me if S/MIME is the
exception).
   Second, in order to support operation without temp files, it's
necessary to interleave the operations of transferring the object from
the app to the daemon and vice versa. I have a proposal for a
lower-level spec which can handle this quite readily, if anyone is
interested.

   Unfortunately, the proposal doesn't look much like SMXP. However,
the possibility of creating a prototype based on SMXP is intriguing.

Raph

P.S. Did anyone see the mention of the perl/RSA CJR in the latest
Wired? Managed to get the attribution wrong. Still no response.

On Sat, 18 Nov 1995, Raph Levien wrote:

>    An even better solution is to design the cryptosystem so that it
> doesn't _need_ temp files int he first place. MOSS wins, PGP loses. I
MOSS?

s1113645@tesla.cc.uottawa.ca wrote:
> MOSS?

MIME Object Security Services. It's a technically superior alternative
to PGP, but one with an uncertain future. It's not being actively
developed by anyone other than TIS, and their TISMOSS prototype
implementation is far from being generally usable.

For more information on the standard, see RFC 1848:
      http://ds.internic.net/rfc/rfc1848.txt

For more information on the TIS effort, see:
      http://www.tis.com/docs/Research/moss.html

Raph

> MIME Object Security Services. It's a technically superior alternative
> to PGP, but one with an uncertain future. It's not being actively
> developed by anyone other than TIS, and their TISMOSS prototype
> implementation is far from being generally usable.

What do you mean by "technically superior"?  What technical merits
does MOSS have over PGP?  It does have a better protocol with which to
integrate it into mailers, but it is only a transmission protocol, not
a security mechanism change.  Worse, MOSS uses X.509, which requires a
lot of overhead for certificates.

On the other hand, the MIME-PGP protocol can provide the same
integration functionality as MOSS and still allow the use of the
simple PGP certification structure that already exists.

-derek

On Sun, 19 Nov 1995, Derek Atkins wrote:

> What do you mean by "technically superior"?  What technical merits
> does MOSS have over PGP?  It does have a better protocol with which to
> integrate it into mailers, but it is only a transmission protocol, not
> a security mechanism change.  Worse, MOSS uses X.509, which requires a
> lot of overhead for certificates.

Ah, I was hoping that my statement would stir some controversy. I've 
learned that well thought out, carefully reasoned posts never get any 
response.

I agree with you that the X.509 stuff is extra baggage in MOSS. 
Fortunately, the use of X.509 is optional.

MOSS has two very large advantages over PGP:

1. It can operate without temp files.

2. It has no non-MIME variant.

It will take forever for PGP/MIME to catch on. Thus, PGP will never 
really be a suitable candidate for my generic interface. Ah well.

> On the other hand, the MIME-PGP protocol can provide the same
> integration functionality as MOSS and still allow the use of the
> simple PGP certification structure that already exists.

This is true. I hope it happens.

> -derek
> 

Raph

Adam Shostack wrote:
> A daemon per user, or per machine? Either way, I think you
> run into problems on a big multi-user machine. (Either its an extra
> process or two per person, or its a great target for attack &
> subversion.

One per user. I'm thinking that, most of the time, the daemon process
would only last as long as the application.

It is certainly true that if there were to be one daemon per machine,
the security requirements would be a lot greater, as it would no
longer be possible to rely on the operating system to get the file
permissions right, etc. On the other hand, the daemon process better
be done right, or your're in trouble anyway.

> Its an interesting proposal, but let me ask you this--Why is
> it better than a libpgp (or pgp.dll) that offers a variety of services
> to programs at multiple levels (ie, offers full one call RSA/IDEA
> encryption and compression, as well as ascii armoring, or offers each
> of those as a seperate function.

   Exportability. There is a general feeling that a mailer program
with specific hooks to libpgp is going to have trouble with
exportablity (and forget about binaries), where a program that
supports a generic interface (the likes of .mailcap) is out of the
NSA's jurisdiction. Of course, this is speculation until we actually
get a ruling, but it sounds plausible enough to me to warrant spending
some time on design and implementation.

   Your question brings up another point: if the daemon process is
going to run as the personal slave of the application, then why not a
dynamic library instead? Two reasons. First, on Unix anyway,
interprocess communication through domain sockets is a more mature,
robust, and portable technology than dynamically linked libraries. On
Windows, it's probably the other way around, and that's worth thinking
about.
   The real reason is, though, that the daemon and application should
naturally be distrustful of each other's address spaces. Can you see
Netscape shipping code that links in a Joe Random dll? Conversely, do
you want your PGP secret data structures sharing an address space with
one of Netscape's beta releases? Using two processes in two address
spaces solves this problem.

   Jeff, if you're reading this, what do you think Netscape's chances
are for supporting such a protocol, assuming of course that there were
nicely implemented daemons, and that the protocol itself was going to
standards track? Is it something you'd be interested in?

Raph

On Sat, 18 Nov 1995, Adam Shostack wrote:

> 	A daemon per user, or per machine?  Either way, I think you
> run into problems on a big multi-user machine.  (Either its an extra
> process or two per person, or its a great target for attack &
> subversion.

	Not any more are target for attack than a shared library.

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01