Re: What email encryption is actually in use?
On Wed, 2 Oct 2002, Matthew Byng-Maddick wrote: I have to say that much as it is a laudable goal to get widespread encryption on the SMTP server network, I'm rapidly coming to the conclusion that opportunistic encryption in this way doesn't really work. Consider where one side believes that it will only accept certificates signed by a particular CA (a perfectly plausible scenario in the case of SSL/TLS), and I hand it a self-signed one - this is not communicable before the connection starts up, and in-protocol, a failure to apply policy causes the connection to be shut down (this is by no means the only one, consider one side that only use DES and the other that never use it), leaving the connection in an undefined state. I consider that state perfectly well defined -- it is the no connection state. The only reason any protocol works is because people prefer abiding by its rules and the policies each other set up in it to having no connection. The essence of a protocol is to detect situations where one party or the other prefers No connection over the rules, and enforce that such detection happens before any confidential data is shared. According to this rule, I would say that the protocol you say is in an undefined state has in fact functioned perfectly. It detected a rule that the other was not willing to abide by and dropped the connection *before* risking any confidential data. That's precisely what it was supposed to do. The problem with this is obvious. You have to treat the failure as a temporary failure and try again in a bit. Of course, we know that the only way you're going to send this system mail is by sending it in plaintext, because otherwise you won't adhere to policy, but also, given that it's an automated service, there's no human to turn round and try something slightly different, as there is in the case of the Web Browser or mail client talking SSL. But if you are willing to abide by the sending-plaintext protocol in the first place, this is perfectly reasonable too. Protocol termination for lack of willingness to trust single-DES is no different than termination of protocol for lack of willingness to send (or receive) plaintext. Where our protocol design fails is in considering plaintext to be something other than a particularly unreliable and ineffective encryption algorithm. Certainly nobody who's willing to reject a connection for a self-signed certificate should be willing to accept plaintext, because obviously plaintext is not as secure as the minimum security they are requiring. But experience shows that people willing to reject self-signed certs and poor ciphers always seem to be willing to accept the even poorer cipher named plaintext. This is completely irrational; either you need security or you don't. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: What email encryption is actually in use?
At 06:50 PM 10/2/02 -0700, Lucky Green wrote: Steven raises an interesting point. Having looked at various STARTTLS implementations it appears to me that if not the designers of STARTTLS then at least the authors of STARTTLS-enabled MTAs appeared to have envisioned the use of STARTTLS primarily to secure and authenticate email submission, not MTA-to-MTA SMTP transfer. I agree. In fact, the primary reason I use (and recommend) STARTTLS is to defeat logging by snoopy employers and/or clients. Udhay -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
RL 'Bob' Morgan wrote: | On Wed, 2 Oct 2002, Jeremey Barrett wrote: | | Evolution does? I tried out the Evolution 1.0.3 that comes with my RedHat | 7.3 distribution, and it appeared not to support STARTTLS for IMAP or | SMTP. When I told it to use secure connection (SSL) for SMTP it tried | to connect to port 465 (the deprecated smtps port) and failed. | Hrm, you're right. I was sure I'd tested Evolution. That's too bad... they picked the wrong thing to implement in a big way. Regards, Jeremey. -- Jeremey Barrett [[EMAIL PROTECTED]]Key: http://rot26.com/gpg.asc GnuPG fingerprint: 716E C811 C6D9 2B31 685D 008F F715 EB88 52F6 3860 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
Matthew Byng-Maddick wrote: | On Wed, Oct 02, 2002 at 10:04:03AM -0500, Jeremey Barrett wrote: | |BTW, most and probably all of the major mail clients out there will do |STARTTLS *for SMTP*. It's a matter of servers offering it and clients |being configured to actually use it. It'd be nice if they always used it |if it's available, but right now I think they all require being told to. | | | I have to say that much as it is a laudable goal to get widespread | encryption on the SMTP server network, I'm rapidly coming to the conclusion | that opportunistic encryption in this way doesn't really work. Consider | where one side believes that it will only accept certificates signed by a | particular CA (a perfectly plausible scenario in the case of SSL/TLS), and | I hand it a self-signed one - this is not communicable before the connection | starts up, and in-protocol, a failure to apply policy causes the connection | to be shut down (this is by no means the only one, consider one side that | only use DES and the other that never use it), leaving the connection in an | undefined state. | Opportunistic SSL/TLS will only work if people configuring it are of the mind that it's better to encrypt than not. No public SMTP server should require valid certificates or give any more trust over SSL than they do over not-SSL. This way, the links get encrypted. Anything else (on public SMTP servers) is misconfiguration. Now you could *add* trust, as appropriate, if you do see certs (or whatever) that you like, but it's always better to encrypt than not, even if no additional trust is gained. Jeremey. -- Jeremey Barrett [[EMAIL PROTECTED]]Key: http://rot26.com/gpg.asc GnuPG fingerprint: 716E C811 C6D9 2B31 685D 008F F715 EB88 52F6 3860 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
In message [EMAIL PROTECTED], John Saylor writes: Hi ( 02.10.02 12:50 -0500 ) Jeremey Barrett: but it's always better to encrypt than not, even if no additional trust is gained. While I generally am on board with this, I can see a situation where the encryption overhead [and complexity] may be excessive [underpowered mail servers administered by beginners] compared to the gains. The primary use of STARTLS for SMTP is for mail *submission*, not relaying. That is, when clients (like Eudora) generate mail, they submit it to an ISP or organizational SMTP server. If this server is accessible from the Internet, it should require some sort of authentication, to avoid becoming an open spam relay. This is sometimes done by a password over a TLS-protected session. In other words, this isn't opportunistic encryption, and doesn't run into the problem of random smtp server has a self-signed cert. The client should be configured to know what cert to expect. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
On Wed, Oct 02, 2002 at 02:56:39PM -0400, Steven M. Bellovin wrote: | While I generally am on board with this, I can see a situation where the | encryption overhead [and complexity] may be excessive [underpowered mail | servers administered by beginners] compared to the gains. | | The primary use of STARTLS for SMTP is for mail *submission*, not | relaying. That is, when clients (like Eudora) generate mail, they | submit it to an ISP or organizational SMTP server. If this server is | accessible from the Internet, it should require some sort of | authentication, to avoid becoming an open spam relay. This is | sometimes done by a password over a TLS-protected session. | | In other words, this isn't opportunistic encryption, and doesn't run | into the problem of random smtp server has a self-signed cert. The | client should be configured to know what cert to expect. Its seemingly easy to configure postfix to opportunisticly encrypt email. That may not be its primary use, and many of the pages describing how to set things up miss this, but In main.cf: smtp_use_tls = yes smtp_tls_note_starttls_offer = yes results in this is my mail headers saying: Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by H203.C220.tor.velocet.net (Postfix) with ESMTP id CC7593008F for adam Opportunisticly. The other guy accepts my cert at random. We're totally vulnerable to MITM. (Lucky points out in another thread that it would be great to have cert persistance, which can maybe be emulated by putting a really big number in the timeout: smtpd_tls_session_cache_timeout = 3600s He's right. But I'm not letting the best be the enemy of the good.) Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
Matthew Byng-Maddick wrote: On Wed, Oct 02, 2002 at 10:04:03AM -0500, Jeremey Barrett wrote: BTW, most and probably all of the major mail clients out there will do STARTTLS *for SMTP*. It's a matter of servers offering it and clients being configured to actually use it. It'd be nice if they always used it if it's available, but right now I think they all require being told to. I have to say that much as it is a laudable goal to get widespread encryption on the SMTP server network, I'm rapidly coming to the conclusion that opportunistic encryption in this way doesn't really work. Consider where one side believes that it will only accept certificates signed by a particular CA (a perfectly plausible scenario in the case of SSL/TLS), and I hand it a self-signed one - this is not communicable before the connection starts up, and in-protocol, a failure to apply policy causes the connection to be shut down (this is by no means the only one, consider one side that only use DES and the other that never use it), leaving the connection in an undefined state. The problem with this is obvious. You have to treat the failure as a temporary failure and try again in a bit. Of course, we know that the only way you're going to send this system mail is by sending it in plaintext, because otherwise you won't adhere to policy, but also, given that it's an automated service, there's no human to turn round and try something slightly different, as there is in the case of the Web Browser or mail client talking SSL. I remain to be convinced on the value of opportunistic encryption. In my mind it doesn't, apparently, do anything useful. Of course, properly configured SSL, I'd agree with, but that means advertising what you're going to talk in some way that means you won't get half way through the protocol and leave it in an undefined state. If you are going to do opportunistic encryption, then you have to be prepared to be opportunistic. Clearly, configuring your server so it can't encrypt opportunistically is a barrier to opportunistic encryption. It isn't hard to set up SSL so it will interoperate with everything (this is why there are mandatory ciphersuites). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
Steven M. Bellovin [EMAIL PROTECTED] writes: While I generally am on board with this, I can see a situation where the encryption overhead [and complexity] may be excessive [underpowered mail servers administered by beginners] compared to the gains. The primary use of STARTLS for SMTP is for mail *submission*, not relaying. While it may was designed for submission, STARTTLS use in relaying probably transports more mail -- looking at the past month, of the 82000 mail I received close to 11000 was delivered in encrypted streams. 7% is quite nice... I wonder how that compares with the use of OpenPGP or S/MIME in mail. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
On Wed, 2 Oct 2002, Jeremey Barrett wrote: BTW, most and probably all of the major mail clients out there will do STARTTLS *for SMTP*. It's a matter of servers offering it and clients being configured to actually use it. It'd be nice if they always used it if it's available, but right now I think they all require being told to. Specifically, Mozilla, Outlook, Outlook Express, Netscape (all the way back to 4.7x at least), Evolution, and Eudora all support STARTTLS (again, for SMTP). I imagine there are others that do as well. Amusingly, virtually none of them support STARTLS on any other protocol. :) IMAP and POP are almost all supported only on dedicated SSL ports (IMAPS, POP3S). Argh. Pine and UW imapd both support STARTTLS for all relevant protocols (SMTP/IMAP/POP/LDAP client for Pine, IMAP/POP server for imapd). They also support Kerberos authentication and datastream encryption for all these protocols. Evolution does? I tried out the Evolution 1.0.3 that comes with my RedHat 7.3 distribution, and it appeared not to support STARTTLS for IMAP or SMTP. When I told it to use secure connection (SSL) for SMTP it tried to connect to port 465 (the deprecated smtps port) and failed. - RL Bob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
At 09:05 AM 10/01/2002 -0700, Major Variola (ret) wrote: So yes Alice at ABC.COM sends mail to Bob at XYZ.COM and the SMTP link is encrypted, so the bored upstream-ISP netops can't learn anything besides traffic analysis. But once inside XYZ.COM, many unauthorized folks could intercept Bob's email. Access Control is sorely lacking folks. I'm running Win2000 in You're Not The Administrator mode. Since somebody else is root and I'm not, the fact that my network admins could eavesdrop on my link traffic isn't a big deal, especially when they set up my PC's software. And if I do pretend to trust my machine against some insiders, I can use SSH, SSL, and PGP to reduce risks from others... Also, STARTTLS can reduce eavesdropping at Alice's ABC.COM. If your organization is an ISP, the risks are letting them handle your email at all (especially with currently proposed mandatory eavesdropping laws), and STARTTLS provides a mechanism for direct delivery that isn't as likely to be blocked by anti-spamming restrictions on port 25. Now to get some email *clients* using it. On the other hand, if your recipient is at a big corporation, they're highly likely to be using a big shared MS Exchange server, or some standards-based equivalent, so the game's over on that end before you even start. Take the STARTTLS and run with it... Link encryption is a good idea, but rarely sufficient. Defense in depth is important for real security. STARTTLS can be a link-encryption solution, but it can also be part of a layered solution, and if you don't bother with end-to-end, it's a really good start, and isolates your risks. It also offers you some possibility of doing certificate management to reduce the risk of man-in-the-middle attacks from outside your organization, and does reduce some traffic analysis. at Tuesday, October 01, 2002 3:08 AM, Peter Gutmann [EMAIL PROTECTED] was seen to say: For encryption, STARTTLS, which protects more mail than all other email encryption technology combined. If your goal is to encrypt 20% of the net by Christmas, STARTTLS will get a lot closer to that than a perfect system. Similarly, IPSEC using the shared key open secret would have been a much-faster-deployed form of opportunistic encryption than the FreeSWAN project's more complex form that wants some control over DNS that most users don't have. In the absence of a real Public Key Infrastructure, neither is totally man-in-the-middle-proof, so if the Feds are targeting *you* it's clearly not enough, but reducing mass-quantity fishing expeditions increases our security and reduces the Echelon potential - especially if 90% of the encrypted material is routine corporate email, mailing lists, Usenet drivel, etc. At 01:20 PM 10/1/02 +0100, David Howe wrote: I would dispute that - not that it isn't used and useful, but unless you are handing off directly to the home machine of the end user (or his direct spool) odds are good that the packet will be sent unencrypted somewhere along its journey. with TLS you are basically protecting a single link of a transmission chain, with no control over the rest of the chain. You can protect most of the path if your firewalls don't interfere, and more if your recipients' don't. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
At 10:04 AM 10/2/02 -0500, Jeremey Barrett wrote: Specifically, Mozilla, Outlook, Outlook Express, Netscape (all the way back to 4.7x at least), Evolution, and Eudora all support STARTTLS (again, for SMTP). I imagine there are others that do as well. Amusingly, virtually none of them support STARTLS on any other protocol. :) IMAP and POP are almost all supported only on dedicated SSL ports (IMAPS, POP3S). Argh. I use Eudora, as I'm very comfortable with it (so comfortable, in fact, that it's my primary reason for booting Windows at all.) The version I use, 5.1, *does* support STARTTLS for POP over both the regular port 110 as well as alternate ports, as well as user-defined ports. It needs some tweaking, but the capability exists. I don't know about IMAP, as I don't use IMAP to get my mail. Udhay -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
Udhay Shankar N wrote: | At 10:04 AM 10/2/02 -0500, Jeremey Barrett wrote: | | Amusingly, virtually none of them support STARTLS on any other protocol. | :) IMAP and POP are almost all supported only on dedicated SSL ports | (IMAPS, POP3S). Argh. | | I use Eudora, as I'm very comfortable with it (so comfortable, in fact, | that it's my primary reason for booting Windows at all.) | | The version I use, 5.1, *does* support STARTTLS for POP over both the | regular port 110 as well as alternate ports, as well as user-defined | ports. It needs some tweaking, but the capability exists. | | I don't know about IMAP, as I don't use IMAP to get my mail. | Yes, Eudora is the exception. It supports both STARTTLS and dedicated SSL ports for all mail protocols (it even does SMTPS I think). Jeremey. -- Jeremey Barrett [[EMAIL PROTECTED]]Key: http://rot26.com/gpg.asc GnuPG fingerprint: 716E C811 C6D9 2B31 685D 008F F715 EB88 52F6 3860 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
--On Wednesday, 02 October, 2002 10:54 -0500 Jeremey Barrett [EMAIL PROTECTED] wrote: Udhay Shankar N wrote: | At 10:04 AM 10/2/02 -0500, Jeremey Barrett wrote: | | Amusingly, virtually none of them support STARTLS on any other protocol. | :) IMAP and POP are almost all supported only on dedicated SSL ports | (IMAPS, POP3S). Argh. | | I use Eudora, as I'm very comfortable with it (so comfortable, in fact, | that it's my primary reason for booting Windows at all.) | | The version I use, 5.1, *does* support STARTTLS for POP over both the | regular port 110 as well as alternate ports, as well as user-defined | ports. It needs some tweaking, but the capability exists. | | I don't know about IMAP, as I don't use IMAP to get my mail. | Yes, Eudora is the exception. It supports both STARTTLS and dedicated SSL ports for all mail protocols (it even does SMTPS I think). it isn't the only exception: i use mulberry with IMAP, and it supports STARTTLS for both IMAP and SMTP over the normal ports; haven't tried POP3, although it looks like it should work. and this seems to work for mulberry on linux, macs and windows. -paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
