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

[Viruthagiri Thirumavalavan <[e-mail]>]

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.

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.

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.

The MTA client decides whether or not it wants to send without an
> encrypted session, the server MUST accept if the client chooses to
> connect without encryption.
> The MX server already has two different ways it can advertise to MTA
> clients they can safely require the connection to be secure, DANE for
> SMTP and MTA-STS. Both of those ways secure the MX record.


Both STS and DANE are not a solution for non-tech savvy folks. I'm gonna
hold-on to that point. My solution primarily try to deal with the SMTP
security. But I also incorporated STS and DANE as 2FA as you mentioned in
my revised proposal. But I made them optional. Not mandatory. If you make
them mandatory, then people are not gonna adopt due to its complicated
nature.

All you proposal seems to be offering is MTA-STS without a mechanism to
> secure the MX records.


In my updated proposal, I mentioned that you can use either STS or DANE to
protect MX records. I even gave example there.
https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#2fa

I just don't see a need for what is proposed. I do not understand the
> problem it solves.


It tries to make everyone upgrade to a new secure protocol in the long run.
But also tries to protect the STARTTLS downgrade attacks. As for
authentication, it leaves the job to both STS and DANE






On Mon, Jan 7, 2019 at 2:41 PM Alice Wonder <[e-mail]> wrote:

> Rather than use a hostname to specify SMTPS only, how about a DNS TXT
> record to indicate SMTPS only?
>
> 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.
>
> The MTA client decides whether or not it wants to send without an
> encrypted session, the server MUST accept if the client chooses to
> connect without encryption.
>
> The MX server already has two different ways it can advertise to MTA
> clients they can safely require the connection to be secure, DANE for
> SMTP and MTA-STS. Both of those ways secure the MX record.
>
> All you proposal seems to be offering is MTA-STS without a mechanism to
> secure the MX records.
>
> I'm perfectly with the recommendation that MTA clients require a secure
> connection if the DNS component of MTA-STS is present but the HTTPS
> component is not there.
>
> In fact I'm perfectly fine with MTA clients that refuse connections that
> do not offer STARTTLS regardless of whether the other server offers
> MTA-STS or DANE.
>
> I already do that! On web servers that are MTA client only. When a
> web-app user does a password reset, or anything else web-app account
> related, I do not want it modified in transit allowing easy NSA (or
> other) phishing access. So the receiving MX supports STARTTLS or the
> message is not sent.
>
> I don't need a different port number for that. And honestly it has never
> been a problem, never had a user account use an e-mail where the MX
> server did not offer STARTTLS. I'm sure they exist, but are not common.
>
> I just don't see a need for what is proposed. I do not understand the
> problem it solves. And securing the MX record (via DNSSEC or MTA-STS) is
> something that SHOULD be encouraged, whether or not you are aware of
> helicopters (helicopters is reference to link that argues DNSSEC isn't
> really needed because some military Generals didn't like technology that
> shot down helicopters)
>
> On 1/7/19 12:19 AM, Viruthagiri Thirumavalavan wrote:
> > Hey all, revised my draft based on the feedback I received from this
> > thread.
> >
> > Changelog:
> >
> > * Added starttls only support.
> > * Provided test cases for IDN names.
> > * Included Jim Fenton's proposal in the related projects section.
> > * No port hardcoding. Removed 26pref and 26only options. Now MX hosts
> > can start with either "smtps-" or "starttls-" prefix
> > * Solution can be used along with STS and DANE
> >
> > https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314
> >
> > Thanks
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.