IETF Logo Mail Archive

Re: [Uta] WGLC on draft-ietf-uta-tls-attacks-02

Leif Johansson <leifj@sunet.se> Fri, 29 August 2014 20:55 UTC

Return-Path: <leifj@sunet.se>
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 379191A017D for <uta@ietfa.amsl.com>; Fri, 29 Aug 2014 13:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.439
X-Spam-Level:
X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=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 j_x5-yZpTpIE for <uta@ietfa.amsl.com>; Fri, 29 Aug 2014 13:55:56 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675F01A00DB for <uta@ietf.org>; Fri, 29 Aug 2014 13:55:56 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7TKtqKp003013 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Aug 2014 22:55:53 +0200
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s7TKtomO002138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 22:55:52 +0200 (CEST)
X-Footer: c3VuZXQuc2U=
Received: from [10.0.0.116] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128 bits)); Fri, 29 Aug 2014 22:55:49 +0200
Message-ID: <5400E8D5.2090107@sunet.se>
Date: Fri, 29 Aug 2014 22:55:49 +0200
From: Leif Johansson <leifj@sunet.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: uta@ietf.org
References: <53F1B167.3000202@mnt.se> <5D7E66F6642C1E1A80820A9D@96B2F16665FF96BAE59E9B90> <53F24630.6030701@sunet.se> <E4765640DA12D7204FDCCD37@nifty-silver.us.oracle.com>
In-Reply-To: <E4765640DA12D7204FDCCD37@nifty-silver.us.oracle.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09MIITRou - aefda7103e1d - 20140829
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/MjVbEyitYy6g_T0bWgFnGyBUqSc
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>
Subject: Re: [Uta] WGLC on draft-ietf-uta-tls-attacks-02
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: Fri, 29 Aug 2014 20:55:58 -0000

> So absent other commentary, I believe the first paragraph should go in the
> document:
> 
> ===
> 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.
> ===
> 
> This is an important motivation for design decisions in:
>    http://tools.ietf.org/html/draft-newman-email-deep-02
> 

Speaking as an individual that seems reasonable. Yaron? Others?

v2.23.0 | Report a Bug | By Email