getting netscape to support the remailers

I started thinking about what it would take to get Netscape to
support sending mail through the remailers, after having read the
S/MIME specs which Netscape 2.0 is apparently going to
support. Perhaps with enough browbeating Netscape 3.0 will support the
remailers.

	I think that in order to get netscape to support the remailers
the remailers will have to:

A) Support S/MIME
B) Have a documented protocol, MIME-related

	Did Ray Cromwell do some work towards MIMEifiying the
remailers? My impression of his work back when he posted was that it
trusted the remailers too much, but perhaps my memory is flawed-- in
any case his work may be helpful towards developing a remailer
standard, which could then help get support incorporated into
MIME agents.

	I will begin work on a preliminary specification, and post my
results. I figure MIME remailers would allow for:

1) Transparent reply-blocks
	Someone could have a multipart mime message where one of the
parts is Content-Type: reply-block and the MUA would see that and
understand to send replies with that reply block to the remailers.

	I will be posting more as I work out the details. I welcome
comments, suggestions, etc., as I figure that my initial specification
will require much improvement.

-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
An Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

sameer writes:
> 	I think that in order to get netscape to support the remailers
> the remailers will have to:
> 
> A) Support S/MIME
> B) Have a documented protocol, MIME-related
> 
> 	Did Ray Cromwell do some work towards MIMEifiying the
> remailers? My impression of his work back when he posted was that it
> trusted the remailers too much, but perhaps my memory is flawed-- in
> any case his work may be helpful towards developing a remailer
> standard, which could then help get support incorporated into
> MIME agents.

Here's something I sent to the list on July 24 which may be of interest:

---- begin included message ----

Perry Metzger writes:
>>> It would be very, very good if everyone doing secure mail systems of
>>> one sort or another (including PGP integrated mail packages and
>>> remailers) slowly moved forward to the formats described in this
>>> document, which is now a proposed internet standard...

The IESG writes:
> The IESG has approved the following two Internet-Drafts as Proposed
> Standards:
> 
> 1. MIME Object Security Services <draft-ietf-pem-mime-08.txt>
> 2. Security Multiparts for MIME: Multipart/Signed and
> Multipart/Encrypted
> <draft-ietf-pem-sigenc-03.txt>
> 
> These documents are the product of the Privacy-Enhanced Electronic Mail
> Working Group. The IESG contact person is Jeffrey Schiller.
> 
> 
> Technical Summary
> 
> These documents describe a general framework for security within MIME
> (draft-ietf-pem-sigenc-03.txt) and a specific proposal for offering
> Privacy Enhanced Mail services within MIME(draft-ietf-pem-mime-08.txt).
> Support is provided for digital signatures on MIME objects (both simple
> and compound) as well as for confidentiality provided through data
> encryption.

I've spent some time reading these proposed standards, along with parts of
RFCs 1423 and 1590, with an eye to applying them to remailers. I'd like to
get a sanity check and comments before I consider proceeding with submission
to the IETF Media Types review list, etc.

I propose a new Media Type subtype for Mixmaster remailer packets,
"application/mixmaster". (For the purposes of this message, "Mixmaster
remailer packet" refers to a packet generated by a Mixmaster server or client,
and intended for transmission to a Mixmaster server. It does *not* cover
messages generated by a Mixmaster server that are intended for an ultimate
message recipient.) This is intended to be an experimental protocol
for use in the control part of a multipart/encrypted message. 

There is one required parameter, "version", meant to indicate the version
number of the originating Mixmaster software. In addition, one optional
parameter, "key-id", may be included. If present, this parameter would
indicate the single line key prefix/ID of the public Mix key used to
encrypt (at the outermost layer) the contents of the application/mixmaster
part. This might be used to thoroughly disambiguate decryption options in
the event that the recipient server has more than one currently active
public Mix keys.

The application/mixmaster (control) part of the multipart/encrypted message 
would contain the padded list of Mixmaster server hop headers, superencrypted 
at the outermost layer with a public Mix key (presumably, one belonging to the
recipient server). A single decryption of these headers should reveal the
IDEA key used to superencrypt, at the outermost layer, the body part of the
multipart/encrypted message. The application/octet-stream (body) part of the
multipart/encrypted message would contain the list of ultimate recipients of
the remailed message, the text of the message itself, and any additional 
processing instructions to the final Mix server. The latter, body part of
the multipart/encrypted message shall have been encrypted by the originator
using the IDEA key specified in the former, control part.

The contents of the application/mixmaster part should be encoded in
accordance with the standards for application/octet-stream.

(NB: this amounts to a division of the extant Mixmaster packet format 
roughly into a control section and a body ("payload") section.)

Comments ?

-Futplex <futplex@pseudonym.com>

---- end included message ----

-Futplex <futplex@pseudonym.com>

> sameer writes:
> > 	I think that in order to get netscape to support the remailers
> > the remailers will have to:
> > 
> > A) Support S/MIME
> > B) Have a documented protocol, MIME-related
> > 
> > 	Did Ray Cromwell do some work towards MIMEifiying the
> > remailers? My impression of his work back when he posted was that it
> > trusted the remailers too much, but perhaps my memory is flawed-- in
> > any case his work may be helpful towards developing a remailer
> > standard, which could then help get support incorporated into
> > MIME agents.

  Yes, a while ago I was working on this, but I dropped it as people
didn't seem interested. It was part of my whole "Remailer 2.0" proposal
(before mixmaster was written)

  I was studying ways to make it easier for mail readers to interact with
remailers, in particular, messages which were split, padded, packetized,
and sent along separate chains. All this without some kind of special 
client. I wanted to use the multipart/partial part of MIME to have
the pieces combined at the recipient end and decoded using an
application/remailer or application/pgp type. (this was also
before PEM was worked on) So I had a lot of work to do in standardizing
stuff. I started working on a remailer which combined those facets,
and also

1) a remailer network which had strong authentication between remailers
so that untrusted remailers could not get in the network (web of trust
for remailers)
2) my virtual handle idea
3) strict addressing for virtual handles on the remailer network
(e.g. set up an explicit chain to anonymous bob by mailing to
remailer1#remailer2#....#remailerN#anonymous_bob. Also, if you add
a '*' in the path, it means for the remailer to choose a random
remailer as the next in the chain)
4) padding, packetizing, delayed delivery, creating artificial traffic to 
   thwart traffic analysis
5) a built in keyserver and "list of active remailers" server. 
   The list of active remailers server would also contain flags
   for each remailer detailing what it supports and special
   flags like if the machine is multiuser, single, firewalled, offline (UUCP 
   connection only), etc. I wanted as standard, that every remailer
   could serve keys or atleast tell you what other remailers were active
6) socket connection for commanding the remailer so that you can bypass
   sendmail logging and get error/status on the message
7) direct SMTP delivery bypassing local sendmail logging



I wanted to use multipart MIME to allow remailers in a network
to be run from user accounts in such a way that they wouldn't accidently get
mail intended for the remailer and they wouldn't have to bear
responsibility for the mail sent (only the whole machine would, as it would
be delivered via SMTP direct, not sendmail, so no local logs)

Nevertheless, like many things, I completed about 60% of it and it got
put on the back burner never to emerge. Mixmaster came along and I 
figured there's no point continuing.

 
-Ray