[Starttls-everywhere-devs] STARTTLS call 3/7/19

[Vladislav Yarmak]

>  * Improvements: hosting multiple smtpd instances on one box? Let me
> know if you have ideas on how to do this.

Could you provide an example of such setting and highlight a problem
with it?

>    * Is there a reasonable way we can also measure sending MTA-STS
> support?

We can provoke tested mailserver to send an email to knowingly bad
domain with missing or incorrect TLS support. If email has been
delivered it means sending domain ignored MTA-STS policy of recipient
domain (or failed to fetch it, but it is not much probable).

There are two ways to do that:

- If tested email domain is a public service, we can register account
  and legitimately send email.
- If tested email domain has bounce for non-delivered emails, we can
  send email to non-existent address and catch bounce. This way can be
  automated pretty easily, but it may increase spam rating of sending
  domain.

Taking into account there are very few domains advertising "enforce"
MTA-STS support, it may be viable option. At least we can conduct
such tests for most popular public email services, undertaking vast
majority of email communications. Also, if test fails, now we have good
place for such domains (starttls.party).

>    * Flagging some proposals from community about securing some more
> DNS lookups via list: onion mxs and "DANE supporters":
> 	* Securing SRV record lookup for onion mailserver discovery
> 	* There are a number of email hosting providers that support
> DANE. Some mail domains that use these hosting providers, however,
> don't or can't DNSSEC-sign their MX RRset. We could secure the MX
> lookup for those domains.
> 

Great ideas! But TOR and DANE support is some sort of different story
for following reasons.

Current policy, in fact, declares restrictions for end-entity
certificate of MX representing domain. In order to add protection for
cases above we have to list statements about MX sender should use to
deliver email to domain. This barely noticeable difference has strong
implications. In practive, we have to bind transport for domain
instead of its TLS policy. In terms of Postfix it's transport maps, and
for Exim it probably will be manualrouter. Though, I'm not sure if MTAs
will resolve TLSA as expected for preconfigured domains. But good news:
we have a chance to implement it for larger set of mailservers than
current TLS policy specification. Bad news: it will make STARTTLS
Everywhere support inconsistent across mailservers if we'll try to
implement it as part of STARTLS-E. Summary: this feature may cover
different set of mailservers; entirely different kind of statements in
policy required.

TOR mail doesn't needs TLS at all since .onion address already tied to
servers public key and all communications already encrypted and
authenticated. There is a small exception: .onion addresses may have EV
certificates, but email communication doesn't benefit from EV status of
certificate. Typical use case of TOR is quite opposite: it is created
for anonymity. Summary: no TLS for TOR.

It's a matter of argument whether we should require MTA-STS support for
MX binding for DANE and TOR. DANE and TOR are self-sufficient in terms
of cryptography. It worth noting that in first place MTA-STS is
introduced as weaker substitution for DANE which "does not require
DNSSEC, at a cost of risking malicious downgrades" (RFC 8461 says
that). Also both DANE and TOR do not (or not necessarily) rely on
Certification Authorities and requirement to do so looks superfluous.
Of course, TOR- and DANE-enabled mailservers may benefit from MTA-STS
if their peers do not support DNSSEC (DANE) or sending emails via
clearnet (TOR). But in this case such peers are not subject of those
technologies and can be considered in terms of already established
STARTTLS-E policies. Summary: probably some other type of validation
required on domain submission for purpose of creating bind between
domain and MX. Probably continuous check of some TXT records and
emailing to postmaster about ongoing inclusion process will do.

Taking all the aforesaid into consideration, these features are
appearing to be orthogonal to what STARTTLS-E already does. Mostly,
because of incoherence in entities and restrictions. It is worth
considering implementing it as separate project. Attempt to find common
denominator for all email security mechanisms in STARTTLS-E project may
setback it's already long-lived development process from completion.

I'll let myself to add some pragmatical considerations, hoping to give
you more context for decision about priority of this features. TOR has
been designed for Internet anonymity and .onion service is really a
thing hard to pinpoint. But _onion-mx records effectively ruin this,
degrading TOR and using it as just another secure transport, since they
are connected to real domain with real owner. The only new advantage
such technology brings in is capability to hide fact of email
communication between two TOR-enabled public-facing email domains. On
the other hand, deployment of STARTTLS-E or MTA-STS promises email
transport security for everyone, including countries where TOR is
mostly nonoperational.

DANE is based on DNSSEC, and it looks like DNSSEC is slowly dying.
Number of DNSSEC-validating users reached its peak in 2016 and now
declining:
https://blog.apnic.net/2018/02/26/peak-dnssec/
Some sources also indicate decline of DNSSEC-signed domains share.
MTA-STS itself is also (inequal) replacement for DNSSEC.

By the way, if you feel sad about DNSSEC, then don't! There is another
fine post in APNIC blog with fresh idea how DNS over TLS may replace
DNSSEC if it also will be enabled between resolver and authoritative
server:
https://blog.apnic.net/2018/08/17/sunrise-dns-over-tls-sunset-dnssec/


-- 
Best Regards,
Vladislav Yarmak