Use of TLS1.1 and DTLS1.0



Is anyone aware of why, when defining S2 and Z/IP, TLS1.1 and DTLS1.0 were chosen? Since TLS1.2 and DTLS1.2 are, in fact, fairly old and well established protocols, why were they not selected instead?

Many thanks,



It’s important to note that neither S2 nor Z/IP include or use DTLS or TLS as part of their definitions. S2 is completely on the Z-Wave Protocol side and is in itself a cryptographic protocol. Z/IP defines additional Command Classes to be used when communicating with Z-Wave devices over IP, or when communicating to zipgateway-type IP devices.

zipgateway does use DTLS1.0 to secure UDP communication to and from its clients. zipgateway also does use TLS1.1 to establish a tunnel to a Cloud Portal in order to secure cloud communications and provide some connectivity guarantees.

zipgateway has been around for a lot longer than it has been available to the general public. While I’m not privy to the actual reasons why TLS1.1 and DTLS1.0 were selected, the typical driver in these situations is the availability of libraries that provide these protocols. Z/IP Clients can be built on multiple platforms and using a variety of programming languages. I would image that at the time zipgateway was developed the maximum common denominator across the different libraries that were available was likely DTLS1.0 and TLS1.1.


Thanks for the reply. Some interesting points and thanks for clarifying my terminology. That said, TLS1.2 was released in 2008, so is almost 10 years old… I think we’d be hard pressed to not find libraries not supporting it …I feel like I need to keep digging here! :slight_smile:

I need to re-read the specs, but I’m still a little unclear on the differentiation made between Z/IP and zipgateway. You say that Z/IP doesn’t specify the use of [D]TLS but zipgateways do. Wouldn’t a zipgateway always use Z/IP to communicate?

On a related note… are you aware of decent low level architectures for ZWave, Z/IP and zipgateway deployments? Everything I’ve found is super high level.


Yes, TLS 1.2 was published in 2008, but the date would be important in this situation is its widespread availability. I believe studies around this show that the halfway mark for its adoption was first reached in 2014. DTLS 1.2, which is based on TLS 1.2, was published in 2012, and is still ways off in terms of general availability. The availability of libraries is a genuine concern here, especially when talking about constrained devices where memory requirements are more prohibitive and their impact on energy consumption/battery life is an important issue.

Z/IP is a means of transporting Z-Wave frames over IP networks. Z-Wave frames are meant to be carried as the payload of Z-Wave RF packets, and are addressed to NodeIDs. Z/IP provides a standardized way for transporting these messages over IP, addressed to IP addresses. Z/IP also specifies the functionality Z/IP clients must share and standardizes the messaging used for managing a Z-Wave network (add, remove, etc.) over IP.

zipgateway is an implementation of an IPv6/4 gateway that bridges/regulates traffic between a Z-Wave network and an IP network. It presents Z-Wave devices in the Z-Wave network it belongs to, as IP devices to the IP network it’s connected to. zipgateway uses Z/IP when communicating with Z/IP clients over IP. It uses DTLS to secure the IP communication, but not because it is mandated by Z/IP. It is perfectly acceptable to build a Z/IP client that cannot do DTLS, but it will be limited to those Command Classes that Z-Wave devices expose without security, and will not be able to initiate network management actions - because zipgateway requires these messages to be DTLS-encapsulated.

I’m not sure I understood what you mean by “low level architectures.” The Z-Wave protocol itself is not public, and direct communication with the Z-Wave hardware requires that you hold a Developer’s Kit Agreement. There are some reverse-engineering attempts out there that provide some communication with the hardware that works just enough to be able to do simple network management and control a small network. They get a lot of it wrong, however, and being able to switch on a few bulbs is not the same as behaving the way controllers in a Z-Wave network are required to (in the different roles they can take when being part of a multi-controller network) by Z-Wave Certification. They’re “fine” if you want to tinker with the lights in your home, but not something you should look at if you’re planning on making a commercial offering.

Along with the Command Class Specification and the RaspberryPi SD card image containing a zipgateway, Sigma also released a bare-bones Z/IP client library: The project contains two sample applications that respectively exemplify how sending and receiving work, but more generally, it provides some simple constructs that wrap the basic actions needed to communicate with zipgateway. It’s all in C and it’s about as low-level as you can get with Z/IP. There’s another implementation of a Z/IP client written in NodeJS here: That one goes as far as providing its own DTLS implementation to avoid dragging in C libraries. It also deals with UDP sockets and is at the same abstraction level as the C project. Just note that neither is directly supported by Sigma Designs, all support for them comes from the community.


Thanks again for taking the time to reply, it’s very much appreciated :slight_smile:

You make a good point re general release and availability of libraries for TLS/DTLS. My thinking, however, is with regard to protecting devices and consumers. IoT is often in the news for all the wrong reasons (cyber attacks, etc) and using protocols which already have proven weakness is a potential concern.

I have follow up questions but I’ll try and post them in separate threads for the sanity of everyone involved :slight_smile: