Some more thoughts on default deny for encrypted email. (Sorry about the length, I am known for that).
I am interested in this because I think Ned has it exactly right: Users are simply not going to put up with encryption that results in (from what I see on my servers) 100 times or more the amount of spam. And if ALL email is encrypted, we will be directly attacking the large services business models: they will fight this tooth and nail and that is a fight I doubt we can win. Email is one of the most used services, along with the web and dns. It is also the closest to someones 'letters and papers', the stuff we would like to be private. Transport level encryption only is not going to solve this as there are too many bad actors in between. We cannot just let this go. So some sort of compromise is needed. I don't know if this is the -best- idea, but if not this, what? The likely result of this would be that people encrypt mail to their friends, family, and maybe work, but not for things like Amazon orders. Since the large services are really more interested in what I want to buy than my notes to my children, this should accommodate their needs to show me better ads, etc. And they would be wise to support something like this, since the alternative may be, increasingly, 'all email encrypted by default'. The best way to see the flaws in an idea is to actually try to implement it. So I have been going through the steps (mentally only, so far) to do this. I had a look at RFC-5321 (apparently 821 is out of date ;-) ). There is no need to mess with 'HELO' 'EHLO'. There is already a mechanism for adding extended commands, that is what EHLO is all about [insert sound of palm slapping head here]. IANA maintains the list at http://www.iana.org/assignments/mail-parameters and there is a clear process to add new commands. I realized there is another clear use case than default rejection of encrypted, mail - it is the exact opposite of this. If you are in an environment that must be REALLY secure, say, a defense contractor, etc., you might want to force ALL email to be encrypted, and reject all others. But humans make errors, so it might be useful to have a situation where all unencrypted email is rejected, and only encrypted email would be allowed to be sent. If done by the server (in this case the server acting as the submission server), a user who accidentally had encryption turned off would get an immediate rejection and be unable to send the email at all - this is much better than say, filtering, where the email (between offices, say) would have gone out in the clear before being rejected. Another realization I had was that if used as described below, this actually creates a user controllable mechanism for default deny even on unencrypted emails, since the MTA just believes what the MUA tells it about the status of the email. The user just needs to lie about whether the email is encrypted. While seemimgly useless, this could actually have some use in filtering. TThe basic concept of default deny for encrypted emails only seems very 'right' to me, because if you are going to the trouble to do this, and handle things like key exchanges, that communication must be pretty special to begin with. Why would you want 'just anyone' to be able to send you encrypted emails? So the problem boils down to this: 1. To create a way for the information that an email is encrypted by the MUA (Mail User Agent or other source) to be passed to the MTA, and all succeeding MTAs, and for the MTA (relay, submission agent, etc.) to be able to make delivery or other decisions on the basis of that status. 2. Additionally, there must be a way for users to whitelist or blacklist email, on a per user basis, and have the MTA be able to make use of those lists. Ideally we could make some new commands and all the MTAs and MUAs would ugrade and everything would be wonderful. Of course that is not how the real world (or the internet) actually works, so we must deal with that reality. There will always be a mix of upgraded and not upgraded systems. There are many different MUAs (hundreds ?), but really just a FEW (maybe 6 or so?) MTAs in common use. The MTAs also tend to be run by businesses, with system administrators, and be upgraded relatively frequently, especially compared to the users mail programs. So it would make sense to put as much of the functionality and changes needed into the MTAs, and even better have a way to use this system even if the users MUA does not support it yet. There should also be a way to handle the situation where an MTA in between two other MTAs that are updated is not, so the information would be lost. So, walking through this step by step: The first problem is how the information that an email is encrypted get passed to the MTA? We would have a new extended mail command registered, perhaps 'PRECRYPTED'. The user agent engages in the submission dialog, with EHLO, if that is ok (meaning the MTA understands extended mail commands), it issues PRECRYPTED (meaning the next message is encrypted by the MUA). If the MTA gives an error at that point, the MUA knows it does not understand this command and proceeds accordingly. Now, what if the NUA does not yet understand this setup, a likely scenario at first? How can the user tell the MTA that an email is encrypted? I suggest two ways. Many MUAs allow the user to set headers. So we have some standard headers that indicate this. Something like: ENCRYPTION: MUA which indicates 'the message has been previously encrypted by the user'. Other things might be on the right side, such as 'TRANSPORT' meaning use transport level encryption for this message if available, or -require- transport level encryption. Or perhap some other use. That would be a required header. Another, optional header might be something like: ENCRYPTION-TYPE: PGP Optional, because the user may not want to make that information available. Now we need one rule for the updated, aware MUA: If it is going to indicate an email is previously encrypted, it MUST also add an ENCRYPTION:MUA header. (This covers the case where only the originating MUA and the last MTA are updated, see below.) Ok, so what if the users MUA doesn't even allow for adding headers? Thanks again to Ned for reminding me of this by his use of a plussed address (ned+perpass). We have a standard 'plussed' address of '+precrypted' which means the email is encrypted. So our user with a really dumb email program may simply adds this to his email that is encrypted to insure it will get through. Now let's add some rules for the MTA: If an MTA is informed by any means that an email is previously encrypted, it MUST updates its status, and insure that the email contains the ENCRYPTION: MUA header, creating it if necessary. And it MUST do this at any stage in the process. (not just upon submission). What this does in handle the case where there are two updated MTAs, but one in the middle relaying is not, and some other errors or special cases. The above is part of addressing the second problem, which is how we insure the encypted status of an email is passed on between MTAs. Here we may have a mixture of updated and non-updated MTAs. If the above rules are followed, in the end, only the LAST MTA, the one that is delivering the emails to local users, has to be updated. That last MTA is either going to have the status passed to it by an updated MTA, or see an ENCRYPTION:MUA header, or see a plussed address, in which case it will follow the rules and treat the email as previously encrypted, also adding the header. The net result of the above is that, for example, a business might only upgrade THEIR MTA, and get the full anti-spam and other benefits of this system. So there is an immediate benefit to the users even if no one else on the internet has upgraded yet. The actual MTA to MTA mail transaction is slightly tricky, as we need to be able to accept or deny based upon the sender, and specifying the sender is the very first transaction in an individual mail submission. MAIL FROM:somb...@somewhwere.com So the status of whether a mail transaction is for an encrypted email needs to be known before that point. Sendmail has a way to delay that check, but this is configurable so cannot be counted on. So I think the way to go here is to use PRECRYPTED as a mode that can be turned on or off. That would also make sending a series of encrypted emails more efficient, since the command would only need to be made once for the block of emails. So we would be looking at something more like: EHLO mail.example.com 220 Howdy there mail.example.com. uptodate-mail V2.1.0 ready for your command. PRECYPTED ON 2xx OK Precrypted mode ON, expecting encrypted emails. MAIL FROM:somb...@somewhwere.com 250 Precrypted Sender OK RCPT TO:go...@updated.com 250 Recipient OK ... PRECYPTED OFF 2xx OK Precrypted mode OFF expecting normal email ... send normal mail I think I have most of the edge cases covered, but if not, the result would be that an encrypted email is accepted, because the system thinks it is ordinary mail. This can then be dealt with by normal filtering, which, while it may not be able to read the email, should be at least able to recognize an encrypted email, and dump it or otherwise do something sensible. The final problem is the user must be able to communicate whitelists and/or blacklists to the local receiving MTA. This gets pretty system and MTA specific. As I previously mentioned, I doubt this will be much of a problem for large services, since they already are storing loads of metadata in databases, etc. For medium and small systems, it might to be useful to have a somewhat standardized system. For unix style systems and sendmail (using this only because it is what I am most familiar with) I might do something like this: Each user dir has a .mailwhitelist and .mailblacklist file which just contains the raw email addresses. In addition, there is one more file that is the result of putting those lists into the specific format used by the specific MTA in use. So the standarization here is: standard format whitelist and blacklist files (which could also be used by another program, such as spamassassin or procmail), plus an MTA dependent file in that MTAs proper format. So for example with sendmail, it uses /etc/mail/access, so that file in the userdir might be .access. In Sendmails case, what actualy happens is that the access file is where the user puts blocks, etc, but that file must be compiled into a database for actual use by the sendmail program, access.db. Often there is a makefile or similar way that is updated, so the actual addition of the local users whitelists to the main MTA list would be done by that makefile or similar means. In the actual access file itself, Sendmail would need to add the capability to distinguish pre-encryped email in its rules. Currently, for normal email I could make a default deny mode with something like: To:mde...@demmers.org REJECT From:j...@example.com OK From:m...@example.com OK which would allow me to receive only mail from those two users. So maybe using something like: To_Precrypted:mde...@demmers.org REJECT From_Precrypted:j...@example.com OK From_Precrypted:m...@example.com OK would work well. And we may as well throw in Connect_Precrypted: as well, which will allow for whitelisting by connecting address, domain, etc. I mention above the users should have individual control of whitelists, however, since this is primarily a spam control measure, that is probably not really necessary in the sense of 'only my whitelist applies to me'. It does not really matter if Mary in accounting has whitelisted 'cosult...@accounting.com', since that person will not be a spammer, and will never email me anyway. If they did, I would be unable to read the email since I would not have exchanged keys with them. Normal mail filters could just drop it as well. It is crytal clear that NSA and other state actors are treating encrypted email differently, I even saw a comment by some senator to the effect that 'if you are using encryption, you are proabably a terrorist or criminal'. So until encryption is very commonly used, it might be said that 'Unless everyone has privacy, no one does'. It is not enough to just provide easy ways for people to use encryption, we must actually get them to USE it. Even now, with all the revelations, something like 40 percent of the people seem to not care that NSA etc are collecting, analyzing, and possibly reading their emails. What people pretty much universally DO care about is spam. So I think this is a real sales point to get people to actually USE encryption: 'If you use encryption, you will get NO spam to those accounts, plus have privacy.' Something not really covered here is that I think there should be some guidelines for MUAs concerning standardizing the interface to this. Standard names for functions like adding someone as an encryption only person ('friend'), that MUAs should have standard ways to handle key exchange, etc. But this message is way too long already. So what do you think? Good idea? Flaws to fix? Have a better idea to solve the problem? -Mike Demmers _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
