Re: [ietf-smtp] SMTP Over TLS on Port 26 - Implicit TLS Proposal

Hello Viruthagiri,

Concerning DANE I propose you read RFC 6698, RFC 7218, RFC 7671, RFC 7672. The 
latter shall answer your question.

In your particular case, you have to find first a statement from Google, that 
they cannot disable anytime at their
disposal STARTTLS, and before this is done at your place I would not publish 
information that to your domain only
secured connections can be made.  In particular I would not publish MTA-STS 
information.

I have read the DANE RFCs long time ago and I do not remember every detail.  In 
theory you can publish the IP addresses
in charge for your emails under your domain and sign that A(AAA) records.  The 
hash of the used certificates is
published over TLSA.  However certificates are changed from time to time and 
before the change you have to publish in
DNS both the current and the next certificate, as you correctly recognized.  
Then wait until the next certificate is
distributed over DNS and only then switch the STARTTLS certificate.  So you 
need in this scenario also to know when the
certificates will be changed and to know the certificate that is going to be 
applied next.  I do not know whether this
information is published, but there are no compelling reasons not to do so.

If you want to get a feeling how SMTP works in practice I recommend you run 
your own mail server.  If you want to use a
provider, find one that matches your needs.

Regards
  Дилян


On Thu, 2019-01-10 at 11:40 +0530, Viruthagiri Thirumavalavan wrote:
> Hey all, I have some questions about DANE and I have some case to make 
> regarding my SMTPS proposal.
>
> I still can't wrap my head around DANE.  I understand DANE is trying to be 
> "your own CA". 
>
> DNSSEC already protects my DNS records from spoofing. So I believe all my DNS 
> records are secure when I enable DNSSEC. 
>
> My domain is dombox.org and if I have mx records like
>
> mx1.dombox.org
> mx2.dombox.org
> mx3.dombox.org
> mx4.dombox.org
> mx5.dombox.org 
>
> then those MX records are already protected from forgery since I have now 
> enabled DNSSEC. 
>
> Now I need to add DANE TLSA record to let the world know that my port 25 
> supports STARTTLS. So clients can detect downgrade issues.
>
> The TLSA records looks like this.
>
> 25._tcp.mx1.dombox.org. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx2.dombox.org. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx3.dombox.org. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx4.dombox.org. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx5.dombox.org. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
>
> I think we can can simplify that part via CNAME record. But, let's not go 
> there.
>
> Now my first question is, does that "fingerprint" adds any security in a 
> "Third party CA" system? Or it's there just to be compatible with the DANE 
> system since DANE is not a mail specific system? 
>
> My second question, if my MX records are configured to use google MX servers 
> (e.g. aspmx.l.google.com) whose job is to configure those DANE TLSA records?
>
> Google or Me?
>
> I believe it's not my job. Because there is no easy way I can have Google MX 
> server certificate fingerprint unless google provides it. Even if they 
> provide it, if google change their certificate for security reasons in the 
> future, then that's gonna break millions of domains that depends on Google 
> mail servers. So that would be a poor design.
>
> If I'm not wrong Google is against DNSSEC. So there is no way they are gonna 
> configure DANE records like this.
>
> 25._tcp.aspmx.l.google.com. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt1..aspmx.l.google.com. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt2.aspmx.l.google.com. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt3.aspmx.l.google.com. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt4.aspmx.l.google.com. IN TLSA 3 0 1 
> ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
>
> Hopefully, That is one of the reason why MTA-STS got introduced. 
>
> Even if I love DNSSEC and support it in my domain, Google sets the rules here 
> since I'm relying on their mail hosting. I have no other way, other than 
> supporting MTA-STS since google is against DNSSEC.
>
> Please correct me if I'm wrong with those statements.
>
> -------
>
> My above statements might be wrong. But if there is a slightest chance those 
> are true, isn't my design offers simpler version of the story?
>
> Step 1: If you wanna support port 26, make sure port 25 is secure too. Then 
> name your records with prefix "smtps-".  If you don't wanna support port 26, 
> but wanna secure only port 25, then name your records with prefix "starttls-" 
>
> Step 2: Enable DNSSEC. If you can't do that, just serve a txt file in a https 
> server (STS).
>
> First step should be treated as "Basic Security". And second step should be 
> treated as "Ultimate Security". 
>
> Isn't that simple there? 
>
> 1) No need to rely on DANE here. Just DNSSEC is enough. 
> 2) Google don't have to interfere with your decision here. You can go for 
> either DNSSEC or STS for authentication since Google's MX records gonna start 
> with "smtps-" prefix. If you don't go for DNSSEC or STS, it still fall under 
> "Basic Security"
> 3) TLSA, CNAME, SRV records very new to the people who used only MX records 
> before. They don't have to be forced to learn those new records since the 
> signalling is embedded in the MX records.
>
> MTA-STS needs a HTTPS server.  So you need a hosting and ssl certificates. 
> You can get both for free these days. For example my website is hosted in 
> Github. Github offers free hosting for simple html pages. And you can get SSL 
> certificates for free via LetsEncrypt. 
>
> But it's not about tech-savvy folks who knows things. It's about non-tech 
> savvy folks who just get started via services like GoDaddy. GoDaddy gonna 
> cross-sell hosting and ssl certificates for this reason rather than guiding 
> them to get hosting and ssl certificates for free. Why should they?. They are 
> a For-Profit company. If they start to recommend free alternatives then their 
> business gonna lose money. So the domain owners are forced to spend money 
> here.  MTA-STS should be a backup plan who are paranoid about DNSSEC. But It 
> shouldn't be the main plan.
>
> As for DANE. If a MX record that's protected by DNSSEC says 
> "aspmx.l.google.com", then i'm gonna validate the SSL certificate and make 
> sure the domain matches. Why do we need DANE for that? If the fingerprint 
> doesn't add any security value and used only for "we support STARTTLS" 
> signalling and designed that way only to be compatible with the DANE system, 
> then I think we are complicating things there.
>
> As for introducing SMTPS on port 26, I already lost the "security" argument. 
> I cannot go down that road again. 
>
> But we can't just ignore Implicit TLS just because it's gonna waste a port. 
> My proposal at least sends out the positive vibe that the IETF still cares 
> about email security. Right now by keep patching STARTTLS, we are only doing 
> "plastic surgery" to the SMTP security.  
>
> I'm not sure why people here not backing me up with my SMTPS proposal. The 
> only person that supports my cause here is Alessandro Vesely.  There are 
> plenty of people like him out there. They are just not here. 
>
> Since no one here to back me up other than Alessandro Vesely, I have to do 
> some research and bring some comments from the Internet. I'm gonna leave 
> those comments here, just to bring some thoughts on this. 
>
> Just to be clear, I'm not in anyway saying they are all right and you are all 
> wrong. I'm just trying to present my case here.
>
> And one more thing, I'm new to the IETF. If you are against my proposal and 
> you are one of the people behind MTA-STS and MTA-DANE related works, please 
> put that in the disclaimer while objecting my proposal. My proposal tries to 
> make the job easier for end user and trying to bring something new to the 
> SMTP world. I just don't want IETF to kill my proposal if people are all 
> biased. 
>
> Here are the comments I sourced from Hacker news.
>
> -------
>
> "The only (weak) argument I can find is that since servers that had a port 
> 465 open also had to keep a port 25 open for compatibility, you could perform 
> the same downgrade attack by blocking connections to port 465, which would 
> result in a submission to the port 25. But that's a "if it's broken let's 
> make sure it remains broken" kind of argument."
>
> https://news.ycombinator.com/item?id=17399079
>
> -------
>
> "How did these committees think that optional, downgradable encryption was 
> preferable to a standalone, encrypted only port (465)? Were they trying to 
> save server ports, like if it was a precious resource? Any design decision I 
> have seen regarding email since 2000 defies common sense. Like I heard most 
> SMTP implementations do not validate certificates. What good is an 
> unvalidated certificate? SPF is treated as indicative only or ignored."
>
> https://news.ycombinator.com/item?id=17398280
>
> -------
>
> "True, but the underlying question is still interesting: why isn't there a 
> similar TLS-only port for MTA-MTA and we all agree to try to connect there 
> first"
>
> https://news.ycombinator.com/item?id=17400554
>
> -------
>
> "I'm not a big fan of STARTTLS, I'd rather just have implicit TLS (All or 
> nothing) from the get go."
>
> https://news.ycombinator.com/item?id=17401895
>
> -------
>
> "I appreciate what they're trying to do, and it may improve the status quo, 
> but we've learned that the push away from implicit SSL/TLS and towards 
> STARTTLS was wrong. Using one insecure aspect (DNS) to note that you SHOULD 
> be able to do TLS with my mail server isn't a great solution.
> We need to revisit the STARTTLS vs implicit TLS debate in light of the 
> obvious vulnerability and overhead of starting with plain TCP connections and 
> then hopefully signalling towards security. HTTPS is obviously implicit TLS 
> and it works great. We know STARTTLS has issues. Can we not keep going down 
> the STARTTLS road for email, while going down the implicit TLS road for other 
> things?"
>
> https://news.ycombinator.com/item?id=17402701
>
> -------
>
> "The problem is partly because we don't have an assigned port for MTA2MTA 
> implicit TLS."
>
> https://news.ycombinator.com/item?id=17403441
>
> -------
>
> "The main problem with this is that STARTTLS is not anywhere near good 
> enough, but if it sees high adoption, nobody may bother with something better 
> in the future because they'll all think "Mission Accomplished.""
>
> https://news.ycombinator.com/item?id=17398335
>
> -------
>
> "I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was 
> running on port 465 many years ago.
> With many ISPs (and even some VPS) now blocking port 25, it could have been 
> an opportunity to migrate naturally towards the "new" unencumbered port."
>
> https://news.ycombinator.com/item?id=17397838
>
> -------
>
> "Perhaps fixing STARTTLS is one of those problems where the solution adds 
> even more problems (and moving parts)."
>
> https://news.ycombinator.com/item?id=17398783
>
> -------
>
> "So there was never really a dedicated TLS port for MTA to begin with?"
>
> https://news.ycombinator.com/item?id=17400128
>
> -------
>
> "Yes - it's a weak argument, and one that's probably been debunked by looking 
> the way https lifted off recently. My view is if port 465 was still around 
> today, it would probably get the same level of attention as port 443 has. We 
> could have been at a stage where port 25 could be made intentionally 
> unavailable (same way we move browsers from http to https) and everything 
> forced to 465. Email agent developers would be forced to update their 
> practices as well, no email should be sent over plaintext. At present, there 
> is no good way to tell your clients you're not accepting plaintext. STARTTS 
> is from a world where 99% of emails were plaintext."
>
> https://news.ycombinator.com/item?id=17399344
>
> -------
>
> "Apparently 465 is only for mail submission, not MTA-MTA -- but of course 
> that still leaves the obvious questions of a) why? b) if it must be a 
> different port, why not make that TLS-only?"
>
> https://news.ycombinator.com/item?id=17400568
>
> -------
>
> "See, at surface value I agree. But at a deeper level I don't. The problem is 
> too many broken protocols exist via RFC only (dns, smtp, etc). Rather than 
> violate that, or force it into something it's not, we should be writing 
> newer, better protocols. The friction against this is huge, mainly by those 
> who capped out at the previous RFCs, though. Email(well, smtp) itself is so 
> outdated and broken, I can't believe it's still so widely used."
>
> https://news.ycombinator.com/item?id=17398011
>
> -------
>
> "I'm sorry, but the problem is more complicated than that.
> SSL is not mandatory on either port 25 or 587, and SSL can not be made 
> mandatory if you follow the RFCs (it can be made mandatory if you tweak your 
> MTA, but you may lose some mail). Advertising for SSL over DNS means you 
> trust the DNS records - which you shouldn't without DNSSEC. Even with it, 
> there can be workarounds that in practice will allow MITMs.
>
> The only real solution is making SSL mandatory, and doing SMTP over SSL as in 
> the good old days of using stunnel on port 465 to decrypt, then netcat to 
> forward the output to the MTA running on localhost:25
>
> But that is not standard. Maybe the efforts would be better invested by 
> changing the standards to have a port where SMTP can not happen at all 
> without SSL - just like port 465 was, over 10 years ago."
>
> https://news.ycombinator.com/item?id=17397803
>
> -------
>
> "I agree with you, STARTTLS Everywhere is not "a problem". It is not a 
> solution either - at best a minor improvement."
>
> https://news.ycombinator.com/item?id=17397850
>
> -------
>
> "I consider myself very technical, and know my way around Windows and Linux 
> pretty well (I've used both for many years), but setting up a mail server is 
> something I do very infrequently and find complicated to get right when I do 
> so, especially when getting it working with TLS, DKIM, SPF and spam 
> filtering."
>
> https://news.ycombinator.com/item?id=17632545
>
> -------
>
> "It would be better to have a TLS connection right at the start. STARTTLS is 
> less secure. Why hasn't this happened for SMTP?"
>
> https://news.ycombinator.com/item?id=17631820
>
> -------
>
> "Because it's not backwards compatible, and would prevent delivery of a large 
> amount of email.
> We just need a way for domain owners to signal that their domains definitely 
> accept email over STARTTLS. At that point, senders which recognise those 
> signals can start to enforce that mail which they send to those domains MUST 
> use STARTTLS. Fortunately, those signalling methods are beginning to rise to 
> the surface. We have MTA-STS, and now also a preload list thanks to StartTLS 
> Everywhere."
>
> https://news.ycombinator.com/item?id=17632756
>
> -------
>
> "All you need is another port in addition to the regular SMTP port. They are 
> not mutually exclusive."
>
> https://news.ycombinator.com/item?id=17634344
>
> -------
>
> "That is completely insecure. A MITM would just block access to the 
> tls-on-connect port, forcing the sending host to retry on port 25, where they 
> would strip the STARTTLS advertisement.
> Unless you're recommending to not fall back to port 25 after a failed 
> connection to the tls-on-connect port. In which case, see the comment you 
> were replying to where I said it would be backwards incompatible.
>
> Both of the solutions I mentioned are backwards compatible, and protected 
> from a similar downgrade situation." (Refering to MTA-STS and StartTLS 
> Everywhere)
>
> https://news.ycombinator.com/item?id=17648703
>
> -------
>
> "Right, I should have said that I was recommending not ever sending on 25. 
> The STARTTLS mitm is just too easy for large attackers.
> IMHO, being backwards compatible is necessary for a transition period. The 
> messaging to SMTP operators should be... get on board, or you are going to 
> start losing mail in 1 year.
>
> Even Chrome is going to show all http as insecure in the very near future. 
> Which reminds me... I need to get all my sites upgraded."
>
> https://news.ycombinator.com/item?id=17655371
>
> -------
>
> "MTA-STS is pretty ill-conceived. In essence it mandates that compliant MTAs 
> also run a concurrent web service. The authors do not explain why this is 
> useful instead of the simpler approach -- enhance SMTP to reject mail on port 
> 25 with a NEEDS-TLS error, then fall back to implicit TLS (what port 465 was 
> originally for)."
>
> "The system needs to be able to authenticate a DNS-resolved endpoint. HTTPS 
> provides this.
> Of course, they could have gone with DNSSEC, but HTTPS has the virtue of 
> solving the same problem (modulo proper configuration), while also being more 
> widely deployed and better understood."
>
> "HTTPS does not provide authentication sufficiently well to put every egg in 
> its basket.
> As for "better understood," the authors of this standard work for Google, 
> Verizon, Microsoft, and Comcast. Combined they probably serve most of the 
> email in the western hemisphere.
>
> There is no excuse for overcomplicating a proposed standard -- and "we have 
> this stuff lying around" is no exception. This plan has the effect of causing 
> a networking protocol to depend on an entire series of unrelated networking 
> protocols.
>
> It does not bode well for the future of independent email operators and it 
> provides no path forward for integrating existing devices. It pushes many, 
> many extra steps onto client devices, necessitating entire additional 
> libraries of software to deal with them. That's not a problem for companies 
> with tens of thousands of developers at their beck and call -- but it is only 
> going to raise the barrier-to-entry of operating an independent service."
>
> "Those sound like reasonable objections. Are you posting them to the 
> discussions involved in shaping and ratifying the proposed standard?"
>
> https://news.ycombinator.com/item?id=16279241
>
> ------
>
> Back to the original discussion, I totally agree with Mark Andrews, Valdis 
> Kletnieks and others that Implicit TLS doesn't offer any additional security 
> than a downgrade protected STARTTLS. 
>
> But, you guys are like movie critics. You go to watch movies just to find 
> flaws. But an average movie goers go for entertainment.  For 20 years, we 
> already established with the fact STARTTLS is not secure. If you wanna sell 
> the same thing again by saying it's secure, then you have to go into detail 
> and explaining why it's secure. So I believe it's much easier to SELL 
> "Implicit TLS" is secure than STARTTLS is secure.
>
> My SMTPS proposal is an optional proposal. Nobody is forced to setup SMTPS. 
> People like me, Alessandro Vesely and many other hacker news users would love 
> to support Implicit TLS in SMTP even though the same level security can be 
> achieved via STATTLS. If something is better (at least in perceiving this), 
> why against it? Also note companies like google still do offer both Implicit 
> TLS and Opportunistic TLS for submission. So it can't hurt to have Implicit 
> TLS in SMTP too.
>
> My apologies for starting the discussion again. 
>
> Thanks
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp