f



SMTP MTA Strict Transport Security ?

Is anyone experimenting with SMTP MTA Strict Transport Security (SMTP MTA_STS) yet ?

It is being worked on as part of IETF UTA working group and can be seen in the Active Internet-Drafts section of https://datatracker.ietf.org/wg/uta/documents/

Is this likely to be made part of sendmail itself or handled by a milter ?

--Dave
0
mrludo001
7/27/2016 1:53:42 AM
comp.mail.sendmail 13518 articles. 1 followers. jfretby (35) is leader. Post Follow

3 Replies
172 Views

Similar Articles

[PageSpeed] 11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, 26 Jul 2016 18:53:42 -0700, mrludo001 wrote:

> Is anyone experimenting with SMTP MTA Strict Transport Security (SMTP
> MTA_STS) yet ?

https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/?include_text=1

"SMTP MTA-STS policies are distributed via a "well known" HTTPS endpoint
in the Policy Domain.  A corresponding TXT record in the DNS alerts
sending MTAs to the presence of a policy file."

This is still subject to a downgrade attack by corrupting the receiver's
DNS resolver to eliminate or modify the _mta_sts.example.com txt record.

DANE closes that hole via DNSSEC.

For those that are interested in sendmail/dane/dnssec :

http://www.five-ten-sg.com/mapper/blog/dane


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAleYLeoACgkQL6j7milTFsE6hACeIwiUC9Addp2kZipl6M2L+EjS
4nsAoIQIDugXj1+qxgFUNriyAURp6xmw
=FGYD
-----END PGP SIGNATURE-----
0
Carl
7/27/2016 3:47:21 AM
Hi Carl,

Thanks for the input.  Section 2 of draft-ietf-uta-mta-sts-01 discusses DANE vs MTA-STS .

--Dave
0
mrludo001
7/27/2016 5:07:59 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, 26 Jul 2016 22:07:59 -0700, mrludo001 wrote:

> Thanks for the input.  Section 2 of draft-ietf-uta-mta-sts-01
> discusses
> DANE vs MTA-STS .

Yes, the quote is from that section. The point is that if you start with
an insecure DNS lookup, you cannot really enforce *mandatory* tls
encryption.

Consider
example.com.       MX 10 mail.example.com.
mail.example.com.  A  192.168.1.1

If you do want to use an insecure DNS lookup to close some of the holes
in opportunistic tls, I think it is better to use:

_25._tcp.mail.example.com. TLSA 3 0 1 ....

rather than:

_mta_sts.example.com TXT "v=STSv1; id=randomstr; ...."

Both of those records (TLSA and TXT) are fetched via an insecure DNS
lookup but the mta_sts TXT record also requires an auxillary HTTPS
server. You could (via local policy) simply extend DANE to obey the
constraints implied by that TLSA record, even though example.com is not
secured with DNSSEC.

That option is in my sendmail patch. This allows folks that (for
whatever reason) don't secure their zones with DNSSEC, to at least
publish an indication of the expected tls usage of their incoming mail
servers. And when they do upgrade to DNSSEC, they get the full DANE
protection.

With respect to mail, we already publish public cryptographic keys for
dkim via insecure DNS TXT records, and those keys can be used by mail
receivers. We can also publish public cryptographic tls keys via
(hopefully secure) DNS TLSA records, and those keys can be used by mail
senders to validate the connection to the mail receiver.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAleYzsIACgkQL6j7milTFsExJgCfQ+xOTBjhEDxeoVZ3+yQoB/o7
2bMAn0WQ6d7tYvemHuLxApRNbMRQJdrZ
=ahx+
-----END PGP SIGNATURE-----
0
Carl
7/27/2016 3:10:36 PM
Reply: