On Mon, Sep 19, 2016 at 10:44:52AM -0700, Jim Fenton wrote:

> > Delivery is not prioritized over security when the sending domain's
> > policy requires TLS for the given destination; or when the receiving
> > domain publishes DANE or (less reliably for initial delivery) STS
> > policy.  What's opportunistic in the presence of DANE or STS is the
> > use of the stronger requirement dynamically, destination by destination,
> > via discovery of the destination's policy.
> 
> It's still opportunistic from the standpoint of a user sending a message
> and asking whether the message will be transmitted securely.

Actually, it is not, provided the destination domain has published
DANE (or perhaps some day STS) policy.  The user may not know which
domains have done that, though some email providers are making an
effort to expose such information to their users (e.g. at least
Postini).  The outbound MTAs of postini.de, gmx.de and others
enforce DANE policy when published by the destination domain.

> A large
> provider is very unlikely to broadly establish policies requiring TLS
> for their outgoing messages, even for specific destination domains,
> because of the possibility that something will break (e.g., certificate
> expiration) and cause their outgoing mail to queue.

And yet a few large providers already have done exactly that.

> Also, that only applies for the first hop.

Indeed.  That's the nature of opportunistic security, you get only
as much security as is possible.  See RFC7435.  In the majority of
cases there are clear benefits to not raising the bar too high.

Keep in mind that the "first hop" if often the last hop over the
public Internet.  Further hops are often internal to the receiving
network, and the threat is then much lower, and use of TLS is likely
mandatory (if ones bothers to publish externally facing DANE TLSA
records, it makes sense to protect all internal links).

-- 
        Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to