Glad to help
From: Thomas Fossati
Date: Monday, October 25, 2021 at 9:41 AM
To: Rich Salz
Cc: Achim Kraus , Hanno Böck ,
"tls@ietf.org"
Subject: Re: [TLS] DTLS RRC and heartbeat
Rich, Hanno, Mohit,
Thanks a lot for your excellent input. We are going to follow your
advice
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
>And we are not sure, if considering mainly implementation issues, will
justify to allocate a new code-point.
As one of the three TLS registry experts, let me tell you not to be worried
about requesting a new codepoint.
___
TLS mailing list
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.
___
TLS mailing list
Hi Mohit,
Am 21.10.21 um 16:40 schrieb Mohit Sahni:
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.
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
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 wrote:
> On
On Thu, 21 Oct 2021 10:35:54 +0100
Thomas Fossati 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
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
