Brandon Long wrote: > > > On Fri, Jun 26, 2015 at 7:03 PM, Michelle Sullivan <miche...@sorbs.net > <mailto:miche...@sorbs.net>> wrote: > > > > Sure SMTP can have the lowest common denominator, but I thought the > whole point of the protocol and extensions was: > > 1/ You want to ensure the email is not readable by a 3rd party you > encrypt (PGP/SMIME) it.. > 2/ You want to ensure credentials for SMTP-AUTH are not > compromised you > SSL3/TLS/TLSv1.2,DH=4096 the connection > > and what you don't do is: > > 3/ Encrypt the connection so no-one can see my email in transit.... > because yeah sure all servers will always TLSv1.2.... > >
Yeah probably was a little to matter of fact there.. probably should have saved, edited and sent later. > The point I have about bringing up Snowden is that for bulk > collection, they'll go where they can and find the weak link. I understand that, which means the sending or receiving computers unless they can hitch in a snooping point somewhere in between.... > We won't be that link, if I can help it. We have a ways to go, of course. .... however that's not necessarily going to stop with all the counter measures because someone will allow it, but as you correctly pointed out, at least it won't be you. > > Especially since #1 for everyone is a really long pole. Sure, if > you're an actual target, #1 is a minimum... or not using this > infrastructure at all might be an even better choice. The main concern I have is if I want to exchange email, you're going to make it mandatory that I TLS 1.2 all connections with you? (or you with me..?) Here's my thought (and where it gets complicated) If I request to send unencrypted, I expect you to accept it. If I request to send encrypted I expect you to at least keep the encryption to the level I have requested (and possibly try to negotiate higher levels if both servers can agree.) If you send to me and request encryption an I don't support (or to the level you request) it you can make a policy decision whether to continue (as I can in reverse.) Now the complicated bit.... Who says what should or should not be encrypted? Well when it comes to what should be encrypted that's easy... The person sending, if they want encryption then their desire for encryption should be honored or them given the option to go elsewhere. If the person sending is not bothered about encryption encrypting or not is totally optional at the providers preference. Now the problem here is for the end user to request a encrypted email the *only* way to ensure that is by encrypting the email itself because as a provider of a service by it's very design was not intended to be encrypted (and lets face it transport layer encryption is an optional bolt on) is to deliver it yourself to the server that the destination email address (and storage) resides on, and as you know with your service that's just not possible (practically or with any sort of scalability.) Now when it comes to that policy as a provider you can say, "Ok all email transport will be encrypted to 'this' standard leaving our network or will not be sent" as a policy and "All email transport inbound must be encrypted to this standard or it will not be accepted" problem is do the users want that for the very small percentage of email that should be encrypted...? Note: My servers require authentication for relay, all authentication sessions must be encrypted (for the actual authentication and the remainder of the authenticated session.) My MX servers (in and outbound) do not required transport layer encryption... and currently won't even support it (and I don't actually want to support it - too many SSL library root hacks in the past for me to trust high volume gateways to end user attacks... same reason I force only the login and registration and personal details on the website into the TLS sessions and force it back to plain text for 'normal browsing' (it's easier to spot hacks/attempts where there is little traffic rather than in streams of data to the order of gigabytes per day) - obviously that works for me, and wouldn't work for the likes of Google+ and Facebook because it's mostly personal details, but I'm sure you get the point.) Thoughts/comments welcome. Michelle -- Michelle Sullivan http://www.mhix.org/ _______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
