Excellent! Strict transport security for SMTP has been sorely needed. Once it's widely deployed, it will finally ensure that virtually all email communication occurs over TLS. TLS is already widely supported among large ISPs, but until now it has been far too easy to fall back to plaintext. There wasn't any way for a receiving ISP to ask all senders to use TLS and not fall back, which meant it happened occasionally.…
We are working to switch Haraka to use TLS by default in all systems. A big part of that is adding support for letsencrypt so that we can trivially create a secure outbound certificate for every mail. This stuff is important and we need to make email secure.
Internet Draft: SMTP Strict Transport Security
91–100 of 104 posts
Re: Internet Draft: SMTP Strict Transport Security
#92Excellent! Strict transport security for SMTP has been sorely needed. Once it's widely deployed, it will finally ensure that virtually all email communication occurs over TLS. TLS is already widely supported among large ISPs, but until now it has been far too easy to fall back to plaintext. There wasn't any way for a receiving ISP to ask all senders to use TLS and not fall back, which meant it happened occasionally.…
We are working to switch Haraka to use TLS by default in all systems. A big part of that is adding support for letsencrypt so that we can trivially create a secure outbound certificate for every mail. This stuff is important and we need to make email secure.
Re: Internet Draft: SMTP Strict Transport Security
#93Earlier quoted context omitted.
DNSSEC however has its own problems. I have been thinking of a DNSSEC2 proposal for a while now that for example would use online signing only.
The DNS root servers need offline signing. Many servers are in untrusted areas (think intervention from local government).
I think DNSSEC already deals with this by offline signing another key that actually signs the DNS root zone.
Re: Internet Draft: SMTP Strict Transport Security
#94Re: Internet Draft: SMTP Strict Transport Security
#95Excellent! Strict transport security for SMTP has been sorely needed. Once it's widely deployed, it will finally ensure that virtually all email communication occurs over TLS. TLS is already widely supported among large ISPs, but until now it has been far too easy to fall back to plaintext. There wasn't any way for a receiving ISP to ask all senders to use TLS and not fall back, which meant it happened occasionally.…
We are working to switch Haraka to use TLS by default in all systems. A big part of that is adding support for letsencrypt so that we can trivially create a secure outbound certificate for every mail. This stuff is important and we need to make email secure.
Re: Internet Draft: SMTP Strict Transport Security
#96Earlier quoted context omitted.
This seems like the slowest possible way to make no useful change. Literally every SMTP-capable software package on earth supports SMTPS on a dedicated port, which requires no changes to protocol. Why not just formalize and mandate this, instead of clinging to a braindead design that requires SMTP to munge the transport level? STARTTLS is a hack. It is not something to be preserved. If the goal is 100% TLS coverage,…
If you required TLS on all SMTP, you would in fact end up having to fail a large number of messages. Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it m…
>Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it may not be trusted for the domain.
This is madness, though. TLS is transport-layer security. It's not kerberos and it was never intended to be. The cert produced by the MX should be valid for the MX. Trust is an illusion, but to the extent that you decide to trust anything in the CA system, you trust it for the MX only and use SPF etc to determine if the MX is the correct one.
STARTTLS is a bad idea and should go away entirely. It forces an SMTP server to care about the transport layer, and that's entirely incorrect. I have plenty of SMTP servers that communicate on my networks without ever touching TCP/IP -- forcing them to support STARTTLS specifically is moving backwards.
This RFC is strongly dependent on the internet looking pretty much exactly like it looks today, and enforcing that mode of operation indefinitely. It's short-sighted and harmful to the entire email world.
Re: Internet Draft: SMTP Strict Transport Security
#97Earlier quoted context omitted.
If you required TLS on all SMTP, you would in fact end up having to fail a large number of messages. Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it m…
>Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it may not be trusted for the domain. This is madness, though. TLS is transport-layer security. It's not…
But I think the authentication problem is in fact the hard problem. Assuming we got rid of STARTTLS (the actual verb) and just always did TLS (say, on some other port), how do you propose to solve it?
Re: Internet Draft: SMTP Strict Transport Security
#98Earlier quoted context omitted.
The fact that DNSSEC is not universally deployed, yet secures important infrastructure in big organizations, would suggest your argument is false. In practice it is a bit more complex as DNSSEC is globally deployed and widely available, and that's a large part of the reason you can trust it. Any global initiative takes a full ten years to deploy as we've repeatedly seen.
What is the most important resource secured today by DNSSEC? I can name thousands of critically important resources that do not use DNSSEC. For instance: any credit card transaction you make on the Internet will not, at any step in the process, involve DNSSEC. The same is true of any stock order at any retail brokerage, or any FIX connection between an exchange and a broker/dealer.
I've worked with banks and financial institutions for quite a while, and I would never pretend to be that sure about one bank, let alone all of them.
You picked a bad example. I can assure you that the clearing following that very card transaction would involve DNSSEC at least at one point, at least at one bank.
Re: Internet Draft: SMTP Strict Transport Security
#99Earlier quoted context omitted.
Your arguments does not make sense as a coherent whole. Any one may not be wrong in itself, but the problems described are either not inherent to secure DNS, or are something that is much worse with every other proposal (including keeping today's system). 1. Your main argument is that the NSA and its cohorts have control over a handful of many top level domains available. But the same control that would allow them to…
I don't think many people want to read this deep into a tangent thread, so I'm going to keep my response very terse. 1. It's not my main argument, but, no: when a CA misbehaves, it is blacklisted (Google's done this). Google can't blacklist .com. 2. No. See FAQ. 3. No. See FAQ. 4. They can't do that if the certificate they're after is pinned. All they'll accomplish is getting the CA killed. 5. The thing DNSSEC secure…
1. That example is not very useful. It's hard to blacklist .com, but it's even harder to blacklist Verisign. (Which by the way runs all of .com, and they have full power to delegate any domain and any certificate to anybody. This is not a theoretical attack.)
2/3. If you mean the FAQ you wrote yourself, it's misleading at this very point.
4. Pinning is useful, but it isn't a PKI. It's equally useful no matter how you issue certificates.
5. Domain name delegation are one of the Internet's weakest points today. Crypographic assurance of domain ownership would be very useful for a number of reasons.
Re: Internet Draft: SMTP Strict Transport Security
#100Earlier quoted context omitted.
One could use a single certificate that is valid for all domain on the server
The client would still send the domain, since it doesn't known the server only has one certificate (the domain is sent in the first message, the ClientHello).
oh yes very true. Had not thougth of that.