Re: [TLS] DTLS RRC and heartbeat

[Achim Kraus <[e-mail]>]

Hi Hanno,

thanks for your feedback.

 > I feel this may be enough justification to define a hearbeat-simplified
 > spec that doesn't have these problems.

The point with that would be, that it requires a new code-point for the
content-type
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5

And we are not sure, if considering mainly implementation issues, will
justify to allocate a new code-point.

best regards
Achim Kraus

Am 21.10.21 um 16:30 schrieb Hanno Böck:
> On Thu, 21 Oct 2021 10:35:54 +0100
> Thomas Fossati <[e-mail]> wrote:
>
>> One problem is - as Hannes put it - that heartbeat has a "somewhat
>> tricky history", making its marketing a slightly intricate operation,
>> and the code reuse story a bit more complicated than desired (see for
>> example [3]).
>
> I think there were a few things that went spectacularly wrong with the
> original heartbeat extension. Some of them are implementation issues
> (like merging code without proper review and testing), but others are in
> the spec itself.
>
> I think this boils down to two things that added unnecessary
> complexity, which is always bad in security:
> 1. The use cases were all UDP, but the extension was defined for both
>     UDP and TCP for no good reason.
> 2. The extension contained a completely unnecessary length-encoded
>     message that was sent forth and back. That's a very risky
>     construction in terms of memory safety.
>
> I feel this may be enough justification to define a hearbeat-simplified
> spec that doesn't have these problems.
> If you decide to go with the old heartbeat extension then I'd still
> wish you at least adress 1. I think many people have just compiled
> openssl without heartbeat, which is a good thing as long as it's not
> used anyway. If it gets used in DTLS then at least make sure that
> doesn't mean it also has to be enabled in TCP-based normal TLS at the
> same time.
>