Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

-IESG Jonathan -> thanks for the review. WG -> This has been sitting around for a while, and I would like to propose that unless another PR appears before 29 October 2021 2359 UTC that we work with Jonathan’s existing PR: https://github.com/tlswg/tls-exported-authenticator/pull/76 Can I get (a

Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

Apologies I meant 29 October 2021 2359 UTC > On Oct 21, 2021, at 21:34, Sean Turner wrote: > > Hi! It’s a been awhile since Nick proposed how to resolve the IESG comments. > To get the I-D moving again, I would like to propose the following and unless > I hear otherwise by 29 November 2021 235

Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

Hi! It’s a been awhile since Nick proposed how to resolve the IESG comments. To get the I-D moving again, I would like to propose the following and unless I hear otherwise by 29 November 2021 2359 UTC it is what we will do: - For the 1st two, we accept Nick's suggestion, i.e., no change (these w

Re: [TLS] tls-flags: abort on malformed extension

Yoav, Thanks for moving this along. spt > On Oct 20, 2021, at 16:11, Yoav Nir wrote: > > Hi. > > I updated the PR. If there are no further objections, I will commit and > submit a new version in time for the submission deadline. > > Yoav > > >> On 7 Oct 2021, at 21:37, Yoav Nir wrote: >

Re: [TLS] DTLS RRC and heartbeat

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

Re: [TLS] DTLS RRC and heartbeat

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 TLS@ietf.o

Re: [TLS] DTLS RRC and heartbeat

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

Re: [TLS] DTLS RRC and heartbeat

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

Re: [TLS] DTLS RRC and heartbeat

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 T

Re: [TLS] DTLS RRC and heartbeat

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 th

[TLS] DTLS RRC and heartbeat

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.