Re: [ietf-smtp] why are we reinventing mta-sts ?

[Дилян Палаузов <[e-mail]>]

Hello,

On Mon, 2019-10-07 at 18:55 +0530, Viruthagiri Thirumavalavan wrote:
> (3) Not all end users have knowledge about how to configure an HTTPS server. This is the reason why most of them relying on third party mail hosting services like Gmail for hosting their mails. They can follow simple things like adding a DNS record. But configuring an HTTPS server is going to be a rocket science for them.   
> 

Much more people know how to configure an HTTPS server, than to configure a SMTP server (with STARTTLS).  So configuring
HTTPS is not an obstacle.  Since, soon or late a mail server operator will want to reject emails that fail DMARC
validation, the operator will have to learn DKIM.  Then set some custom email rules, AV/AS and so on.  Setting up HTTPS
(and a web-based mail client) looks trivial compared to the remaining pieces.

The HSTS (http strict transport security) preload list, https://hstspreload.org/, is knowledge in HTTP browsers, about
sites, which serve content explicitly over HTTPS.  Browsers use the knowledge and do not contact the hosts under the
listed domains over pure HTTP.

Similar to it, there is a MTA-STS (smtp strict transport security) preload list: a set of hosts, which can serve SMTP
over TLS.  The list is hosted at https://starttls-everywhere.org/ .  This list functions just like HSTS preload list,
but for port 25.

Talking about SMTP and TLS is bi-fold.  There are incoming and outgoing connections.  Depending on the MTA, setting up a
MTA that applies DANE for outgoing connections can be done very easily, so in the context of outgoing connections,
utilizing DANE/DNSSEC can be easier than MTA-STS.

Installing the MTA-STS preload list on the own MTA, and using it for outgoing connections, can be easier than
configuring MTA-STS for outgoing connections.

Deploying/enforcing DANE for outgoing connections is equally hard compared to deploying MTA-STS for outgoing
connections, when the used MTA offers neither features.

To sum up, the options in the MTA are:
* for outgoing connections:
  - check MTA-STS (without necessary publishing own MTA-STS records)
  - check DANE (without having deployed DNSSEC for the own domain)
  - check the STARTTLS-everywhere preload list for the destination host
  - consider sending your own certificate during establishing the TLS tunnel (nearly nobody does this)

* for incoming connections:
  - publish MTA-STS records
  - publish DANE records, once DNSSEC is set up
  - add an entry in the MTA-STS preload list

* for both: speak TLS 1.3 .

What are the pros and cons of sending the certificate of the SMTP client to the SMTP server, during STARTTLS?

Regards
  Дилян