MUSE (Mail Ubiquitous Security Extensions) discussion starting

Don Eastlake has written an internet-draft proposing to add signatures and encryption to the Internet mail-delivery system. The two big differences between his proposal and past proposals are: * They work at the "sendmail" level, not at the "mail reader" level. This doesn't give your mail complete end-to-end protection (unless you use "mail reader" encryption like S/MIME or PGP). But it's a lot easier to install and maintain; your sysadmin can do it for your whole site, instead of having to retrain every user. * They use the Domain Name System to keep the keys. Since DNS is going to distribute keys for its own authentication, these can also be used to provide authenticated public keys for remote host machines, so that email destined for those machines can be encrypted. With existing systems, getting and validating keys is a big problem. I encourage cypherpunks to read his draft and to participate in the discussion and/or implementation that results. The general MUSE web page is at http://www.imc.org/ietf-muse/. You can find the hypermail'd mailing list archives there, as well as the Internet-Draft (draft-eastlake-muse-00.txt). I hope that soon the Web page will tell you how to join or exit the mailing list, too! One initial technical question I have about MUSE is why to bother encapsulating email messages while in transit in more layers of MIME glop? Why not just run IP Security between the sendmail daemons involved, and have the receiving sendmail daemon note in the Received header that the message arrived over an authenticated connection? IPSEC provides your choice of authentication and/or encryption, and already uses the keys from the Domain Name System. IPSEC solves many other problems as well as the particular secure/private email delivery problem. And deploying a Real Application (sendmail) that uses IPSEC would shake it out and get it widely used. John Gilmore

One initial technical question I have about MUSE is why to bother encapsulating email messages while in transit in more layers of MIME glop? Why not just run IP Security between the sendmail daemons involved, and have the receiving sendmail daemon note in the Received header that the message arrived over an authenticated connection?
Because this gives you a point-to-point solution. MUSE is still end-to-end; the only difference is that the ends have moved slightly away from the user in the interests of deployment expediency.
IPSEC provides your choice of authentication and/or encryption, and already uses the keys from the Domain Name System. IPSEC solves many other problems as well as the particular secure/private email delivery problem. And deploying a Real Application (sendmail) that uses IPSEC would shake it out and get it widely used.
IPSEC does indeed solve many problems. Unfortunatly secure email end-to-end email isn't one of them. Ned

-----BEGIN PGP SIGNED MESSAGE-----
Don Eastlake has written an internet-draft proposing to add signatures and encryption to the Internet mail-delivery system. The two big differences between his proposal and past proposals are:
* They work at the "sendmail" level, not at the "mail reader" level. This doesn't give your mail complete end-to-end protection (unless you use "mail reader" encryption like S/MIME or PGP). But it's a lot easier to install and maintain; your sysadmin can do it for your whole site, instead of having to retrain every user.
One obvious problem with this is that since sendmail runs at all times of day or night and since sendmail must have the decryption keys, this means that the decryption keys may be in the memory of a computer that may be unattended. This scheme may be useful for its convenience, but many users will only be willing to turst the computer with their keys while there messages are actually being decrypted in their presence. Thus, many users will want to super encrypt with their own personal keys. Thus I believe that the above scheme should be implemented for mail security between sites, but it should not be viewed as a total solution. - -- Paul Elliott Telephone: 1-713-781-4543 Paul.Elliott@hrnowl.lonestar.org Address: 3987 South Gessner #224 Houston Texas 77063 -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: cp850 iQCVAgUBMV229/BUQYbUhJh5AQFrIgP/eejmxUvAiRtJQfkHyrIZflQ6tQBz1PuB Oxl31K+xnIYmpgIJHb2M+flpeTlOE+6DyIf3ZTB3UMHRqT1v5VrVmDy0ByrukrjF KRbJTLO2yuDadZKEGKrm+n1FAleCpwuoQJTem7S5XQQts6FCscqaII61HNBkSC0V JkDwN8ouYsk= =YUcS -----END PGP SIGNATURE-----
participants (3)
-
John Gilmore
-
Ned Freed
-
Paul Elliott