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

[Alissa Cooper <[e-mail]>]

> On Sep 2, 2015, at 7:09 AM, Sean Turner <[e-mail]> wrote:
> 
> On Sep 02, 2015, at 02:26, Yoav Nir <[e-mail]> wrote:
> 
>> 
>>> On Aug 31, 2015, at 11:36 PM, Alissa Cooper <[e-mail]> 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.

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

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