On 1/7/19 2:09 AM, Viruthagiri Thirumavalavan wrote:
Alice thanks for the insight.
Rather than use a hostname to specify SMTPS only, how about a DNS TXT
record to indicate SMTPS only?
Third party mail hosting services usually provide services for millions
of domains. You are asking those millions of people to go for 1 more
step. I'm asking that step should be embedded in the mx hostname. Users
should do the steps as they did before, but now the mx records contains
smtps prefix.
They already will query for the existence of the MTA-STS record, and
likely have unbound or similar caching resolver running on the localhost
or at least at same hosting facility that caches the response to the query.
Why not just require STARTTLS if the TXT record for
_mta-sts.example.org. exists? They check for that anyway.
And if that DNS TXT record exists, rather than waste a < 1024 port
number, just have the MTA client use Port 25 with STARTTLS required.
Then it is just like MTA-STS except w/o the HTTPS component that
secures
the MX record.
But bottom line is to be RFC compliant, an MX host MUST accept on Port
25 without encryption.
You are worried about wasting a port. But I'm worried about bringing
full possible encryption to the SMTP. I have never heard of many of the
services found in < 1024 ports. You maybe too. So i'm pretty sure IANA
ok with assigning a new port to SMTPS.
I do want full possible encryption brought to SMTP. This is why I
encourage DANE for SMTP with MTA-STS as a backup for servers / clients
that do not implement DANE for SMTP.
The problem is solved.
My proposal is to being "Implicit TLS" to the SMTP relay. If you don't
allocate a new port, then people are not going to take the solution
seriously. And as you mentioned, an MX host MUST accept on port 25
without encryption. So you can do all the hack you want like STARTTLS,
port 25 is never gonna be treated as a fully secure protocol. Via
STARTTLS we are trying to provide "best effort" security. SMTPS can
provide "Full effort" security. That's the maximum possible security we
can provide. Top to bottom everything encrypted. We all moved to HTTPS
today. It will take many decades to completely move to SMTPS. Maybe 20
years. But if we worry about wasting a port today, then it's gonna take
forever.
You are missing the point.
It is up to MTA client to decide whether or not encryption should be
required. You can have your MTA client do that today, right now, without
needing to use a different port.
What you want is a client that gets its cue to go into that secure only
mode from the MX record, but that is an easily defeated trigger if the
MX record is not secured.
There are two ways to secure the MX record - DNSSEC and MTA-STS, both of
which then already require STARTTLS without needing a new port assigned.
There is also the STARTTLS Everywhere project which provides a GPG
signed json file of hosts you should require STARTTLS with. It is fairly
easy to turn that JSON fine into a Postfix policy map, I assume the same
applies to other MTA clients. That is a good temporary solution while
software/admins catch up with implementing DANE and MTA-STS in the MTA
clients and servers. And it does not require a new port.
Port 26 gives us nothing that a policy map file with domains we know
should require STARTTLS does not also give us.
How about instead of designating a new port, a "best practices" RFC is
created suggesting that MTA clients require STARTTLS when the the
MTA-STS record exists, whether or not the policy file can be
successfully retrieved by HTTPS?
That will allow system administrators who are having trouble setting a
web server for the MTA-STS policy file to still advertise they have set
up TLS on their mail server.
How about this:
When the MTA-STS DNS record has a serial number of 0 *and*
mta-sts.example.org domain name does not have an A or AAAA record, then
the MTA client SHOULD still require STARTTLS.
That would allow MTA clients to know they should at a minimum require
STARTTLS with mail sent to that domain, it would not require any DNS
queries beyond what is already required, and it would not require DNSSEC
or a HTTPS web server.
But MX admins should still do both DANE and MTA-STS whenever possible to
secure the MX record.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
