Re: message-signing at the MTA level
In 1997 I proposed something along these lines. Appended at the end is
the last rev I did of the Internet Draft...
Donald
===
Donald E. Eastlake 3rd +1 914-276-2668 [EMAIL PROTECTED]
65 Shindegan Hill Rd, RR#1 +1 914-784-7913(w) [EMAIL PROTECTED]
Carmel, NY 10512 USA
From: Bill Stewart <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
Date: Mon, 13 Sep 1999 18:00:49 -0700
To: Russell Nelson <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
>>On Sat, Aug 21, 1999 at 10:09:31PM -0400, Russell Nelson wrote:
>>> I've been thinking about cryptographic signing of messages at the mail
>>> transfer agent level. I can think of how to do it, but I'm not sure
>>> what problem it solves. :) Anyone have any ideas?
>>
>At 12:01 PM 8/22/99 -0700, Eric Murray wrote:
>>I wrote a similar system for Sun 4 or 5 years ago. However its purpose
>>was to encrypt the email for secrecy. It used sendmail and PGP, would
>>automagically encrypt messages sent to hosts/domains registered in a
>>config file, and would use the same config file to attempt to decrypt
>>incoming PGP'd messages.
>
>PGP/NAI developed an SMTP forwarder system that does rule-based processing
>with capabilities like
> - Encrypt outgoing mail when possible
> - Block unencrypted outgoing mail to some/all sites
> - Block encrypted outgoing mail to some/all sites
> - copy+encrypt in/outgoing mail to Corporate Email Escrow
> - Block outgoing mail not also encrypted to Corporate Escrow
> - Sign&date incoming or outgoing mail
>This was during their Corporate Escrow period, so we all taunted them about
>it,
>rather than doing much thought about what things might be useful.
>
>Cryptographic signing of the messages can be useful in some
>business environments, though I'd prefer encryption+signing for many of them.
>If you always sign outgoing mail, and somebody asserts that
>an unsigned message is from your company, you've got some ability to
>argue that it's forged. More importantly, if someone knows you
>always sign your mail, and they receive unsigned mail claiming to be from you,
>you and they can be suspicious.
>
>One of the fun things about just doing signatures is that you can
>distribute the software for free if you want, without US export laws.
>
>A big problem with this, though, is making very sure that the software
>doesn't sign things it's not supposed to sign. This is hard, because
>it depends on the user's configuration of their mailserver and firewalls,
>which is mostly out of your control - having software with your name on it
>that gets abused this way would be Really Bad.
>
> Thanks!
> Bill
>Bill Stewart, [EMAIL PROTECTED]
>PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
INTERNET-DRAFTDonald E. Eastlake 3rd
CyberCash
Expires: November 1997 May 1996
Mail Ubiquitous Security Extensions (MUSE)
-- -- --
Status of This Document
This draft is file name draft-eastlake-muse-02.txt. Distribution of
this document is unlimited. Comments should be sent to the ietf-
[EMAIL PROTECTED] mailing list or to the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
Next page...
INTERNET-DRAFTMUSE May 1997
Abstract
Secure electronic mail can provide authentication of the source of
mail and confidentiality for its contents. These features are
becoming increasingly important as the Internet grows exponentially
and email is increasingly used for critical, sensitive, and
confidential communications. In addition, authentication
Re: message-signing at the MTA level
>On Sat, Aug 21, 1999 at 10:09:31PM -0400, Russell Nelson wrote: >> I've been thinking about cryptographic signing of messages at the mail >> transfer agent level. I can think of how to do it, but I'm not sure >> what problem it solves. :) Anyone have any ideas? > At 12:01 PM 8/22/99 -0700, Eric Murray wrote: >I wrote a similar system for Sun 4 or 5 years ago. However its purpose >was to encrypt the email for secrecy. It used sendmail and PGP, would >automagically encrypt messages sent to hosts/domains registered in a >config file, and would use the same config file to attempt to decrypt >incoming PGP'd messages. PGP/NAI developed an SMTP forwarder system that does rule-based processing with capabilities like - Encrypt outgoing mail when possible - Block unencrypted outgoing mail to some/all sites - Block encrypted outgoing mail to some/all sites - copy+encrypt in/outgoing mail to Corporate Email Escrow - Block outgoing mail not also encrypted to Corporate Escrow - Sign&date incoming or outgoing mail This was during their Corporate Escrow period, so we all taunted them about it, rather than doing much thought about what things might be useful. Cryptographic signing of the messages can be useful in some business environments, though I'd prefer encryption+signing for many of them. If you always sign outgoing mail, and somebody asserts that an unsigned message is from your company, you've got some ability to argue that it's forged. More importantly, if someone knows you always sign your mail, and they receive unsigned mail claiming to be from you, you and they can be suspicious. One of the fun things about just doing signatures is that you can distribute the software for free if you want, without US export laws. A big problem with this, though, is making very sure that the software doesn't sign things it's not supposed to sign. This is hard, because it depends on the user's configuration of their mailserver and firewalls, which is mostly out of your control - having software with your name on it that gets abused this way would be Really Bad. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: message-signing at the MTA level
Greg Rose writes: > At 22:09 21/08/1999 -0400, Russell Nelson wrote: > >I've been thinking about cryptographic signing of messages at the mail > >transfer agent level. I can think of how to do it, but I'm not sure > >what problem it solves. :) Anyone have any ideas? > > Signing messages at the MTA level solves no problem at all unless there's a > widely deployed PKI. Because of man in the middle attacks? You could supply a public key in the SMTP server banner, but that doesn't help if someone is fudging things in the middle. Encryption would help, though, wouldn't it? Of course, you've got a nasty bit of known plaintext right at the beginning: "Received:" Actually, if your sole threat model is "telnet mail.example.com 25", then *any* kind of crypto helps. :) And if I go down in history for any quote at all, it should be: "Crypto without a threat model is like cookies without milk." -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: message-signing at the MTA level
At 22:09 21/08/1999 -0400, Russell Nelson wrote: >I've been thinking about cryptographic signing of messages at the mail >transfer agent level. I can think of how to do it, but I'm not sure >what problem it solves. :) Anyone have any ideas? Signing messages at the MTA level solves no problem at all unless there's a widely deployed PKI. >[I remember that someone in Australia built some experimental patches >to do this for sendmail some time back. That was me/us. There's a paper coming up and a rerelease of the software in about three weeks. I'll send another message then. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: message-signing at the MTA level
On Sat, Aug 21, 1999 at 10:09:31PM -0400, Russell Nelson wrote: > I've been thinking about cryptographic signing of messages at the mail > transfer agent level. I can think of how to do it, but I'm not sure > what problem it solves. :) Anyone have any ideas? I wrote a similar system for Sun 4 or 5 years ago. However its purpose was to encrypt the email for secrecy. It used sendmail and PGP, would automagically encrypt messages sent to hosts/domains registered in a config file, and would use the same config file to attempt to decrypt incoming PGP'd messages. The proposed use was between corporate/sales offices in certain countries east of Europe. There had been an existing DES-based system in place but key management was geting harder with more offices. For a previous company I'd been requested to build the same kind of thing to automatically protect emails between corporate officers and lawyers and partners. Either way, the purpose is to make the encryption/decryption automatic as far as the end-users are concerned. It's hard enough to get some corporate officers or marketing people to understand how a regular email programs works or to pick good passwords. Educating them on how to use PGP is like herding snakes[0]. So automating the process is a good thing. There are security problems with this, not the least of which is that the process that handles the crypto has got to leave the private keys unlocked (or have the passphrase built in, same thing). If you can assume that this happens on your internal network, and that network is secure, then this is probably ok. It does present a nice target if an attacker manages to penetrate your network though. I don't know what a signature by itself would accomplish, other than preventing modification of the email body in transit. The impression I get is that SMTP headers are sufficent legal proof of where and when a message was sent. Perhaps autosigned messages would be better in that regard, but any of us on this list could cast almost as much doubt on an autosigning system (based on known security holes & flaws) as on SMTP headers. [0] One can argue that it's possible to herd snakes if one waits until it's time for them to hibernate, but I have not yet discovered the hiberation season for marketing people. However talking crypto in front of the does seem to put them in a mild torpor. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
message-signing at the MTA level
I've been thinking about cryptographic signing of messages at the mail transfer agent level. I can think of how to do it, but I'm not sure what problem it solves. :) Anyone have any ideas? [I remember that someone in Australia built some experimental patches to do this for sendmail some time back. RFC2487 proposes a more standard way to do this, using TLS for the encryption. One may argue that the mechanism ultimately does not protect end to end message integrity, but it most certainly *does* monkeywrench vacuum-cleaner style mass tapping, and as such is possibly a very good thing even if it provides no authentication at all... It would be nice to open some discussion of this. --Perry] -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
