dtls
dtls copied to clipboard
Plans for DTLS 1.3
I stumbled across https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ today. Looks like it's on its way now.
I took a stroll through the spec, and https://tools.ietf.org/html/draft-ietf-tls-dtls13-34#section-12 has the changed compared to DTLS v1.2. I'm copying it here for good meassure:
- New handshake pattern, which leads to a shorter message exchange
- Only AEAD ciphers are supported. Additional data calculation has been simplified.
- Removed support for weaker and older cryptographic algorithms
- HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest
- More flexible ciphersuite negotiation
- New session resumption mechanism
- PSK authentication redefined
- New key derivation hierarchy utilizing a new key derivation construct
- Improved version negotiation
- Optimized record layer encoding and thereby its size
- Added CID functionality
- Sequence numbers are encrypted
Seems there's quite a bit of change. It might prove a fairly decent headache to support that.
This is really exciting! Some random thoughts I had.
We should join the IETF list and see if we can help.
Would be so exciting if Pion DTLS could make prototyping/building DTLS implementations faster.
Put flights in separate packages
@at-wat split out all the code for flights into their own things. We can take advantage of this and have separate flights for 1.2 and 1.3 in their own packages.
A lot of stuff like the sequence numbers will be a pain to manage, but we will figure it out :)
DTLS 1.3 is finally in RFC state... https://www.rfc-editor.org/rfc/rfc9147.html
I would love to see some updates on this.
DTLS 1.3
is providing a some really essential features, regarding deep sleep and energy efficiency.
https://github.com/eclipse/wakaama/issues/684#issuecomment-1455065127 https://github.com/tlswg/dtls13-spec/issues/282
I would love to help with this!
- Do any implementations of 1.3 exist (so we can interop test)
- Would any Pion users benefit from it/actually use it?
I am just hesitant to put work into this if no one ends up using it.
We are working a lot with narrowband IP links at work (with tens or hundreds of kilobits/s channel capacity), so the more compact headers of DTLS1.3 and its zero-RTT reconnection would be a great way to secure UDP based communication (e.g. COAP).
Looking at OpenSSL ( https://github.com/openssl/openssl/issues/13900#issuecomment-1414440852 ) it mentions the WolfSSL implementation for interop testing DTLS 1.3
We're working on similar narrowband cellular problems like @HRogge (we should talk!) and have been tracking DTLS 1.3. That said, there's one feature, Connection ID, that was "backported" to 1.2 that provides significant power improvements that our customers and partners are asking for. @miguel91it has been evaluating what it would take to add it. Of course it's a separate issue from DTLS 1.3, but it's smaller and the thing we currently care most about, so I thought it would be worth sharing 🙂
@eabase @HRogge Indeed wolfSSL supports DTLS 1.3 since release 5.4.0 (July 2022).
We would be interested in setting up some interoperability tests ourselves too, since we could not find any other implementation so far.
Edit: corrected link
Just forgot to add that go-coap refers to pion-dtls for TLS support... so everyone who wants to use "secure go-coap" will most likely also end using this project.
@danielinux
Indeed wolfSSL supports DTLS 1.3 since release 5.4.0 (July 2022).
No, that's incorrect. They support TLS 1.3
, but only DTLS 1.2
.
(Unless they're showing wrong info in the README.)
Corrected wolfSSL link: https://github.com/wolfssl/wolfssl
@eabase Indeed the README is outdated. I've reported that to the team. Thanks for noticing that.
Confirming wolfSSL support both TLS 1.3 (since 2017) and DTLS1.3 (since July 2022).
When we will DTLS1.3 be supported?