101–104 of 104 posts
Interesting to see the list of contributors from the various companies: Google, Inc, Yahoo!, Inc, Comcast, Inc, Microsoft, Inc, LinkedIn, 1&1 Mail & Media Development & Technology GmbH . One of my goals is to contribute to an RFC.
Join a working group mailing list and pay very close attention. Most of the work happens there, as opposed to at the 3x a year meeting.
Why do we need to add support for protocols individually for this? Can't we just introduce a TLS extension and an API for detecting these "always use TLS" requests in OpenSSL etc.?
SMTP starts in cleartext. That's the problem. You upgrade to TLS later. But only if the server says it can do that. A MITM attack can easily say that the receiver can't do TLS and thus can see everything that passes. This RFC specifies a way to prevent this, assuming clients abide by the requirements. It will be a long and slow roll out to get this done. But it is worth it.
Earlier quoted context omitted.
>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?
Earlier quoted context omitted.
Read the draft dude. STS is designed to interoperate with DANE. Also, if you deploy your STS info via DNS you'll need DNSSEC validation to to ensure that what you read in DNS is actually what the zone holder put there. Without DNSSEC how does a sending SMTP daemon trust the STS policy of the recipient zone. STS policies are stored in DNS TXT records, or their own new RR.
Pleaee don't be rude. STS doesn't preclude DANE, but it doesn't require it either. Meanwhile, this use case was the last remaining one motivating DANE at all.
Sure, if DNSSEC fail, then SMTP-STS is better than nothing.
I'm pretty sure that the big providers could have had deployed DNSSEC relatively easily, if they just wanted to.
I think other DNS-based email security features such as DKIM and DMARC motivates DNSSEC as well.