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 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
