Dear Ned, Good questions. See comments inline.
On Oct 19, 2013, at 2:48 PM, Ned Freed <[email protected]> wrote: >>> You're still not answering the question, at least directly, and I really >>> want a >>> direct answer. More expensive for whom? The vast majority of current and >>> likely >>> future email users, who seem perfectly happy to use the service offerings of >>> large ISPs and MSPs? If so, then any proposal you come up with needs to >>> done in >>> a way that persuades those providers that making changes to their service >>> offerings is the right thing for them to do. > >> Dear Ned, > >> Improving the efficiency of email acceptance might be this incentive. As >> IPv6 becomes pervasive, an authenticated domain source as a basis is likely >> to >> be more sustainable over time. Establishing expectations that StartTLS >> confirms both server and client certificates affords improved transactional >> protection from spoofing or reputation poisoning, especially with the >> transparency and economy afforded by DANE for protection from simple >> monitoring, malicious spoofing, and reputation poisoning. Providers will >> need >> to be trustworthy and may need to reside in specific geopolitical regions >> willing to ensure such protections. > > I must be missing something here, because I don't see how what we've been > discussing - preventing pervasive surveilance in general and mandating > SSL/TLS on more connections in particular - has anything to do with email > acceptance. This is achieved by StartTLS exchanging BOTH client and server certificates. While indeed security concerns are normally related with destinations of account access over web, IMAP, and POP where the client is authenticated using other means, it is important not to overlook the lack of privacy protection afforded plaintext exchanges over SMTP. Internet exchange in plaintext is exposed to undetectable surveillance not requiring any provider cooperation. Deprecating use of plaintext exchange for what should be considered "private" user-to-user communications would force governments and providers to use expressed policies. Any plaintext exchange should be considered "public" especially when warrantless wiretapping has become the norm since 2007 with legal clarifications suggesting "information gathering" is not "electronic surveillance". This can lead to Orwellian concerns of "self censorship" through various forms of suppression and ostracism. Private exchanges should be able to use encryption as the prevalent mode for all exchanges. With SMTP, encrypted exchanges immediately confront a lack of source authentication necessary to defend the service from pervasive abuse. With IPv4, a lack of source authentication is supplanted by reliance on the IP address as a basis for acceptance. This practice has many drawbacks such as preventing the effective use of IPv6 that could be remedied by validating the client certificate used in what would have been a plaintext port 25 exchange and its related loss of privacy. >> Multiple keying of encrypted data where each key subset resides in different >> geopolitical regions might be a way to increase trust, but this is not >> off-the-shelf crypto which you state as a requirement. > > The security of IMAP and similar mailbox manipulation protocols seems > entirely divorced from what you're talking about. Almost. There are some delivery schemes that do not depend upon privacy protections afforded by the infrastructure. For example, Trend acquired an identify based keying product developed by the University of Bristol back in 2002. Here is a white paper created by the Enterprise Strategy Group. http://www.trendmicro.com/cloud-content/us/pdfs/business/white-papers/wp_true-costs-of-email-encryption_analyst-esg.pdf It uses Identity Base Encryption (IBE) a derivative of PKI, but with simple identity attributes. Rather than depending on CAs, Central Trust Authority (CTA) is used instead. Because destination addresses decode the symmetric key, only that portion of the message is uniquely encrypted. This allows one image to be sent to several destinations where only those intended to see the message are able to decrypt. This approach allows enterprises a means to inspect for data leaks to comply with governmental requirements not practical with S/MIME or OpenPGP unless key management and encryption has been centralized. As such, this means a portion of the message path could be exposed. After speaking with the developer of this technology, one of the features envisioned from this approach was to require the use of multiple CTAs each located in different geo-political regions to prevent any unilateral governmental action defeating message privacy. If there is any interest in this technology, perhaps I could then request my management share its terms and conditions and more of the underlying details. Regards, Douglas Otis
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
