A maturity model for modern internet standards
Setting objectives and making choices
Along with numerous other national and international organisations involved with the internet infrastructure, we have been promoting the adoption of modern internet standards for many years. The standards we have backed include DNSSEC, IPv6, SPF/DKIM/DMARC and DANE. As that list illustrates, we place particular emphasis on security-related standards, but we have also been pushing for adoption of IPv6, which is concerned with the underlying infrastructure. The importance of making the internet more secure is underscored by news stories on a daily basis. And the limited nature of the IPv4 address space has been causing problems for decades. Until now, however, the promotion of modern internet standards has been lacking a clear vision of the interrelationships, inter-dependencies and relative priorities of the standards. The reason being that infrastructure providers and operators have limited budgets and capacity. In this article, therefore, we present a maturity model that enables the main internet standards to be organised into a matrix.
Figure 1. A maturity model for modern internet standards.
Matrix structure
On the vertical dimension, you'll see various colour-differentiated bands. The lowest band (red/orange) is what we call 'old-school'. The internet standards in this band are classical, largely outmoded standards that have become significantly problematic. For some of the standards, good extensions and add-ons are available – such as DNSSEC for DNS, and STARTTLS, SPF/DKIM/DMARC and DANE for mail. Others require replacement with new standards – such as IPv6 instead of IPv4, and HTTPS instead of HTTP. Most of the extensions and new standards that we are currently promoting hard are in the green band. At the bottom ('modern') you'll see DNSSEC and (dual-stack) IPv6, which you really should be using or implementing very soon. The middle group is made up mainly of security standards, many of which build on DNSSEC's cryptographic infrastructure. The top group contains relatively new and unknown security standards, such as DoH/DoT, RPKI, NTS [1, 2] and SSHFP, which we've labelled 'state-of-the-art'.
Finally, the blue-green band at the very top contains 'future-proof' standards, or combinations of standards, which most people probably wouldn't immediately implement as projects, but which form very important aspirational targets and should therefore be borne in mind when drawing up roadmaps and migration pathways, particularly in relation to IPv6. We have additionally divided the model on the horizontal dimension, to form two regions. In the left-hand region are the security standards for web, mail and end users, respectively. The right-hand region contains the infrastructural standards (IPv6, etc) for the server-side and end users, respectively. We've also slipped in RPKI, although it's primarily a security standard (albeit for internet infrastructure).
Selection and ranking
Assignment of the standards to the various bands depends on two factors. First, the standard's importance relative to the other standards in the same column, and relative to the other standards (or the same) in adjacent columns. There are also hard and soft inter-dependencies between standards, particularly with the standards that build on DNSSEC. DANE, for example, is an extension to SPF and/or DKIM. And, for all three, DNSSEC is recommended but not mandatory. By contrast, DNSSEC is mandatory for DANE, because DANE makes use of DNSSEC's chain of trust back to the root domain. Deciding which standards to include in the model and which to leave out was rather more difficult. Our starting point was that we should include at least the standards on the Forum for Standardisation's 'use-or-explain' list and those promoted by the Platform for Internet Standards – of which SIDN is a member – and tested on the Internet.nl portal. You'll also see that we've included DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT), together with RPKI. The first two were included because they have really taken off in the last few years. RPKI is included because the Platform for Internet Standards is currently considering adding it to the Internet.nl portal. Question marks have been placed by 'DoT' and 'DANE for web' because we aren't sure what will happen to those two standards. DoT is sometimes implemented, but is nowhere near as popular as DoH. And, although DANE for mail has been very much on the up recently, DANE for web has barely got off the ground. The role for which it was developed now seems to be performed by Let's Encrypt certificates. Other standards that might be considered are OpenPGP, the Signal Protocol and ZRTP, (for end-to-end encryption (E2EE) of, respectively, mail/files, messages and internet telephony), and OpenVPN and WireGuard (for establishing VPN connections). However, all those standards are more removed from the generic basic infrastructure of the internet.
Setting objectives and making choices
We hope that you can use our model to make a higher-level appraisal of your infrastructure's current status, to define objectives regarding the level you want to reach, and to decide where to begin (as with project portfolio management), in view of the interdependencies between standards. One thing we ourselves are considering is using the model as a basis for collating all the information about modern internet standards that we have published over the years. For the moment, however, that remains merely an idea. For full details of the hands-on articles we've published about DNSSEC signing on authoritative DNS servers and validation on (caching) resolvers, see this overview article and our DNSSEC section. In addition, we recently published four detailed hands-on articles on the implementation of SPF/DKIM/DMARC and DANE on the Postfix and Exim mail servers, respectively:
You can also use this convenient checklist:
Finally, feedback on the maturity model is, of course, welcome.