Re: [Uta] Recording from irtfopen on email security using TLS

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 07 April 2016 19:41 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BBD12D1B1 for <uta@ietfa.amsl.com>; Thu, 7 Apr 2016 12:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 gCWyAv7Es1lA for <uta@ietfa.amsl.com>; Thu, 7 Apr 2016 12:41:17 -0700 (PDT)
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 674F412D0BA for <uta@ietf.org>; Thu, 7 Apr 2016 12:41:17 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 287CA284F25; Thu, 7 Apr 2016 19:41:16 +0000 (UTC)
Date: Thu, 07 Apr 2016 19:41:16 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: "uta@ietf.org" <uta@ietf.org>
Message-ID: <20160407194115.GI26423@mournblade.imrryr.org>
References: <BN3PR0301MB08678C5C40FDD9741697D201AD9F0@BN3PR0301MB0867.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BN3PR0301MB08678C5C40FDD9741697D201AD9F0@BN3PR0301MB0867.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/WkaqFWI03Hw6R6UT6QdYOAeWTcw>
Subject: Re: [Uta] Recording from irtfopen on email security using TLS
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
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: Thu, 07 Apr 2016 19:41:22 -0000

On Wed, Apr 06, 2016 at 11:13:17PM +0000, Orit Levin (CELA) wrote:

> For those who didn't attend the irtfopen session on Tue, I recommend viewing the recording at 
> https://www.youtube.com/watch?v=36WDbfKEIRI.
> 
> The talk relevant to UTA starts at min 22. It provides a great intro to
> the challenges around using email with TLS.

While the talk was interesting and provides useful background it
is also somewhat misleading.

  * Firstly it compares SMTP security with HTTPS, but the right
    comparison is with the Web, whether HTTP or HTTPS, not just
    the "secure" Web.  What fraction of HTTP sites visited by users
    are HTTPS with valid certificates?

    I certainly find many HTTP-only sites, even sites of major
    server hardware vendors that provide firmware and software
    updates are HTTP-only, or routinely serve HTTP links from
    from HTTPS pages even if they support both.

    The state of SMTP transport security is not nearly as dire as
    presented.  Yes, the "secure" portion of SMTP is typically only
    secure against passive attacks, but in practice more of the
    traffic may be at least somewhat protected than with HTTP.
    Opportunistic security *is* easier to deploy.

  * The dismissal of DANE in the Q&A is either disingenuous or
    naive.  Yes, DNSSEC adoption is low (around 2% of domains in
    my survey), but it is not *zero* as with STS.

    Just as DANE requires adoption of new software (DANE capable
    MTAs, and DNSSEC validating resolvers), so would STS require
    adoption of new capabilities in client MTAs.

    DANE software is already available in Postfix and Exim, and in
    May will become part of the stable OpenSSL 1.1.0 release.  I've
    identified 11.7k domains with working DANE (out of an estimated
    100k similar domains that don't always appear on lists such as
    the Alexa 1M, which is not a particularly relevant list for
    email).

Whether the solution is STS, DANE or both, neither will happen
overnight.  I estimate broad adoption of STS not much earlier than
circa 2020--2022.  In the same timeframe, the large providers could
likely implement DNSSEC and DANE.

Adoption of STS may be faster on the server side at the large
providers, but client-side adoption of STS outside that set of
providers will take longer than it would for DANE, because there
is neither a stable specification, nor even experimental code in
the various open-source MTAs.

The following "well-known" domains (based on a current listing at
Google's email transparency report) support DANE on the server
side:

    registro.br
    mail.com
    mzk.cz
    bund.de
    jpberlin.de
    lrz.de
    posteo.de
    unitymedia.de
    octopuce.fr
    comcast.net
    t-2.net
    xs4all.net
    xs4all.nl
    debian.org
    freebsd.org
    gentoo.org
    ietf.org
    netbsd.org
    openssl.org
    samba.org
    torproject.org

if we include domains that appeared in that report in the past,
the list grows to include:

    travelbirdbelgie.be
    mailous.com
    societe.com
    t-2.com
    gohost.cz
    bayern.de
    ish.de
    kabelmail.de
    ruhr-uni-bochum.de
    tum.de
    unitybox.de
    lepartidegauche.fr
    dd24.net
    rrpproxy.net
    xworks.net
    aanbodpagina.nl
    jasperalblas.nl
    mijngastouderburo.nl
    steffann.nl
    isc.org

I've identified > 11700 additional domains, but most are too small
to account for a noticeable fraction of most senders' email.

[ Even my domain is not listed, despite my best efforts to
  flood the ietf lists with my comments. :-) ]

-- 
	Viktor.