Support for dtls connection id extension?

[mfalkvidd]

Does tinydtls support the dtls connection id extension? (See https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ for details)

If not, does anyone familiar with the project have an idea of how much effort it would be to add support?

[erkki]

We've implemented a minimalistic form of DTLS CID in a private project but it's not in a good shape right now to be released publicly as it relies on many hardcoded bits. There's some internals that make it clunky to implement so if there's official upstream interest/support we're happy to collaborate.

[obgm]

The official status is that it is currently not supported by the upstream tinydtls. It should not be too hard to implement, though (maybe @erkki can share more details?)

[boaks]

@erkki

I'm interested to test the interoperability with Eclipse - Californium, at least the device-client side. Would it be possible to get access to your work?

[erkki]

@boaks by all means, we are already running against leshan/californium, in fact your work there was our starting point. I'll revisit and try to share something.

[boaks]

:-), cool!
So there are already some clients working with it.

[erkki]

Sorry for being late, I was hoping to go through the code again to refresh up and maybe make some bits nicer. This didn't happen, so opening it up as it is in its current state and then we can take it from there. We have a limited implementation with a fixed CID length (also hardcoded leshan side in our usage) format so this would probably have to change in a more general solution.

Happy to help with implementation and/testing once there's established interest and direction.

https://github.com/bear-metal/tinydtls-esp32/tree/dtls_cid

[boaks]

@erkki

just if you are still interested in the recent development, I added a build-in cid-load-balancer to Californium. The current plan is to add this the the upcoming Californium release 2.5.0 next week.

[erkki]

@boaks this looks great! Definitely interested, albeit little time constrained. We're doing field testing now with some devices but for the next phase we would definitely need something like this on the server/infra side for HA/LB. I've been trying to keep up with the RFC discussions as well so probably need a rebase+refresh at some point. Curious if you have a backwards compatibility plan with the recent RFC changes and client code with CID length specificers :)

[boaks]

albeit little time constrained.

So am I :-)

I've been trying to keep up with the RFC discussions as well so probably need a rebase+refresh at some point. Curious if you have a backwards compatibility plan with the recent RFC changes and client code with CID length specificers :)

There are three ways to go:

• new MAC new record content-type
• new MAC only (without new record content-type). That would require to check the MAC of the FINISH, if it uses the definition of 07 or the future one.
• no new MAC, no change required. My strong preference. But it seems, that I'm the only one :-).

So for now, the only topic discussed to change seems to be the MAC. But until the RFC gets really released, I don't think it's worth to frequently adapt to those MAC updates based on cryptographic hygiene.

The discussion about more clarification on "variable length CID" encoding doesn't affect Californium's implementation. There it's just delegated to the implementation of ConnectionIdGenerator. And, if fixed length CID are used, it's not related at all.

The only "claimed threat" left seems to be a "false valid" for the MAC of the FINISH message, if handshake messages are manipulated. Generally, the verify_data of the FINISH is used to protect from such handshake message manipulations. I don't see, why the MAC should be here that important. There are much more options to manipulate handshake messages, which are also not detected by the FINISH MAC, but by that verify_data.
End the example seems to be more theoretical and focused isolated on the CID-MAC topic. In my opinion, AEAD, AES-CDC MtE will not show that defect, only AES-CDC EtM, but that's not implemented in Californium.
And I guess, RFC7627 will also close that gap (if that "false valid" MAC is considered as gap at all).

So, let's look forward, what will be presented as release by the IETF-TLS working group.

[erkki]

Yes makes sense, we're already using ConnectionIdGenerator to pseudo-fix our CID length.

[boaks]

The last information on that MAC change is, that also a new hello_extension code point (currently 53) will be assigned by the IANA with the release of the draft-ietf-tls-dtls-connection-id. The old one will stay reserved for a while.

[boaks]

@mfalkvidd
@erkki

For the case, you're still interested:

• RFC9146 should be published in the next time (at least I hope so ;-).

• I prepared a first PR to add support to the client (PR Client cid #108 }.

• mbedtls is also working on supporting RFC9146

• when mbedtls will be release (2022/Q1 according this roadmap, zephyr may also support it.

Californium reached also version 3.0.0 (support compliant to RFC9146).
If you're still interested, your feedback is very welcome.

[erkki]

Sounds good!

I'll give this a test in the lab :)

[boaks]

@mfalkvidd
@erkki

Have you been able to have a look on it? Does it work for you?

For my developments in the last two years, DTLS CID, so simple it is, turned into the enabler technology for successfully DTLS load-balancing with long term session, and for (half :-) ) high availability using a dtls graceful restart. Hope this could get some more adoption in the next year.

[erkki]

Sorry, been tied up. Definitely want to give this a test run in the lab this weekend.

For us, also, DTLS CID has been a huge enabler, due to the IP roaming issue prevalent otherwise.