Re: [dane] SMTP STARTTLS stripping in the wild

Chris Newman <chris.newman@oracle.com> Fri, 14 November 2014 01:57 UTC

Return-Path: <chris.newman@oracle.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530061A03E3 for <dane@ietfa.amsl.com>; Thu, 13 Nov 2014 17:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level:
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 hwbV3TRgeM3I for <dane@ietfa.amsl.com>; Thu, 13 Nov 2014 17:57:10 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A461A017A for <dane@ietf.org>; Thu, 13 Nov 2014 17:57:10 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAE1v92W009735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Fri, 14 Nov 2014 01:57:10 GMT
Received: from hermes-fe-3.easd.brm.oracle.com (hermes-fe-3.easd.brm.oracle.com [10.79.248.12]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAE1v9PG013438 for <dane@ietf.org>; Fri, 14 Nov 2014 01:57:09 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from [10.175.253.161] (dhcp-ukc1-twvpn-1-vpnpool-10-175-183-28.vpn.oracle.com [10.175.183.28]) by hermes-fe-3.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NF000A6DAR53I00@hermes-fe-3.easd.brm.oracle.com> for dane@ietf.org; Thu, 13 Nov 2014 17:57:08 -0800 (PST)
Date: Thu, 13 Nov 2014 15:57:05 -1000
From: Chris Newman <chris.newman@oracle.com>
To: dane@ietf.org
Message-id: <2CCB417DB294C9CC79C32DC1@96B2F16665FF96BAE59E9B90>
In-reply-to: <20141114005253.GW22498@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1411131457140.25815@bofh.nohats.ca> <20141114004313.8557.qmail@ary.lan> <20141114005253.GW22498@mournblade.imrryr.org>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LBhr0kv_5UMCGXp20J3Ht6Vw8Tc
Subject: Re: [dane] SMTP STARTTLS stripping in the wild
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 01:57:17 -0000

--On November 14, 2014 0:52:53 +0000 Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:
> On Fri, Nov 14, 2014 at 12:43:13AM -0000, John Levine wrote:
>> > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
>> This is an anti-spam measure on port 25 traffic on a few mobile
>> networks.  I expect there aren't a lot of copies of Postfix running
>> on mobile devices.  For all those other mobile users, if they're
>> configured correctly they're submitting over port 587 or 465, and
>> nobody tries to filter that.
> 
> Indeed most such configurations are likely to have similarly mundane
> explanations.  I used Paul's message as an excuse for a marketing
> message, but forgot to voice my skepticism as to whether this is
> an actual attack at work.
> 
> I am far more curious about what happened to Google's outbound
> TLS mail stats around Oct 14th:
> 
>     https://www.google.com/transparencyreport/saferemail/
> 
> but this seems likely to remain a mystery.  Perhaps some large peer
> botched their TLS settings?

My speculation:

There's no specification for SMTP relay fallback from STARTTLS to cleartext. So
if a provider turns on fully RFC 3207 client-side STARTTLS for relay and that
software doesn't also implement the unspecified fallback, it will stop the flow
of mail to peers that advertise STARTTLS but implement it incorrectly. Once the
queue buildup is noticed, the client-side site has to:
1. turn off client-side STARTTLS
2. upgrade to a software version implementing the unspecified protocol, if
available.
3. manually configure no-STARTTLS for each endpoint that has a broken STARTTLS
implementation.
4. bounce mail to legitimate recipients with a bogus STARTTLS implementation.

Incidentally, I suspect 1 is a common service provider response to this
situation.

		- Chris