Subject: [TLS] DTLS RRC and heartbeat

From: Thomas Fossati <[email-masked]>
Date: Thu, 21 Oct 2021 10:35:54 +0100

Hi,

Hannes, Achim and I are working on the DTLS return routability check
(RRC) draft [1].

In the process, we realised that what we were building was heartbeat
(RFC6520) just with a different name.

If one looks at RFC6520's use cases [2], path MTU discovery and path
liveliness are listed already.  So we could update the existing RFC
with a path validation use case and profile the probing algorithm to
support the more subtle threat model that QUIC assumes, which we are
reasonably sure we want to do.  Enhancing the heartbeat mechanism with
a "path validation" sub-protocol for DTLS seems quite logical (to us).
This would be incremental work rather than reinventing the wheel. To
us, this appears to be an attractive approach.

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]).

So, we are not entirely sure what we should do, and on Chris's
suggestion we are bringing this to the group to ask for direction.

Thanks in advance for any thought, opinion, ideas you may want to share with us.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-rrc
[2] https://www.rfc-editor.org/rfc/rfc6520#section-5
[3] https://github.com/openssl/openssl/pull/1928
-- 
Thomas

---

From: Hanno Böck <[email-masked]>
Date: Thu, 21 Oct 2021 16:30:27 +0200

On Thu, 21 Oct 2021 10:35:54 +0100

> and the code reuse story a bit more complicated than desired (see for

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.

-- 
Hanno Böck
https://hboeck.de/

---

From: Mohit Sahni <[email-masked]>
Date: Thu, 21 Oct 2021 07:40:44 -0700

Just want to highlight one more issue with using the original extension,
many network security devices have threat signatures to identify the
heartbeat extension in packet streams and they will block the sessions that
match the signatures.

On Thu, Oct 21, 2021 at 7:31 AM Hanno Böck <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Achim Kraus <[email-masked]>
Date: Thu, 21 Oct 2021 16:58:09 +0200

Hi Hanno,

thanks for your feedback.

 > 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

---

From: Achim Kraus <[email-masked]>
Date: Thu, 21 Oct 2021 17:06:38 +0200

Hi Mohit,

Am 21.10.21 um 16:40 schrieb Mohit Sahni:
> heartbeat extension in packet streams and they will block the sessions
> that match the signatures.
>

that sounds as a good reason, to ask for a new code-point.

best regards
Achim Kraus

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Oct 2021 15:42:44 +0000

For the points Hanno raised, I think it might make sense to define a simpler heartbeat framework that is only defined for UDP.  Get a new udp-only codepoint.  And yes, OpenSSL completely removed heartbeat some time ago.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Oct 2021 15:44:32 +0000

As one of the three TLS registry experts, let me tell you not to be worried about requesting a new codepoint.

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 25 Oct 2021 14:41:35 +0100

Rich, Hanno, Mohit,

Thanks a lot for your excellent input.  We are going to follow your
advice and avoid overloading heartbeat then.

Scope-wise, RRC will focus on path validation and liveliness use cases,
leaving PMTU discovery out, at least for the moment.

cheers,

On Thu, Oct 21, 2021 at 4:45 PM Salz, Rich <rsalz=
[email-masked]> wrote:

> As one of the three TLS registry experts, let me tell you not to be
> worried about requesting a new codepoint.
>

-- 
Thomas

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 Oct 2021 13:06:13 +0000

Glad to help

From: Thomas Fossati <[email-masked]>
Date: Monday, October 25, 2021 at 9:41 AM
To: Rich Salz <[email-masked]>
Cc: Achim Kraus <[email-masked]>, Hanno Böck <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DTLS RRC and heartbeat

Rich, Hanno, Mohit,

cheers,

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Eeto3IhgNvAs-fuQuW3f8r9ToWWyxEm_a6VHztwS_H52jjnmkZInzPkc1loF$>

--
Thomas