IETF Logo Mail Archive

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

Sean Turner <sean@sn3rd.com> Wed, 02 September 2015 14:09 UTC

Return-Path: <sean@sn3rd.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 5C0061B42DE for <tls@ietfa.amsl.com>; Wed, 2 Sep 2015 07:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.487
X-Spam-Level:
X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 NZ7UXlNVZ6dj for <tls@ietfa.amsl.com>; Wed, 2 Sep 2015 07:09:41 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 E3E941B3F5A for <tls@ietf.org>; Wed, 2 Sep 2015 07:09:40 -0700 (PDT)
Received: by qkcf65 with SMTP id f65so5872884qkc.3 for <tls@ietf.org>; Wed, 02 Sep 2015 07:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/RJ2EFJkbox7IsXrS5zlseEjpSipN+I9JjjvuayEEnM=; b=a71OmF0/LmzfcGVoqUOZG5nW0hjSH/foBP+jYNMFRZKFmXHfjMgZnV/UVnISyFUlg6 rHKfFWR8YlR+jTTXqe7gPxHwHlpvUi68BwVT8/GqVMPCEvSDQTfU42ifdLduoWF0jj0H gzT2Tv1048LLP8NWpDbYm8vQ5xS3eu9EFLXrY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/RJ2EFJkbox7IsXrS5zlseEjpSipN+I9JjjvuayEEnM=; b=L6AkFs14jWNETSowzMtdyRT7BuItVVOembY+ciCcSq3SQa0st45UdgsfD5f5PKM2UI WccztuExywdA5cJfvWM1koVySxNxPDCqYDCGWZOUqfE0s1d1LvPCkD+JZL+4XuUagVmG O1cJlARPPuWo1CZRNPed6PmeJIr02pdLOWUM0kF6zsQgkNGyhaoFT6vpRkpzcYxuROlV ZkSa9AGVJXo4uFWDzOUK+AqqD5pEx0X/u4HSeFaYIFkWngUYlt6bhsWaM3CR9mFR0utI qlv2Wd2BF1OH/+9bn/gJ6s+qe04tiyAwlaLNBJtliY/Km0xx5k1HXAvEWqFFFhlp9q0J IcoQ==
X-Gm-Message-State: ALoCoQnoEQWi+MnNbsP44RL3BL2oQX0bX50gh99D+cNKTV4IxvXgdg3X9d0guS3aD7iELEa/6rZz
X-Received: by 10.55.198.92 with SMTP id b89mr28086249qkj.102.1441202979520; Wed, 02 Sep 2015 07:09:39 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.216.201]) by smtp.gmail.com with ESMTPSA id 130sm12805930qhg.13.2015.09.02.07.09.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Sep 2015 07:09:38 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <3A706F2D-B607-47E5-A6CD-4BAF344A8C7B@gmail.com>
Date: Wed, 02 Sep 2015 10:09:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6630C2B6-A273-400D-A72D-CACB255BB87D@sn3rd.com>
References: <20150831203613.9221.81864.idtracker@ietfa.amsl.com> <3A706F2D-B607-47E5-A6CD-4BAF344A8C7B@gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/bxCrG9vvkj7UiuGuaNldAd5QiEQ>
X-Mailman-Approved-At: Wed, 02 Sep 2015 09:47:15 -0700
Cc: The IESG <iesg@ietf.org>, "<tls@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 14:38:10 -0000

On Sep 02, 2015, at 02:26, Yoav Nir <ynir.ietf@gmail.com> wrote:

> 
>> 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

I agree with Yoav.  

By way of additional background: The extension fixes an issue that Brian Smith brought to the WG’s attention [0].  It’s related to ALPN deployment; he was running into failures when handshakes were larger than 255 bytes.  Brian got some numbers from Kurt Roeckx, who relayed them from Ivan Ristic, and these numbers showed that around 2.9% of the web servers surveyed on the Internet had this problem.  That number kind of got the WG’s attention because yeah the implementer can fix their code in a patch, but they can’t really force that patch to be deployed everywhere.

spt

[0] https://mailarchive.ietf.org/arch/msg/tls/v7tEam3Wi5GjpEXxF_71qPY0Ojo

v2.23.0 | Report a Bug | By Email