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

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 31 Aug 2015 13:36:13 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-padding-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Sep 2015 09:26:27 +0300

> On Aug 31, 2015, at 11:36 PM, Alissa Cooper <[email-masked]> wrote:
> 
> 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

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

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Sep 2015 10:09:36 -0400

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

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

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Sep 2015 09:39:30 -0700

> On Sep 2, 2015, at 7:09 AM, Sean Turner <[email-masked]> wrote:
> 

Thanks, this is the kind of helpful context I was going for. I would suggest adding something like this at the end of the first paragraph in section 1:

"This is desirable given that fully comprehensive patching of affected implementations is difficult to achieve.”

Alissa