On Mon, Sep 14, 2015 at 11:32:57AM +0800, Ken Peng wrote:
> You are exactly right, we are talking about securing inbound mail.
So finally we have a clear problem statement.
In that case, firstly inbound email is always port 25. Barring
special-case manual routing agreed by both parties, email is relayed
to the MX hosts of the nexthop domain on port 25.
Secondly, the protocol on port 25 is cleartext SMTP, with STARTTLS
as a possible negotiated transition to TLS. This transition is
typically "opportunistic" and unauthenticated, see RFC3207 and
RFC7435.
When both sides support STARTTLS, they'll generally negotiate a
TLS connection that is protected against passive wiretap, but
not active attack. For details see:
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
Some domains are beginning to deploy opportunistic DANE TLS for
SMTP as defined in the above draft (soon RFC). This can provide
greater protection against active or man-in-the-middle (MiTM)
attacks.
If your domain's MX RRset is secured with DNSSEC, and the MX hosts
similarly lie in a signed zone (perhaps the same zone as the email
domain), then you can publish TLSA records for the MX hosts, which
allow clients that implement DANE to authenticate your server and
mitigate various MiTM attacks.
The key thing to remember is that publishing TLSA records carries
the operational burden of not messing up the validity of the records
when/if you update your SMTP server certificates. Sites that can't
implement reliable operational procedures to coordinate TLSA record
updates with server certificate updates SHOULD NOT publish TLSA
records.
# Cert/Key rotation
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.4
# Recommendations for DANE-EE(3) and DANE-TA(2) "certificate usages"
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-5.1
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-5.2
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.1
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.2
# Avoid PKIX-EE(1) and PKIX-TA(0) "certificate usages"
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-4.1
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.3
# DO NOT make STARTTLS access "selective", available to just
# "known good" SMTP clients.
#
https://dane.sys4.de/common_mistakes#3
# Read about other mistakes to avoid
https://dane.sys4.de/common_mistakes
Publishing TLSA records allows other servers to authenticate your
domain. If you want to use DANE to authenticate remote domains,
you'll need to:
+ Deploy a *local* DNSSEC validating resolver on each "edge"
outbound MTA. This resolver would listed on 127.0.0.1 or
similar loopback address, implement RFC5011 root trust-anchor
rollover, and be reasonably current to avoid legacy bugs.
+ List *only* that local resolver in /etc/resolv.conf and
any chroot jail copies.
+ Deploy Postfix 2.11 or later.
+ In the main.cf file set:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
See http://www.postfix.org/TLS_README.html#client_tls_dane
> >If so, why were you asking port 465? That's a legacy (and perhaps
> >also future) submission service for mail *from* your users to other
> >domains, not from other domains to your users.
>
> Sorry I was just not sure, if peer MTA (not MUA) can delivery messages to us
> from port 465 (SSL enabled).
Inbound mail is on port 25, remote MTAs WILL NOT connect to port
465 which is for submission not relaying to the nexthop.
> Also our commercial domain is not cloud-china.org (this is the one just for
> my personal usage). From the company's policy I can't say whom i was serving
> for.
I did not ask for that.
> >What's possible and what's best-practice depends on the details.
>
> * We are public MX hosts, there are hundreds of them as I have said. they
> are deployed as distributed architecture.
> * They are neither internal MX nor relay.
> * For delivery agent we in fact wrote our own ones,not opensource, b/c our
> storage service are not opensource, but with our own storage architecture.
> * not private MX, you can just think we are Yahoo/AOL etc, we have the user
> base near to them.
That's clear now. You SHOULD enable STARTTLS on port 25, if you
haven't already. Consider publishing DANE TLSA records, but only
if you can do it right, nobody benefits from badly implemented TLSA
records. Consider enabling DANE for outbound mail, but be prepared
for occasional domains that misconfigure their TLSA records.
My hope is that some of the earlier adopters of outbound DANE
authentication will be very large providers that can "stand firm"
in the face of misconfigured receiving systems and place the burden
of resolving problems on the receiving side.
That way, instead of everyone else having to work-around breakage
on domains that can't get key rotation (etc.) right, broken TLSA
records and certificates are treated just like any other operational
failure that makes the remote party unreachable.
Some large German email providers have said they'll enable DANE
soon. I hope they'll refuse to make exceptions for broken remote
systems, and will expect such breakage to be fixed by the guilty
party.
--
Viktor.
