On Mon, Jun 29, 2015 at 1:48 PM, Michelle Sullivan <[email protected]> wrote:
> Brandon Long wrote: > > > > > > On Fri, Jun 26, 2015 at 7:03 PM, Michelle Sullivan <[email protected] > > <mailto:[email protected]>> 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. > Sure, there's a bit of political or privacy argument involved here, that some people think "why does this need to be encrypted". There does seem to be a shift, however, to encrypting by default. The Mozilla blog post has a bunch of pointers in it for reasons and calls to encrypt by default: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ I don't expect to convince folks of that in this forum, nor to downplay the costs of doing this, and the challenges for interoperability. That said, so far today, only 0.015% of our outbound messages that were over an encrypted link were using SSLv3. At our volume, that's not nothing, unfortunately, but it's a pretty small amount to allow to continue to allow the possibility of breaking the rest. TLSv1 is still about 5%, way too high to deprecate at this point. Inbound is 0.1% at SSLv3, 37% at TLSv1. Also apropos https://tools.ietf.org/rfc/rfc7568.txt I know, this is somewhat off-topic for the DHE length, but there you go. Brandon
_______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop
