> On Sep 2, 2015, at 7:09 AM, Sean Turner <s...@sn3rd.com> wrote: > > On Sep 02, 2015, at 02:26, Yoav Nir <ynir.i...@gmail.com> wrote: > >> >>> On Aug 31, 2015, at 11:36 PM, Alissa Cooper <ali...@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.
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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
