On 15 Apr 2014, at 18:23, Richard Könning <richard.koenn...@ts.fujitsu.com> wrote:
> Am 15.04.2014 14:35, schrieb Michael Tuexen: >> On 15 Apr 2014, at 14:26, Fedor Indutny <fe...@indutny.com> wrote: >> >>> >>> Hello Hanno! >>> >>> Despite not a being an active community member, I'd like to share my >>> thoughts >>> on it, if you don't mind. >>> >>> 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. > > When the spec leads to an unnecessary large implementation then there is a > problem with the spec because more source code means in general more errors > (there may be deviations from this rule when a more general spec allows to > use common source parts). > >> I think OpenSSL has already a switch to disable the extension at >> compile time. This is available for a lot of extensions/features. > > At least in this case it would have been better to have a compile time option > for *enabling* the extension. Or perhaps two options differentiating between > DTLS and TLS would have been even better. Having explicit compile time options for enabling is a possibility, however, I think this is not how it is done in OpenSSL in general. I think there are a lot of OPENSSL_NO_* defines. That is why OPENSSL_NO_HEARTBEATS was used and not the opposite. > >> Having also a runtime switch for features (with the default being >> off) is a possibility. Might be something for other extensions >> as well. So someone needing a feature needs to write code to >> enable it. > > For people who provide OpenSSL libs for a broad audience with unknown needs a > compile time option helps not much, here a runtime option (being off per > default) helps to provide a functionality without imposing it on the user. > With such an option the Heartbleed bug wouldn't have it made into the major > news. > > Best regards, > Richard > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
