IETF Logo Mail Archive

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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 30 August 2014 06:39 UTC

Return-Path: <yaronf.ietf@gmail.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 8929B1A880E for <uta@ietfa.amsl.com>; Fri, 29 Aug 2014 23:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 xixd5w0Fxf2E for <uta@ietfa.amsl.com>; Fri, 29 Aug 2014 23:39:21 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8101A87EE for <uta@ietf.org>; Fri, 29 Aug 2014 23:39:21 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id x12so3021278wgg.33 for <uta@ietf.org>; Fri, 29 Aug 2014 23:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UmpkzI5w4b911NF6m8TbIT1ER4bI0QAq2d/jRuZ4L5A=; b=rPAPytdj7zG5CIRai1E/Oa/HUsuAhOdi54cUcM4csuKMKP9ODu2z5zXgrXDpRhIwj9 dEtaI+8G2Q81fWW4mhrCEO+rRTyUVbC1Jp3QhyGCJXV/HGVD8UeQ9mYgCVXGICDIOiYG ++T+zpIl7Lga0pbhCt+uwjn2UvCkc/fmkTNvBiOT6Fcr4MCQ8W0t9U246+qOD1goJDdW bqdL8fIBy87O20CmkrN/VMRtVV2KYr4cUJVXV3wQSCTe7wOp718jSyKre4yNcP1wO2qW ft5SncRSpkdGcRwoRz6fHRzmepGsb0hr47Wdj5egAzGVreRbAWsI12Eh0jpLm5puu8wW JJ9g==
X-Received: by 10.180.86.202 with SMTP id r10mr8890623wiz.6.1409380760106; Fri, 29 Aug 2014 23:39:20 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id gj3sm2893943wib.15.2014.08.29.23.39.18 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Aug 2014 23:39:19 -0700 (PDT)
Message-ID: <54017195.5090405@gmail.com>
Date: Sat, 30 Aug 2014 09:39:17 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Leif Johansson <leifj@sunet.se>, uta@ietf.org
References: <53F1B167.3000202@mnt.se> <5D7E66F6642C1E1A80820A9D@96B2F16665FF96BAE59E9B90> <53F24630.6030701@sunet.se> <E4765640DA12D7204FDCCD37@nifty-silver.us.oracle.com> <5400E8D5.2090107@sunet.se>
In-Reply-To: <5400E8D5.2090107@sunet.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/zFfdm6vplVPy-VpperigFBkj-WY
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: Sat, 30 Aug 2014 06:39:26 -0000

I am fine with this text.

Thanks,
	Yaron

On 08/29/2014 11:55 PM, Leif Johansson wrote:
>
>> 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