Re: [saag] AD review of draft-iab-crypto-alg-agility-06

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 25 August 2015 13:43 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26D91ACD79 for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 06:43:36 -0700 (PDT)
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 lXumpZOfQq9J for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 06:43:35 -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 296C31A907A for <saag@ietf.org>; Tue, 25 Aug 2015 06:43:34 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A8ED0284B69; Tue, 25 Aug 2015 13:43:33 +0000 (UTC)
Date: Tue, 25 Aug 2015 13:43:33 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag@ietf.org
Message-ID: <20150825134333.GX9021@mournblade.imrryr.org>
References: <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <DM2PR0301MB0655CF099FA7C56E9B9D24A9A88D0@DM2PR0301MB0655.namprd03.prod.outlook.com> <20150728053035.GR4347@mournblade.imrryr.org> <CAHbuEH7B3_G9vAhw=U2tuz-Uh8mKMUfL6s=H+BOG96FDZaACig@mail.gmail.com> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/WfW_p6Xfgv1n3JnkJhpgVSSv8yc>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 13:43:36 -0000

On Tue, Aug 25, 2015 at 07:26:53AM +0000, Peter Gutmann wrote:

> Viktor Dukhovni <ietf-dane@dukhovni.org>; writes:
> 
> >Opportunistic TLS was added to Microsoft Exchange 2003, and further extended
> >in 2007.
> 
> It's not true opportunistic TLS (unless they've fixed it recently), it's "pay
> a commercial CA to be allowed to do TLS", unlike pretty much every other MTA
> I'm aware of which allows you to just set up and go without having to buy a
> cert for each server.

Server side STARTTLS support, which is agnostic as to whether the
client is opportunistic or not, is available with Exchange 2003
and later.

Opportunistic TLS is supported in at least Exchange 2007 and later.
I don't recall what Exchange 2003 did outbound, I only recall
helping  Microsoft to design fixes for various issues prior to the
release of Exchange 2007.  Some flaws remain, but it is largely
workable without a CA tax.

> (I'm not saying this as part of some anti-CA crusade, but to point out that
> Exchange puts a considerable hurdle in the way of universal opportunstic TLS
> for email.  To do opportunistic TLS with Postfix or most (all?) other MTAs,
> you need just the MTA.  To do it with Exchange, you need the MTA plus
> permission from a commercial CA to use TLS.  In the interests of getting hard
> data for this, I wrote to Aaron Zauner, who did the TLS-with-SMTP survey, a
> few days ago to ask if he has distinct stats for Exchange vs. everything else).

Inbound, Exchange does not and cannot know whether the client is
authenticating the server certificate or ignoring it.  Outbound,
there are still a few known defects, that I've communicated to
Microsoft, and will I hope be fixed at some point.

The most significant known issues are TLS handshake failure and
fallback to cleartext when:

    * The peer's certificate is expired.  Even though authentication
      is not required and it would be accepted from an untrusted
      issuer.

    * The peer's certificate chain has certificates signed with
      MD5.  Even if the only use of MD5 is in the self-signature
      of a root CA, and even for client cerficates which are
      solicited though the server does not use them.

    * The server's certificate uses SHA2-256, but the peer only supports
      TLS 1.0, or in any case fails to include SHA2-256 in the supported
      signature algorithms extension.

The last of these is a result of implementing RFC 5246 (TLS 1.2),
rather than what makes sense.  It looks like TLS 1.3 is on track
to be sensible in this regard (server-side handling of certificate
signature algorithms).

The majority of clients and servers don't run into the above
problems, but they do thwart STARTTLS for a non-negligible minority
of systems.

-- 
	Viktor.