IETF Logo Mail Archive

Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)

Yoav Nir <ynir.ietf@gmail.com> Wed, 02 September 2015 06:26 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6F81B48EF; Tue, 1 Sep 2015 23:26:36 -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 GQBuQNSnUkJe; Tue, 1 Sep 2015 23:26:35 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D905D1B48EE; Tue, 1 Sep 2015 23:26:34 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so7167608wic.0; Tue, 01 Sep 2015 23:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0MmSVlEKNziybf7h56gPmQtS32lr1l8YPlTQM5OzjZA=; b=ORFd1dOS9J6suWHRPKuqLqM7ZyqXgYBbU8kWMZNsbvmyjNEXKlLgYQnVPZdAloxoKt OdJF1rAiA5HPHii8lHDZFUDokEI1PH/ideS+gLTZiYBZQVuKE9OZBQrZxzSmMztfsnn4 ln4Yy0tvwKl4OuKnr0PJPp1ryRmPpG02u//dbjr2k15/oytGXo+6nOPbvAiAAyE6OpSN +g6OPOpoJzSyUK0W5T1F2cyrgR/NDs/nEq+VEM2JSaXLzwI9cJ+o+/M6Qr1Drf7BiiOq i3WOOG+UdYezCkVbi/iLxzXfMLSFw9Muq4Mug0pxRohZocpR0K+0fuYgCcN8gDmwU1Sx izPQ==
X-Received: by 10.194.86.134 with SMTP id p6mr40551935wjz.71.1441175193426; Tue, 01 Sep 2015 23:26:33 -0700 (PDT)
Received: from yoavs-mbp.mshome.net ([109.253.130.113]) by smtp.gmail.com with ESMTPSA id c11sm1863711wib.1.2015.09.01.23.26.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Sep 2015 23:26:32 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20150831203613.9221.81864.idtracker@ietfa.amsl.com>
Date: Wed, 02 Sep 2015 09:26:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A706F2D-B607-47E5-A6CD-4BAF344A8C7B@gmail.com>
References: <20150831203613.9221.81864.idtracker@ietfa.amsl.com>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pwxQoBCg09FbKI3KZTRzyVawpnI>
Cc: The IESG <iesg@ietf.org>, tls@ietf.org
Subject: Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2015 06:26:36 -0000

> On Aug 31, 2015, at 11:36 PM, Alissa Cooper <alissa@cooperw.in> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-tls-padding-02: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Would be nice to include a reference to something that explains or at
> least identifies the implementation that hangs when receiving
> ClientHellos of a certain size.

RFCs are forever. I don’t see much value in a “F5 had a bug in 2011” sentence in an RFC. OTOH such perpetual bad publicity (much like the “NETSCAPE_BUG” and “MICROSOFT_BUG” constants in OpenSSL code) may in the future discourage vendors from being as forthcoming with relevant information as F5 were in this case.

> Otherwise one wonders why it's easier to
> define this extension than it is to just fix that one implementation
> (assuming it is only one).

The implementation has been fixed for years. Many of their customers had not upgraded their firmware when discussion of this extension began.

This is similar to how a vulnerability in home router firmware that was patched in 2004 was still present in new home routers sold in 2014 that were vulnerable to Shellshock. Unfortunately not every vendor can push upgrades to all customers the way browser vendors do.

Yoav

v2.23.0 | Report a Bug | By Email