Re: [Uta] I-D Action: draft-ietf-uta-tls-attacks-01.txt

Chris Newman <chris.newman@oracle.com> Mon, 21 July 2014 21:46 UTC

Return-Path: <chris.newman@oracle.com>
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 900A11A090D for <uta@ietfa.amsl.com>; Mon, 21 Jul 2014 14:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 GSKRCPNlZVgr for <uta@ietfa.amsl.com>; Mon, 21 Jul 2014 14:46:10 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8951A08F8 for <uta@ietf.org>; Mon, 21 Jul 2014 14:46:10 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6LLk9US001998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <uta@ietf.org>; Mon, 21 Jul 2014 21:46:09 GMT
Received: from hermes-fe-1.easd.brm.oracle.com (hermes-fe-1.easd.brm.oracle.com [10.79.248.10]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LLk8mT029008 for <uta@ietf.org>; Mon, 21 Jul 2014 21:46:09 GMT
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"
Received: from [10.175.162.51] (dhcp-ukc1-twvpn-3-vpnpool-10-175-240-81.vpn.oracle.com [10.175.240.81]) by hermes-fe-1.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0N9300D130GTWF00@hermes-fe-1.easd.brm.oracle.com> for uta@ietf.org; Mon, 21 Jul 2014 14:46:08 -0700 (PDT)
Date: Mon, 21 Jul 2014 17:46:04 -0700
From: Chris Newman <chris.newman@oracle.com>
To: uta@ietf.org
Message-id: <2C79E435C2F8A9528EBDDBEE@[10.175.162.51]>
In-reply-to: <20140327181624.19837.45584.idtracker@ietfa.amsl.com>
References: <20140327181624.19837.45584.idtracker@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/eUEk6Dvod2J0XZ35PbZMLb-KiG8
Subject: Re: [Uta] I-D Action: draft-ietf-uta-tls-attacks-01.txt
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: <http://www.ietf.org/mail-archive/web/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: Mon, 21 Jul 2014 21:46:12 -0000

I've reviewed draft-ietf-uta-tls-attacks-01.txt and support its publication. I
believe the document would be improved by including CVE numbers for the
vulnerabilities in the document.

I had volunteered to write text describing the STARTTLS attack. Here's strawman
text:

---
2.9 STARTTLS Command Injection Attack (CVE-2011-0411)

A number of IETF application protocols have used an application-level command,
usually STARTTLS, to upgrade a clear-text connection to use TLS. Multiple
implementations of STARTTLS had a flaw where an application-layer input buffer
retained commands that were pipelined with the STARTTLS command, such that
commands received prior to TLS negotiation are executed after TLS negotiation.
This problem is resolved by requiring the application-level command input
buffer to be empty before negotiating TLS. Note that this flaw lives in the
application layer code and does not impact the TLS protocol directly.

Because several independent implementations had the same problem, use of
STARTTLS in new IETF protocols is discouraged.
---

This attack is a key factor in changing the bias of the application area with
respect to use of STARTTLS and is one of the motivations behind the "implicit
TLS" preference in

 http://tools.ietf.org/html/draft-newman-email-deep-01

		- Chris