Repository navigation
Support for dtls connection id extension? #27
Description
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?
Activity
erkki commentedon Mar 31, 2020
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 commentedon Mar 31, 2020
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 commentedon Jun 25, 2020
@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 commentedon Jun 25, 2020
@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 commentedon Jun 25, 2020
:-), cool!
So there are already some clients working with it.
erkki commentedon Jul 11, 2020
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 commentedon Oct 29, 2020
@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 commentedon Oct 30, 2020
@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 commentedon Oct 30, 2020
So am I :-)
There are three ways to go:
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_dataof 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 thatverify_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 commentedon Oct 30, 2020
Yes makes sense, we're already using
ConnectionIdGeneratorto pseudo-fix our CID length.boaks commentedon Mar 21, 2021
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 commentedon Nov 19, 2021
@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 commentedon Nov 21, 2021
Sounds good!
I'll give this a test in the lab :)
boaks commentedon Dec 9, 2021
@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 commentedon Dec 9, 2021
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.
boaks commentedon Mar 22, 2022
Just to mention:
RFC9146 is published.
boaks commentedon Aug 9, 2022
In the meantime, tinydtls has a feature branch for CID and a pending PR #149 .
If someone is interested to see that in action, you may consider to have a look at
Zephyr - CoAP/DTLS 1.2 CID client for Thingy:91