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
participants (3)
-
futplexï¼ pseudonym.com -
Ray Cromwell -
sameer