Subject: Re: [Uta] E-Mail Protocol Security Measurements

From: Watson Ladd <[email-masked]>
Date: Sat, 31 Oct 2015 07:15:51 -0400

On Sat, Oct 31, 2015 at 1:06 AM, Viktor Dukhovni <[email-masked]> wrote:
> On Fri, Oct 30, 2015 at 12:00:30PM +0100, Aaron Zauner wrote:
>
<chop>
>
> STARTTLS is designed to thwart exactly one attack: *passive* wiretap.
> It works as designed for just that attack.  It is not surprising
> that active attacks can and do defeat STARTTLS,

Before STARTTLS adoption the Tunisian secret police read all your
emails. Afterwards they still do. What was gained? Let's try solving
that problem.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 3 Nov 2015 11:13:52 +0100

Hi,

FYI, there's now a third paper dealing with TLS in communication
protocols: http://arxiv.org/abs/1511.00341

Aaron

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Nov 2015 16:41:40 +0100

John C Klensin <[email-masked]> writes:

> 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.

/Simon

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Nov 2015 16:11:05 +0000

> but it is distinctly better than permitting any certificates as in the

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.

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Nov 2015 12:24:48 -0500

--On Tuesday, November 10, 2015 16:41 +0100 Simon Josefsson
<[email-masked]> wrote:

> 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.

Simon,

This is, IMO, less a matter of true or falsity but a question of
who one trusts and why.    I understand that the general pattern
of SMTP servers is to not reject connections unless they can
verify the cert.  However, in the web browser case, it appears
to be fairly easy (especially if money changes hands) to get a
CA into that bundle.  Many CAs, including some those who
typically appear in those bundles, are willing to issue a cert
on the basis that someone appears to "own" a domain name and can
receive mail at an address in that domain.  And many domain name
registrars do no identity verification at all beyond ability to
pay (and are happy to obscure much of the information).   

One way to summarize our disagreement is that your last sentence
says "...distinctly better" where I would have said "...really
not much better".

A different way to look at the problem is to ask the question of
what sort of threat one is trying to protect against.  If the
answer is "casual eavesdropping", then probably any cert, even a
self-signed one, will do.   If the answer is "protection against
a determined attacker who has resources and is willing to invest
them", then I don't think much of certificates that involve only
casual or indifferent checking by the issuer.

YMMD and probably does.

    john