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