After MQTT 5.0: The Present and the Future
In the previous blog post, MQTT 5.0: The Next Generation of MQTT, we covered the story of the improvements and enhancements to the MQTT protocol. In this blog, we will cover what has transpired after the release of MQTT 5.0, focusing on its current state, the ongoing coexistence with MQTT 3.1.1, and why no new version is being considered soon. We'll also explore the backward compatibility and future direction of the protocol in the evolving IoT landscape.
Post MQTT 5.0
Another version of MQTT is not being considered at the moment, let alone in progress. MQTT enabled devices could be embedded in hard to reach places with an expected lifetime in decades, unable to be updated. For this reason MQTT should be stable and backwards compatible.
There are no further enhancements to MQTT that seem to have a wide consensus, which would be the prerequisite to creating a new version. On the contrary, some people think that MQTT 5.0 is already too complex, even though it fixes major complaints with MQTT 3.1.1 such as error reporting.
In this context, MQTT 3.1.1 and 5.0 co-exist as separate OASIS standards and will continue to do so. MQTT 5.0 in no way replaces 3.1.1. MQTT 3.1.1 remains the ISO standard. If MQTT 3.1.1 has sufficient features to solve a problem, then it is a valid choice.
The continuing work since 2019 has been the standardization of MQTT-SN, an MQTT like specification for non-TCP transport layers such as UDP and mesh networks.
CVE
A CVE was opened against MQTT in 2020, highlighted on MQTT’s Wikipedia page (at the time of writing). Its description is:
“The MQTT protocol 3.1.1 requires a server to set a timeout value of 1.5 times the Keep-Alive value specified by a client, which allows remote attackers to cause a denial of service (loss of the ability to establish new connections).”
MQTT 5 allows the broker to override the keep alive value requested by the client, if it is set to be excessively long. For public-facing servers, careful thought should be given to who is authorized to connect. This is one of the attacks to consider included in the “MQTT and the NIST Cybersecurity Framework Version 1.0” committee note.
Conclusion
A standard is one of those things that benefits the community that uses it, but needs committed individuals and organizations to bring it to completion. Most of the people involved do it because they are motivated, not because it is going to bring them great renown or recompense. That was the same for MQTT - so thanks to everyone who contributed.
Missed reading the other blogs from The History of MQTT blog series?
Part 2: How MQTT 3.1.1 was Standardized
Part 3: MQTT 5.0: The Next Generation of MQTT
We are celebrating 25 years of MQTT this year. Join us and enroll into our mailing list and we'll keep you updated on all of the happenings this year from MQTT awards to a fireside chat later in the year.
Want to learn more about MQTT concepts, features, and facts? Download our comprehensive ebook.
Ian Craggs
Ian Craggs works for IBM, and has been involved with MQTT for more than 10 years. He wrote the IBM MQTT server Really Small Message Broker which became the inspiration for the Eclipse Mosquitto project. He contributed C client libraries to the Eclipse Paho project at its onset and is now the project leader.
