On 15 Apr 2014, at 16:43, Hanno Böck <ha...@hboeck.de> wrote: > On Tue, 15 Apr 2014 14:35:36 +0200 > Michael Tuexen <michael.tue...@lurchi.franken.de> wrote: > >> On 15 Apr 2014, at 14:26, Fedor Indutny <fe...@indutny.com> wrote: >> >>> I certainly agree that this extension has a quite faulty >>> specification and very questionable use. But perhaps, instead of >>> just removing it from OpenSSL, we should try to make IETF deprecate >>> it in a spec as well? >> I don't think there is a problem with the spec. The spec tells you >> how to deal with packets having a faulty length field. The problem >> was with the implementation. > > I disagree. Too many features and too much complexity is a problem in > the spec. Unused features is a problem in the spec, because nobody will > care to look after them. I don't think the spec is complex... I think it is simple, the problematic case is explicitly mentioned. However, this does not avoid that someone makes a mistake. > >> I think OpenSSL has already a switch to disable the extension at >> compile time. This is available for a lot of extensions/features. > > Yes, and it should have sane defaults. Enabling an extension that > nobody uses shouldn't happen. So the default of that switch should be > "off", unless someone has a convincing argument otherwise. Adding > features "because we can" is not helpful and adds attack surface. I guess the default could be always off. This would mean if an application wants a new feature, it has to enable it. So if there is no new code in the application, there is no new behaviour in the (D)TLS stack.
Best regards Michael > > > -- > Hanno Böck > http://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: BBB51E42 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
