> On Mar 12, 2019, at 11:00 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> 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.
>
> Surely you're familiar with the term "argument from authority".
Yes, and also quite aware that FWIW, that's in part the argument I'm
making. The idea is that am I am not just citing the dead trees that
only loosely capture the spirit of the specifications. Having written
the DANE specification, crafted its first MTA implementation, and worked
hard to see it adopted, I think that while any authority I may bring to
this is by no means dispositive, it still should carry some weight, and
ought to be considered, among whatever other factors you might find
relevant.
Bottom line, while working with the Postfix and broader email community
to bring greater transport security to email, my read is that senders
do not view anything that recipient systems might publish as a mandate
that preëmpts their policy options.
Indeed my experience tells me (as e.g. explained in RFC7435) that we get
greater adoption of security systems when we give participants a range of
options and not just once size fits all.
While a higher fraction of Web traffic than email traffic is *strongly*
protected with authenticated TLS, a larger fraction of email traffic
than Web traffic is protected from passive monitoring, because support
for unauthenticated STARTTLS was easier to deploy and operate.
With Let's Encrypt, HTTP is now starting to catch up on TLS adoption, but
some have rightly noted that it has also become much easier for various
MiTM attackers to obtain fraudulent DV certificates. We're seeing an
unsurprising tradeoff between ubiquity and security.
We should not deny senders the opportunity to take sender preference
into account, this will ease the adoption path to greater security,
and will help to make security more deployable. Strong security that
only a few deploy is ultimately not a success story. Sometimes (e.g.
Let's Encrypt) we compromise in the name of ease of deployment.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
