> On Mar 12, 2019, at 8:01 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> I'm sorry, but I don't see how any of this is meaningfully different from the
> situation with HSTS. In both cases, the receiving system indicates that
> the sending system ought to use secure transport, and if the sending
> system conforms to the specification providing that indication, it is
> required to use secure transport. See:
> https://tools.ietf.org/html/rfc8461#section-5
The difference is that MTAs with published DANE and MTA-STS policies
nevertheless in the majority of cases still accept email not only
from senders who don't do DANE or MTA-STS (and use unauthenticated
opportunistic STARTLS), but also in cleartext!
Unlike HSTS where the port 80 website typically only serve the HSTS
policy and a redirect to HTTPS, the MTA's published DANE or MTA-STS
policy is an offer of support for security delivery to the sender,
it is NOT a mandate.
The normative MUSTs in e.g. the DANE SMTP RFC are there to ensure that
senders implement DANE correctly *when* they choose to do that, and don't
do something half-baked leading to a false sense of security.
There is no expectation that DANE preëmpts sender policy, and MTAs use
whatever rules they have for a particular "envelope" to determine the
relevant security policy. The present draft just adds an important
signal from the sending user.
My perspective on the SMTP security landscape is based on 18 years of
Postfix development and a decade as Postmaster at Morgan Stanley where
among other activities (email for the Google IPO) I managed mandatory
TLS peering with many business partners, and saw first hand what it
takes to deal with all the edge-cases. Email is different from the Web,
and experience learned in one doesn't always carry over to the other.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
