A better way to do secure SMTP

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

A better way to do secure SMTP

Alice Wonder
Maybe better, I do not know. I do not know right place to recommend
this, I hope it is not too out of place here.

Opportunistic TLS is a concept I do not like. DANE fixes the issues for
system admins willing to implement DNSSEC and add a TLSA record but it
seems many are not, so MTA-STS was invented.

MTA-STS has the same flaw as opportunistic TLS. It uses an insecure
channel to determine if it should use a secure channel.

If Mallory can eavesdrop and MITM the message from Alice to Bob, then
Mallory can likely alter the DNS responses and thwart MTA-STS either by
saying the needed DNS record for MTA-STS does not exist, and possibly
doing the same for the A/AAAA records for the specified subdomain used
for MTA-STS if the server checks them anyway.

A better solution is to bring back Port 465 and SMTPS.

When Alice connects to Bob on Port 465, the certificate MUST validate in
one of two ways:

A) DNSSEC validated TLSA record
B) Trusted CA with Certificate Transparency and OCSP stapled

If a DNSSEC validated TLSA record exists, then either it validates or
the connection drops and bounces as undeliverable.

If no DNSSEC secured TLSA record exists, then B is used. Failure to
validate likewise results in message undeliverable.

Port 25 is only used if Port 465 is not listening *and* no TLSA record
exists for Port 465.

For servers that do not use DNSSEC, they can optionally send a response
on first successful to Port 465 telling the client to never connect via
Port 25 similar to how HSTS works, so that if a future attack blocks
Port 465, Port 25 would not be tried until X days had passed.

This solution takes opportunistic completely out of the equation for
servers that use DANE and for servers that don't use DANE, allows them
to send a command upon first successful connection that takes future
opportunistic out of the equation.

The *only* think MTA-STS does for non DNSSEC users that this doesn't do,
MTA-STS does provide a somewhat secured list of MX hosts, but only if
the A/AAAA record response is not modified by the attacker.

If this has merit, who do I submit it to?
Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

Viktor Dukhovni


> On Nov 1, 2018, at 3:48 PM, Alice Wonder <[hidden email]> wrote:
>
> Maybe better, I do not know. I do not know right place to recommend this, I hope it is not too out of place here.
>
> Opportunistic TLS is a concept I do not like. DANE fixes the issues for system admins willing to implement DNSSEC and add a TLSA record but it seems many are not, so MTA-STS was invented.

Opportunistic TLS is highly effective at reducing opportunities for
passive monitoring.  It is good to do better when possible, and both
DANE and (less effectively) MTA-STS tackle active attacks, but do not
knock opportunistic TLS, it has achieved considerable privacy gains.

> A better solution is to bring back Port 465 and SMTPS.

Port 465 is back, but for SUBMIT, not for MTA-to-MTA SMTP, and
that's not going to change.  Sorry.

If we could reliably know which MTAs support your proposal and
which domains have which MTAs, we would not need DANE or MTA-STS.

Just conjuring up another port does nothing to address the fundamental
issues.  There's not going to be an SMTP flag day when everyone switches
to mandatory TLS at the same time.  Nor will MX records magically become
resistant to MiTM in the absence of DNSSEC.

My advice is to accept the current state as a transitional phase to
to potentially more secure email in a decade or so from now.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

Alice Wonder
On 11/01/2018 01:00 PM, Viktor Dukhovni wrote:

>
>
>> On Nov 1, 2018, at 3:48 PM, Alice Wonder <[hidden email]> wrote:
>>
>> Maybe better, I do not know. I do not know right place to recommend this, I hope it is not too out of place here.
>>
>> Opportunistic TLS is a concept I do not like. DANE fixes the issues for system admins willing to implement DNSSEC and add a TLSA record but it seems many are not, so MTA-STS was invented.
>
> Opportunistic TLS is highly effective at reducing opportunities for
> passive monitoring.  It is good to do better when possible, and both
> DANE and (less effectively) MTA-STS tackle active attacks, but do not
> knock opportunistic TLS, it has achieved considerable privacy gains.
>
>> A better solution is to bring back Port 465 and SMTPS.
>
> Port 465 is back, but for SUBMIT, not for MTA-to-MTA SMTP, and
> that's not going to change.  Sorry.
>
> If we could reliably know which MTAs support your proposal and
> which domains have which MTAs, we would not need DANE or MTA-STS.
>
> Just conjuring up another port does nothing to address the fundamental
> issues.  There's not going to be an SMTP flag day when everyone switches
> to mandatory TLS at the same time.  Nor will MX records magically become
> resistant to MiTM in the absence of DNSSEC.
>
> My advice is to accept the current state as a transitional phase to
> to potentially more secure email in a decade or so from now.
>

Both opportunistic TLS and DANE secured TLS could still be supported on
Port 25 allowing a staggered adoption until such time that the majority
of mail servers implement it.
Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

Viktor Dukhovni
On Thu, Nov 01, 2018 at 01:15:04PM -0700, Alice Wonder wrote:

> > My advice is to accept the current state as a transitional phase to
> > to potentially more secure email in a decade or so from now.
> >
>
> Both opportunistic TLS and DANE secured TLS could still be supported on
> Port 25 allowing a staggered adoption until such time that the majority
> of mail servers implement it.

Sorry, it can't be turtles all the way down.  Anything that can
reliably signal a mandatory security policy for port 465, can with
less disruption do the same for port 25.  And port 465 is already
taken for SUBMIT, it is NOT an inbound relay port.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

Alice Wonder
On 11/01/2018 01:35 PM, Viktor Dukhovni wrote:

> On Thu, Nov 01, 2018 at 01:15:04PM -0700, Alice Wonder wrote:
>
>>> My advice is to accept the current state as a transitional phase to
>>> to potentially more secure email in a decade or so from now.
>>>
>>
>> Both opportunistic TLS and DANE secured TLS could still be supported on
>> Port 25 allowing a staggered adoption until such time that the majority
>> of mail servers implement it.
>
> Sorry, it can't be turtles all the way down.  Anything that can
> reliably signal a mandatory security policy for port 465, can with
> less disruption do the same for port 25.  And port 465 is already
> taken for SUBMIT, it is NOT an inbound relay port.
>

Doesn't have to be 465. The point of different port than 25 is it makes
it easy to keep 25 as the status quo opportunistic for backwards
compatibility while phasing in SMTPS that only allows secure connection.

Using a different port allows changes to STMP that are not backwards
compatible with current SMTP to potentially fix other legacy issues,
potentially even some that reduce ability to spam.
Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

Bill Cole-3
In reply to this post by Alice Wonder
On 1 Nov 2018, at 15:48, Alice Wonder wrote:

> Maybe better, I do not know. I do not know right place to recommend
> this, I hope it is not too out of place here.

This list reaches a minority of Postfix admins, who are a minority of
mail system admins, who are a minority of people with strong interests
in the technical security aspects of email.

The IETF "uta" working group may be an even smaller minority of the
people with strong interests in the technical security aspects of email,
but at least there you would reach a more diverse subset and your idea
would be squarely on topic.

https://datatracker.ietf.org/wg/uta/about/

I agree with every one of Viktor's critiques, which have been valid
critiques of many incomplete and unworkable concepts of how to "fix
email" over the past 20+ years. Here on a list made up mostly of people
running production mail systems and maintaining tools for such systems,
you will find both disinterest in an idea that does not exist as
deployable code (or even as an implementable protocol) and active
skepticism of doing today what Microsoft tried and failed to do 20+
years ago with port 465. The uta-wg community may be less jaded and more
interested in helping move an embryonic concept towards something
useful.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

Alice Wonder
On 11/01/2018 02:40 PM, Bill Cole wrote:

> On 1 Nov 2018, at 15:48, Alice Wonder wrote:
>
>> Maybe better, I do not know. I do not know right place to recommend
>> this, I hope it is not too out of place here.
>
> This list reaches a minority of Postfix admins, who are a minority of
> mail system admins, who are a minority of people with strong interests
> in the technical security aspects of email.
>
> The IETF "uta" working group may be an even smaller minority of the
> people with strong interests in the technical security aspects of email,
> but at least there you would reach a more diverse subset and your idea
> would be squarely on topic.
>
> https://datatracker.ietf.org/wg/uta/about/
>
> I agree with every one of Viktor's critiques, which have been valid
> critiques of many incomplete and unworkable concepts of how to "fix
> email" over the past 20+ years. Here on a list made up mostly of people
> running production mail systems and maintaining tools for such systems,
> you will find both disinterest in an idea that does not exist as
> deployable code (or even as an implementable protocol) and active
> skepticism of doing today what Microsoft tried and failed to do 20+
> years ago with port 465. The uta-wg community may be less jaded and more
> interested in helping move an embryonic concept towards something useful.
>

Thank you, I'll look at that list.

To me, DNSSEC + TLSA "fixes" e-mail.

But there's a lot of resistance to DNSSEC, for some reason some key
people really don't like it and have put out a lot propaganda against
it, and aren't going to use it.

MTA-STS is a solution they come up with that when I look at doesn't
actually solve anything while at the same time sending the message that
DNSSEC isn't really needed. It's a bad broken solution (just like HPKP
was a bad broken solution).

I'm just looking for something for those who refuse to embrace DNSSEC
that at the same time doesn't discourage the use of DNSSEC.

I'll bring it to that list.
Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP

@lbutlr
In reply to this post by Alice Wonder
On 01 Nov 2018, at 13:48, Alice Wonder <[hidden email]> wrote:
> Opportunistic TLS is a concept I do not like. DANE fixes the issues for system admins willing to implement DNSSEC and add a TLSA record but it seems many are not, so MTA-STS was invented.
>
> MTA-STS has the same flaw as opportunistic TLS. It uses an insecure channel to determine if it should use a secure channel.

Since the MTA tp MTA communication does not involve secure information like logins, passwords, etc, there is no issue with either opportunistic TLS nor with using an insecure channel to determine if security should be used.

After all, if the encryption fails, the mail is sent in the clear.


--
It was a fifty-four with a mashed up door and a cheesy little amp with a
sign on the front said "Fender Champ" and a second-hand guitar it was a
Stratocaster with a whammy bar

Reply | Threaded
Open this post in threaded view
|

Re: A better way to do secure SMTP (closing the thread I hope...)

Viktor Dukhovni
> On Nov 2, 2018, at 12:43 AM, @lbutlr <[hidden email]> wrote:
>
> After all, if the encryption fails, the mail is sent in the clear.

I think we should stop here.  This thread is getting off track.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Secure DNS (was: A better way to do secure SMTP)

Wietse Venema
In reply to this post by Alice Wonder
Alice Wonder:
> I'm just looking for something for those who refuse to embrace DNSSEC
> that at the same time doesn't discourage the use of DNSSEC.

The DNSSEC workarounds keep coming: a recent example is DNS over
HTTPS, a.k.a. DoH. It's off-topic for this list. though.

        Wietse