Re: [Uta] E-Mail Protocol Security Measurements

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 10 November 2015 16:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74F11B2DF7; Tue, 10 Nov 2015 08:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOU51R22m1IU; Tue, 10 Nov 2015 08:11:08 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAB91B2DF4; Tue, 10 Nov 2015 08:11:07 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ECB70284D70; Tue, 10 Nov 2015 16:11:05 +0000 (UTC)
Date: Tue, 10 Nov 2015 16:11:05 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org, uta@ietf.org
Message-ID: <20151110161105.GL18315@mournblade.imrryr.org>
References: <55B62F80.1010400@azet.org> <20151030115708.80a5221a87@43412e1d2c718c7> <20151031050630.GB24882@mournblade.imrryr.org> <1F1B4718D570C1E3AD9AFADB@JcK-HP5.jck.com> <878u65dfpn.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <878u65dfpn.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/TsfyTzNBHocuvtRWBEsEyyAnizs>
Subject: Re: [Uta] E-Mail Protocol Security Measurements
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2015 16:11:09 -0000

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.