On Tue, Nov 10, 2015 at 04:41:40PM +0100, Simon Josefsson wrote:
> > You may reasonably
> > claim that those criteria are almost never satisfied today and
> > that almost all TLS connections between SMTP sender and SMTP
> > receiver are made in the same casual way that almost all HTTPS
> > ones are.
>
> That is far from true -- all significant web browsers out there validate
> HTTPS certs against a pre-distributed CA bundle, and reject connections
> when that fails. SMTP servers in general never reject connections when
> cert checking fails. You may argue that CAs perform casual checking,
> but it is distinctly better than permitting any certificates as in the
> SMTP world.
I agree that browsers meticulously check DV certificates that are
well worth their $0.00 price. As for SMTP's "casual way" and HTTP's
"distinctly better" alternative, these mischaracterizations gloss
over fundamental differences between MTA-to-MTA SMTP and browser
to web server HTTP.
https://tools.ietf.org/html/rfc7672#section-1.3
With HTTPS, TLS employs X.509 certificates [RFC5280] issued by one of
the many CAs bundled with popular web browsers to allow users to
authenticate their "secure" websites. Before we specify a new DANE
TLS security model for SMTP, we will explain why a new security model
is needed. In the process, we will explain why the familiar HTTPS
security model is inadequate to protect inter-domain SMTP traffic.
Please read Section 1.3 and subsections. Please understand that
the existing (RFC 3207) use of TLS in SMTP is in the vast majority
of cases unavoidably opportunistic and protects only against passive
wiretap (reasonably well).
Nobody denies that ideally we would address other risks, the above
quoted RFC is one attempt at doing that. However, it makes no
sense to merely "go through the motions" of checking WebPKI
certificates with SMTP without addressing the fundamental barriers
to getting meaningful security that way. Nor, consequently, does
it make much sense to bemoan the lack of WebPKI certificate checks
by all those casually irresponsible SMTP servers.
Doing better in SMTP transport security means requires robust,
downgrade-resistant out of band hardening of MX records and STARTTLS
signalling.
--
Viktor.