> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
