Internet-Draft Defined-Trust Transport (DeftT) November 2022
Nichols, et al. Expires 24 May 2023 [Page]
Network Working Group
Intended Status:
K. Nichols
Pollere LLC
V. Jacobson
R. King
Operant Networks Inc.

Defined-Trust Transport (DeftT) Protocol for Limited Domains


This document describes a broadcast-friendly, many-to-many Defined-trust Transport (DeftT) that makes it simple to express and enforce application and deployment specific integrity, authentication, access control and behavior constraints directly in the protocol stack. DeftT combined with IPv6 multicast and modern hardware-based methods for securing keys and code provides an easy to use foundation for secure and efficient communications in Limited Domains (RFC8799), in particular for Operational Technology (OT) networks.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 May 2023.

Table of Contents

1. Introduction

Decades of success in providing IP connectivity over any physical media ("IP over everything") has commoditized IP-based communications. This makes IP an attractive option for Internet of Things (IoT), Industrial Control Systems (ICS) and Operational Technologies (OT) applications like building automation, embedded systems and transportation control, that previously required proprietary or analog connectivity. For the energy sector in particular, the growing use of Distributed Energy Resources (DER) like residential solar has created interest in low cost commodity networked devices but with added features for security, robustness and low-power operation [MODOT][OPR][CIDS]. Other emerging uses include connecting controls and sensors in nuclear power plants and carbon capture monitoring [DIGN][IIOT].

While moving to an IP network layer is a major advance for OT, current Internet transport options are a poor match to its needs. TCP generalized the Arpanet transport notion of a packet "phone call" between two endpoints into a generic, reliable, bi-directional bytestream working over IP's stateless unidirectional best-effort delivery model. Just as the voice phone call model spawned a global voice communications infrastructure in the 1900s, TCP/IP's two-party packet sessions are the foundation of today's global data communication infrastructure. But "good for global communication" isn't the same as "good for everything". OT applications tend to be localized and communication-intensive with a primary function of coordination and control and communication patterns that are many-to-many. Implementing many-to-many applications over two-party transport sessions changes the configuration burden and traffic scaling from the native media's O(n) to O(n2) (see Section 1.2). Further, as OT devices have specific, highly prescribed roles with strict constraints on "who can say what to which", the opacity of modern encrypted two-party sessions can make it impossible to enforce or audit these constraints.

This memo describes a new transport protocol, Defined-trust Transport (DeftT) for Limited Domains [RFC8799] in which multipoint communications are enabled through use of a named collection abstraction and secured by an integrated trust management engine. DeftT employs multicast (e.g., IPv6 link-local [RFC4291]), distributed set reconciliation PDU transport, a flexible pub/sub API, chain-of-trust membership identities, and rules that define the local context and communication constraints of a deployment in a declarative language. The rules are used by DeftT's runtime trust management engine to enforce adherence to the constraints. The resulting system is efficient, secure and scalable: communication, signing and validation costs are constant per-publication, independent of the richness and complexity of the deployment's constraints or the number of entites deployed.

Device enrollment consists of securely configuring a device with identity bundles, each containing a trust anchor certificate, a compact and secured copy of the trust rules, and a membership identity which comprises a secret signing key plus its public certificate together with all the certs in its signing chain (which can be used to confer attributes) terminated at the trust anchor. The signing chains of all communicating members share a common trust anchor and the rules define legal signing chains, so the bundle suffices for a member to authenticate and authorize communication from peers and vice-versa. New members can join and communicate without labor intensive and error-prone device-to-device association configuration.

1.1. Environment and use

Due to physical deployment constraints and the high cost of wiring, OT networks preferentially use radio as their communication medium. Use of wires is impossible in many installations (untethered Things, adding connected devices to home and infrastructure networks, vehicular uses, etc.). Wiring costs far exceed the cost of current System-on-Chip Wi-Fi IoT devices and the cost differential is increasing [WSEN][COST]. For example, the popular ESP32 is a 32bit/320KB SRAM RISC with 60 analog and digital I/O channels plus complete 802.11b/g/n and bluetooth radios on a 5mm die that consumes 70uW in normal operation. It currently costs $0.13 in small quantities while the estimated cost of pulling cable to retrofit nuclear power plants is presently $2000/ft [NPPI].

OT applications are frequently Limited Domain with communications that are local, have a many-to-many pattern, and use application-specific identifiers ("topics") for rendezvous. This fits the generic Publish/Subscribe communications model ("pub/sub") and, as table 1 in [PRAG] shows, nine of the eleven most widely used IoT protocols use a topic-based pub/sub transport. For example MQTT, an open standard developed in 1999 to monitor oil pipelines over satellite [MQTT][MHST], is now likely the most widely used IoT protocol ( Microsoft Azure, Amazon AWS, Google Cloud, and Cloudflare all offer hosted MQTT brokers for collecting and connecting sensor and control data in addition to providing local pub/sub in buildings, factories and homes. Pub/sub protocols communicate by using the same topic but need no knowledge of one another. These protocols are typically implemented as an application layer protocol over a two-party Internet transport like TCP or TLS which require in-advance configuration of peer addresses and credentials at each endpoint and incur unnecessary communications overhead Section 1.2.

1.2. Transporting information

The smart lighting example of Figure 1 illustrates a topic-based pub/sub application layer protocol in a wireless broadcast subnet. Each switch is set up to do triple-duty: one click of its on/off paddle controls some particular light(s), two clicks control all the lights in the room, and three clicks control all available lights (five kitchen plus the four den ceiling). Thus a switch button push may require a message to as many as nine light devices. On a broadcast physical network each packet sent by the switch is heard by all nine devices. IPv6 link-level multicast provides a network layer that can take advantage of this but current IP transport protocols cannot. Instead, each switch needs to establish nine bi-lateral transport associations in order to send the published message for all lights to turn on. Communicating devices must be configured with each other's IP address and enrolled identity so, for n devices, both the configuration burden and traffic scale as O(n2). For example, when an "all" event is triggered, every light's radio will receive nine messages but discard the eight determined to be "not mine." If a device sleeps, is out-of-range, or has partial connectivity, additional application-level mechanisms have to be implemented to accommodate it.

iotDeftt iotDeftt kitchen ceiling kitchen ceiling kitchen all subscriptions den ceiling den ceiling den all subscriptions kitchen counter kitchen counter kitchen all subscriptions den switch den ceiling den all 1: 2: 3: clicks pub topic kitchen switch kitchen counter kitchen all 1: 2: 3: clicks pub topic
Figure 1: Smart lighting use of Pub/Sub

MQTT and other broker-based pub/sub approaches mitigate this by adding a broker where all transport connections terminate (Figure 2). Each entity makes a single TCP transport connection with the broker and tells the broker the topics to which it subscribes. Thus the kitchen switch uses its single transport session to publish commands to topic kitchen/counter, topic kitchen or all. The kitchen counter light uses its broker session to subscribe to those same three topics. The kitchen ceiling lights subscribe to topics kitchen ceiling, kitchen and all while den ceiling lights subscribe to topics den ceiling, den and all. Use of a broker reduces the configuration burden from O(n2) to O(n): 18 transport sessions to 11 for this simple example but for realistic deployments the reduction is often greater. There are other advantages: besides their own IP addresses and identities, devices only need to be configured with those of the broker. Further, the broker can store messages for temporarily unavailable devices and use the transport session to confirm the reception of messages. This approach is popular because the pub/sub application layer protocol provides an easy-to-use API and the broker reduces configuration burden while maintaining secure, reliable delivery and providing short-term in-network storage of messages. Still the broker implementation doubles the per-device configuration burden by adding an entity that exists only to implement transport and traffic still scales as O(n2), e.g., any switch publishing to all lights results in ten (unicast) message transfers over the wifi network. Further, the broker introduces a single point of failure into a network that is richly connected physically.

iotMQTT iotMQTT MQTT broker kitchen ceiling den ceiling kitchen counter den switch den ceiling den all 1: 2: 3: clicks pub topic kitchen switch kitchen counter kitchen all 1: 2: 3: clicks pub topic ←sub : den ceiling, den, all ←sub : kitchen ceiling, kitchen, all ←sub : kitchen counter,             kitchen, all
Figure 2: Brokers enable Pub/Sub over connection/session protocols

Clearly, a transport protocol able to exploit a physical network's broadcast capabilities would better suit this problem. (Since unicast is just multicast restricted to peer sets of size 2, a multicast transport handles all unicast use cases but the converse is not true.) In the distributed systems literature, communication associated with coordinating shared objectives has long been modeled as distributed set reconciliation [WegmanC81][Demers87]. In this approach, each domain of discourse is some named set, e.g., myhouse.iot. Each event or action, e.g., a switch button press, is added as a new element to the instance of myhouse.iot at its point of origin then the reconciliation process ensures that every instance of myhouse.iot has this element. In 2000, [MINSKY03] developed a broadcast-capable set reconciliation algorithm whose communication cost equaled the set instance differences (which is optimal) but its polynomial computational cost impeded adoption. In 2011, [DIFF] used Invertible Bloom Lookup Tables (IBLTs) [IBLT][MPSR] to create a simple distributed set reconciliation algorithm providing both optimal communication and computational cost. DeftT uses this algorithm (see Section 2.2) and takes advantage of IPv6's self-configuring link local multicast to avoid all manual configuration and external dependencies. This restores the system design to Figure 1 where each device has a single, auto-configured transport that makes use of the broadcast radio medium without need for a broker or multiple transport associations. Each button push is broadcast exactly once to be added to the distributed set.

1.3. Securing information

Conventional session-based transports combine publications with independent topics and purposes under a single session key, providing privacy by encrypting the sessions between endpoints. The credentials of endpoints (e.g., a website) are usually attested by a third party certificate authority (CA) and bound to a DNS name; each secure transport association requires the exchange of these credentials which allows for secure exchange of a nonce symmetric key. In Figure 2 each transport session is a separate security association where each device needs to validate the broker's credential and the broker has to validate each device's. This ensures that transport associations are between two enrolled devices (protecting against outsider and some MITM attacks) but, once the transport session has been established there are no constraints whatsoever on what devices can say. Clearly, this does not protect against the insider attacks that currently plague OT, e.g., [CHPT] description of a lightbulb taking over a network. For example, the basic function of a light switch requires that it be allowed to tell a light to turn on or off but it almost certainly shouldn't be allowed to tell the light to overwrite its firmware (fwupd), even though "on/off" and "fwupd" are both standard capabilities of most smart light APIs. Once a TLS session is established, the transport handles "fwupd" publications the same way as "on/off" publications. Such attacks can be prevented by requiring trust management that operates per-publication, using trust rules that enable the "fwupd" from the light switch to be rejected. Combining per-publication trust decisions with many-to-many communications over broadcast infrastructure requires per-publication signing rather than session-based signing. Securing each publication rather than the path it arrives on deals with a wider spectrum of threats while avoiding the quadratic session state and traffic burden.

This requires a trust management system such as [DLOG] where each publisher is responsible for supplying all of the "who/what/where/when" information needed for each subscriber to prove the publication complies with system policies. In OT, valid messages conform to rigid standards on syntax and semantics [IEC61850][ISO9506MMS][ONE][MATR][OSCAL][NMUD][ST][ZCL] that can be combined with site-specific requirements on identities and capabilities to create a system's trust requirements. Instead of vulnerable third-party CAs [W509], sites can employ a local root of trust and locally created certificates. If, as described in [DLOG], the system's trust requirements are expressed using a declarative framework, they can be validated for consistency and completeness. These trust requirements in the declarative language can be converted to a compact runtime form which can be authorized and secured via signing with the system trust anchor. This trust schema (TS) is a type of certificate that can be distributed, validated and updated using on-device trusted enclaves [TPM][HSE][ATZ] as part of the device enrollment process. In DeftT's publication-based transport, the TS can be used to both construct and validate publications, guaranteeing that all parts of the system always conform to and enforce the same rules, even as those rules evolve to meet new threats (more in Section 2.5.1). DeftT embeds the trust management mechanism described above directly in the publish and subscribe data paths as shown below:

trustElements trustElements-rfc Device Specific Code Trust Schema Shim Subscribe Publish Publication Validator Publication Builder Network Trust Schema Compiler Site Policy Standard Conformance Trust Requirements: On-Device App
Figure 3: Trust management elements of DeftT.

This approach extends LangSec's [LANG] "be definite in what you accept" principle by using the authenticated common ruleset for belt-and-suspenders enforcement at both publication and subscription functions of the transport. If an application asks the Publication Builder to publish something for which the TS shows it lacks credentials, an error is thrown and nothing is published. Independently, the Publication Validator ignores publications that:

  • don't have a locally validated, complete signing chain for the credential that signed it
  • the TS shows its signing chain isn't appropriate for this publication
  • have a publication signature that doesn't validate

Note that since an application's subscriptions determine which publications it wants, only certificates from chains that can sign publications matching the subscriptions need to be validated or retained. Thus a device's communication state burden and computation costs are a function of how many different things are allowed to talk to it but not how many things it talks to or the total number of devices in the system. In particular, event driven, publish-only devices like sensors spend no time or space on validation. Unlike most 'secure' systems, adding additional constraints to trust schemas to reduce attack surface results in devices doing less work.

A Limited Domain where all the members communicate via DeftT and are configured with the same trust anchor, TS, and an identity that conforms to the TS and is signed by the trust anchor at its root are in a Defined-trust Communications (DC) Trust Domain (TD). Note that the particular rules for any deployment are application-specific (e.g., Is it home IoT or a nuclear power plant?) and site-specific (specific form of credential and idiosyncrasies in rules) which DeftT accommodates by being invoked with a ruleset particular for a deployment. We anticipate that the efforts to create common data models for specific sectors will lead to easier and more forms-based configuration of DeftT deployments. (DC

1.4. Current status

An open-source Defined-trust Communications Toolkit [DCT] with an example implementation of DeftT is maintained by the corresponding author's company. [DCT] has examples of using DeftT to implement secure brokerless message-based pub/sub using UDP/IPv6 multicast and unicast UDP/TCP and include extending a Trust Domain via a unicast connection or between two broadcast network segments. Working implementations and performance improvements are occasionally added to the repository.

Massive build out of the renewable energy sector is driving connectivity needs for both monitoring and control. Author King's company, Operant, is currently developing extensions of DeftT in a mix of open-source and proprietary software tailored for commercial deployment in support of distributed energy resources (DER). Current small scale use cases have performed well and expanded usage is planned. Pollere is also working on home IoT uses. As the needs of our use cases expand, the Defined-trust Communications (DC) architecture will evolve. This reflects the development philosophy of DC to start from solving useful problems with a well-defined scope and extend from there. DeftT's code is open-source, as befits any communications protocol, but even more critical for one attempting to offer security. DCT itself makes use of the open source cryptographic library libsodium [SOD] and the project is open to feedback on potential security issues as well as hearing from potential collaborators.

2. DeftT and Defined-trust Communications

DeftT synchronizes and secures communications between enrolled members of a Limited Domain [RFC8799]. Like QUIC, DeftT is a user-space transport protocol that sits between an application and a system-provided transport like UDP or UDP multicast. DeftT's set reconciliation communication model between multiple parties contrasts with the bilateral communication model of TCP or QUIC where a source and a destination coordinate with one another to transport information. DeftT collections are denoted by structured names which include the identifier of a particular TS. Set reconciliation is used by a protocol that synchronizes the currently active elements of DeftT collections among all members. Communicating DeftTs may hold different subsets of the collection at any time (e.g., immediately after entities add elements to the collection) but its synchronization protocol ensures they all converge to holding the complete set of elements within a few round-trip-times following the changes.

2.1. DeftT role in application communications

Applications use DeftT to add to and access from a distributed collection of Publications. DeftT enforces "who can say what to which" as well as providing required integrity, authenticity and confidentiality. A DeftT instance both constructs and validates all Publications against the TS's formal, validated rules transparently to applications. The compiled binary TS is distributed as a trust-root-signed certificate and that certificate's thumbprint (see Section 2.6.1 and Section 4) uniquely identifies a trust domain (TD) in DeftT PDU headers. Each DeftT is configured with the trust anchor used in the TD, the TS cert, and its own credentials for membership in the TD. Credentials comprise a unique private signing key along with a public certificate chain rooted at the TD's trust anchor, contain the capabilities of the member identity and have the member's public signing key in its leaf certificate. Communicating DeftTs must be in the same TD, i.e., credentials trace to the TD root of trust and follow an identical TS. Each DeftT must publish its credentials to the TD's certificate collection in order to join the TD. DeftT validates credentials as a certificate chain against the TS and does not accept Publications without a fully validated signer identity. This provides fully distributed policy enforcement for the TD without relying on a secured-perimeter physical network and/or extensive per-device configuration. DeftT can share an IP network with non-DeftT traffic as well as DeftT traffic of a different TD. Privacy via AEAD PDU content encryption is automatically handled within DeftT.

transportBD0 transportBD0v2 Application system- p r ovided transport DeftT information to convey information of inte r est local adds to collection others’ adds to collection state of collection
Figure 4: DeftT's external interaction in a network stack

Figure 4 shows the data flow of a DeftT instance. An application-specific format is used to exchange information with an application. DeftT uses its TS to package this information into Publications that is added to its local view of the collection. DeftT's communication goal is to synchronize the state of this collection for all members. To this end, two types of PDUs are used to manage the set: cState and cAdd. cStates are used to report the state of the local collection; cAdds are used to transport Publications to other TD members that need them. These PDUs are broadcast on their subnet (e.g., UDP multicast).

2.2. Set Reconciliation enables a broadcast-friendly transport

DeftT's collection management, described above, is efficiently realized using set reconciliation where the collection is the set and the Publications are the elements of the set. In particular, IBLTs [DIFF][IBLT][MPSR] solve the multi-party set-difference problem efficiently without the use of prior context and with communication proportional to the size of the difference between the sets being compared. DeftT's collection synchronization is carried out in its syncps module. Syncps announces its collection state (set of currently known Publications) by sending a cState PDU containing an IBLT. The cState serves as a query for additional data that isn't reflected in its local state. Receipt of a cState performs three simultaneous functions: (1) announces new Publications, (2) notifies of Publications that peer member(s) are missing and (3) acknowledges Publication receipt. The first may prompt the recipient to send a cState to get the new Publication(s). The second results in sending a cAdd PDU containing all the missing and locally available Publications that will fit. The third may result in a progress notification sent up the protocol stack so anything waiting for delivery confirmation can proceed.

On broadcast media, syncps uses the cStates it hears to suppress sending its own and listens for any cAdds that add to its cState. This means that one-to-many Publications require one cState and one cAdd to be sent, independent of the number of members desiring the Publication (the theoretical minimum possible for reliable delivery). The digest size of a cState can be controlled by Publication lifetime, dynamically constructing the digest to maximize communication progress [Graphene][Graphene19] and, if necessary for a large network, dynamically adapting topic specificity.

A cAdd with new Publication(s) responds to a particular cState so a receiving syncps removes that cState as a pending query (it will be replaced with a new cState with the addition of the new items). Any DeftT that is missing a Publication (due to being out-of-range or asleep, etc.) can receive it from any other DeftT. A syncps will continue to send cAdds as long as cStates are received that don't contain some of their Publications. This results in reliability that is subscriber-oriented, not publisher-oriented and is efficient for broadcast media, particularly with protocol features designed to prevent multiple redundant broadcasts.

2.3. Information movement is based on trust rules

Although the Internet's transport and routing protocols emphasize universal reachability with packet forwarding based on destination, a significant number of applications neither need nor desire to transit the Internet (e.g., see [RFC8799]). This is true for a wide class of OT application. Further, the liberal acceptance of packets while depending on the good sending practices of others leaves critical applications open to misconfiguration and attacks. DeftT only moves its Publications in accordance with fully specified trust rules. This approach differs from Internet forwarding but offers new opportunities to address the specific security requirements of applications in many Limited Domains.

DeftTs on the same subnet may not be in the same TD and DeftTs in the same TD may not be on the same subnet. In the former case, cState and cAdd PDUs of different TDs are differentiated by the trust domain id (thumbprint of the TD's TS certificate) which can be used to determine whether or not to process a PDU. A particular sync zone is managed on a single subnet: cState and cAdds are not forwarded off that subnet. Trust-based Relays connect Publications of separate sync zones that share the same TD. A Relay is currently implemented by an application running on a device with a DeftT network interface on each subnet (two or more) or with multiple DeftT interfaces to the same subnet where each uses a different but compatible version of the others' TS. Each DeftT participates in a different sync zone and has a member identity valid for its sync zone. All DeftTs of a sync zone use an identical TS to validate Publications. Publications that arrive via one DeftT may be added to the collections of other DeftTs of the Relay after validation. Only Publications are relayed between subnets and the Publication must validate against the TS of each DeftT. Thus cAdd encryption is unique per subnet/sync zone.

As Relays do not create Publications, they use a special DeftT API module (a "shim", see Appendix A) that performs "pass-through" of valid Publications from the application. The Relay of Figure 5-left is on three separate wireless subnets. If all three DeftTs are using an identical TS, a new validated cert added to the cert store of its incoming DeftT then passed to the other two, where each will validate it before adding to its own cert store (superfluous in this case, but not a lot of overhead for additional security). When a valid Publication is received at one DeftT, it is passed to the other two DeftTs to validate against their copies of the TS and published if it passes.

relayextend relayextend Relay b r oadcast segment 0 b r oadcast segment 2 b r oadcast segment 1 ch0 ch1 ch2 local network 1 local network 2 Relay Relay cell connection, tcp tunnel, etc.
Figure 5: Relays connect subnets

A Relay may have different membership identities and TSs for each DeftT but must have the same trust anchor. Relays can also connect subsets of a TD, either proper subsets or overlapping subsets. Publications that are undefined for a particular DeftT will be silently discarded when they do not validate. This means the Relay application of Figure 5-left can remain the same but Publications will only be published to a different subnet if its DeftT has that format in its TS. Relays may filter Publications at the application level or restrict subscriptions on some of their DeftT interfaces. Figure 5-right shows extending a TD geographically by using a unicast connection (e.g., over a cell line or tunnel over the Internet) between two Relays which also interface to local broadcast subnets. Everything on each local subnet shows up on the other. A TD subset could be used here to limit the types of Publications sent on the remote link, e.g., logs or alerts. Using this approach in Figure 5-right, local communications for subnet 1 can be kept local while subnet 2 might send commands and/or collect log files from subnet 1.

More generally, Relays can form a mesh of broadcast subnets with no additional configuration (i.e., Relays on a broadcast network do not need to be configured with others' identities). The mesh is efficient: publications are only added to an individual DeftT's collection once regardless of how it is received. More on the applicability of DeftT meshes is in Section 3.

2.4. DeftT and congestion control

Each DeftT instance manages its collection on a single broadcast subnet (since unicast is a proper subset of multicast, a point-to-point connection is viewed as a trivial broadcast subnet) thus only has to deal with that subnet's congestion. As described in the previous section, a device connected to two or more subnets may create DeftT instances having the same collection name on each subnet with a Publication Relay between them but DeftT never forwards PDUs between subnets. It is, of course, possible to run DeftT over an extended broadcast network like a PIM multicast group but the result will generally require more configuration and be less reliable, efficient and secure than DeftT's self-configuring peer-to-peer Relay mesh.

DeftT sends at most one copy of any publication over any subnet, independent of the number of publishers and subscribers on the subnet. Thus the total DeftT traffic on a subnet is strictly upper bounded by the application-level publication rate. As described in Section 2.1, DeftTs publish a cState specifying the set elements they currently hold. If a DeftT receives a cState specifying the same elements (Publications) it holds, it doesn't send its cState. Thus the upper bound on cState publication rate is the number of peers on the subnet divided by the cState lifetime (typically seconds to minutes) but is typically one per cState lifetime due to the duplicate suppression. Each peer can send at most one cAdd in response to a cState. This creates a strict request/response flow balance which upper bounds the cAdd traffic rate to (number of peers - 1) times the cState publication rate. The flow balance ensures an instance can't send a new cState until it's previous one is either obsoleted by a cAdd or times out. Similarly a cAdd can only be sent in response to the cState which it obsoletes. Thus the number of outstanding PDUs per instance is at most one and DeftT cannot cause subnet congestion collapse.

If a Relay is used to extend a TD over a path whose bandwidth delay product is many times larger than typical subnet MTUs (1.5-9KB), the one-outstanding-PDU per peer constraint can result in poor performance (1500 bytes per 100ms transcontinental RTT is only 120Kbps). DeftT can run over any lower layer transport and stream-oriented transports like TCP or QUIC allow for a 'virtual MTU' that can be set large enough for DeftT to relay at or above the average publication rate (the default is 64KB which can relay up to 5Mbps of publications into a 100ms RTT). In this case there can be many lower layer packets in flight for each DeftT cAdd PDU but their congestion control is handled by TCP or QUIC.

2.5. Defined-trust management engine

OT applications are distinguished (from general digital communications) by well-defined roles, behaviors and relationships that constrain the information to be communicated (e.g., as noted in [RFC8520]). Structured abstract profiles characterize the capabilities and attributes of Things and can be machine-readable (e.g., [ONE][RFC8520][ZCL]). Energy applications in particular have defined strict role-based access controls [IEC] though proposed enforcement approaches require interaction of a number of mechanisms across the communications stack [NERC]. Structured profiles and rules strictly define permitted behaviors including what types of messages can be issued or acted on; undefined behaviors are not permitted. These rules, along with local configuration, are incorporated directly into the TSs used by DeftT's integrated trust management engine to both prohibit undefined behaviors and to construct compliant Publications. This not only provides a fine-grained security but a highly usable security, an approach that can make an application writer's job easier since applications do not need to contain local configuration and security considerations.

DCT [DCT] includes a language for expressing the rules of communication, its compiler, and other tools to create the credentials a DeftT needs at run-time to function in a particular TD.

2.5.1. About trust schemas

DC's use of trust schemas has been influenced by [SNC][SDSI] and by trust management defined by Blaze et. al. [DTM] as the study of security policies, security credentials, and trust relationships. Li et. al. [DLOG] refined some trust management concepts arguing that the expressive language for the rules should be declarative (as opposed to the original work). This body of work influences that of trust schemas. Trust schemas for Named-Data Networking were described by Yu et al [STNDN] as "an overall trust model of an application, i.e., what is (are) legitimate key(s) for each data packet that the application produces or consumes." [STNDN] gave a general description of how trust schema rules might be used by an authenticating interpreter finite state machine to validate packets. A new approach to both trust schema language and their integration with applications was introduced in [NDNW] and extended in [DNMP][IOTK][DCT]. In this approach, a trust schema is analogous to the plans for constructing a building. Construction plans serve multiple purposes:

  1. Allow permitting authorities to check that the design meets applicable codes
  2. Show construction workers what to build
  3. Let building inspectors validate that as-permitted matches as-built

Construction plans get this flexibility from being declarative: they describe "what", not "how". As noted in p4 of [DLOG], a declarative trust management specification based on a formal foundation guarantees all parties to a communication have the same notion of what constitutes compliance. This allows a single schema to provide the same protection as dozens of manually configured, per-node ACL rules. This approach is a critical part of DC.

VerSec, an implementation approach to creating trust schemas, is included with the DC Toolkit [DCT]. VerSec includes a declarative schema specification language with a compiler that checks the formal soundness of a specification (case 1 above) then converts it to a signed, compact, binary form. The binary form is used by DeftT to build (case 2) or validate (case 3) the Publications of a sync collection. Publications (whose format is covered in Appendix B) have names, content and signatures in TLVs. DC Certificates (Section 2.6.1,Appendix B.2) are a type of Publication, allowing them to be distributed and validated using DeftT, but they are subject to many additional constraints that ensure DeftT's security framework is well-founded.

2.5.2. A language for DeftT trust schemas

The VerSec language follows LangSec [LANG] principles to minimize misconfiguration and attack surface. Its structure is amenable to a forms-based input or a translator from the structured data profiles often used by standards [ONE][RFC8520][ZCL]. Declarative languages are expressive and strongly typed, so they can express the constructs of these standards in their trust rules. VerSec continues to evolve to add new features as its application domain is expanded and the latest released version is at [DCT]. Other languages and compilers are possible as long as they supply the features and output needed for DeftT.

A TS expresses the intent for an application domain's communications in fine-grained rules: "who can say what." Credentials that define "who" are specified along with complete definitions of "what". DC is targeted at OT networking where administrative control is explicit and it is not unreasonable to assume that identities and trust rules are securely configured at every device. The TS details the meaning and relationship of individual components of the filename-like names (URI syntax RFC3986) of Publications and certificates. A simple TS (Figure 6) defines a Publication in this TD as #pub with a six component name. The strings between the slashes are the tags used to reference each component in the structured format and in the run-time schema library. An example of this usage is the component constraint following the "&" where ts is a timestamp (64-bit unix timepoints in microseconds) which will be set with the current time when a publication is created. The first component gets its value from the variable "domain" and #pubPrefix is designated as having this value so that the TS contains information on what part of the name is considered common prefix. For the sake of simplicity, the Figure 6 trust schema puts no constraints on other name components (not the usual case for OT applications) but requires that Publications of template #pub are signed by ("<=") a mbrCert whose format and signing rule (signed by a netCert) is also defined. The "Validator" lines specify cryptographic signing and validation algorithms from DCT's run-time library for both the Publication and the cAdd PDU that carries Publications. Here, both use EdDSA signing. This schema has no constraints on the inner four name components (additional constraints could be imposed by the application but they won't be enforced by DeftT). Member identity comes from a mbrCert (including private key) which allows it to create legal communications. The signing certificate MUST adhere to the TS; Publications or cAdds with unknown signers are discarded. The timestamp component is used to prevent replay attacks. DeftT is structured to add its certificate identity chain to the TD certificate collection (see Section 2.6.2) when instantiated, making its identity available to all other members of the TD. Using the pre-configured TD trust anchor and TS, any member can verify the identity of any other member. This approach means members are not configured with identities of other members of a trust domain and new entities can join a trust domain at any time.

#pub: /_domain/trgt/topic/loc/arg/_ts & { _ts: timestamp() } <= mbrCert
mbrCert:       _domain/_mbrType/_mbrId/_keyinfo <= netCert
netCert:        _domain/_keyinfo
#pubPrefix:     _domain
#pubValidator:  "EdDSA"
#cAddValidator: "EdDSA"
_domain:        "example"
_keyinfo:       "KEY"/_/"dct"/_
Figure 6: An example trust schema

To keep the trust schema both compact and secure, it is compiled into a binary format that becomes the content of a TS certificate. [DCT]'s schemaCompile converts the text version (e.g. Figure 6) of the TS into a binary output file as well as outputing diagnostics (see Figure 7) used to confirm the intent of the trust rules (and to flag problems). TD member entities are configured with the TD's trust anchor, the TS cert and their own identity. Secure device configuration and on-boarding should be carried out using appropriate applicable best practices [TATT][DMR][IAWS][TPM][RFC8995].

Publication #pub:
  parameters: trgt topic loc arg
  tags: /_domain/trgt/topic/loc/arg/_ts
Publication #pubPrefix:
  tags: /_domain
Publication #pubValidator:
  tags: /"EdDSA"
Publication #cAddValidator:
  tags: /"EdDSA"
Certificate templates:
  cert mbrCert: /"example"/_mbrType/_mbrIdId/"KEY"/_/"dct"/_
  cert netCert: /"example"/"KEY"/_/"dct"/_
binary schema  is 301 bytes
Figure 7: schemaCompile diagnostic output for example of [Figure 6]

This simple TS provides useful security, using enrolled identities both to constrain communications actions (via its #pub format) and to convey membership. To increase security, more detail can be added to Figure 6. For example, different types of members can be created, e.g., "admin" and "sensor", and communications privacy can added by specifying AEAD Validator to encrypt cAdds. To make those member types meaningful, Publications can be defined such that only admins can issue commands and only sensors can issue status, a role-based security policy. Specifying the AEAD validator means that at least one member of the TD will need the key maker capability in its signing chain. In Figure 7 key maker capability is added to the signing chain of all sensors. WIth AEAD specified, a key maker is elected during DeftT start up and that key maker creates, publishes, and periodically updates the shared encryption key. (Late joining entities are able to discover that a key maker has already been chosen.) These are the only changes required in order to increase security and add privacy: neither code nor binary needs to change and DeftT handles all aspects of validators. The unique approach to integrating the communication rules into the transport makes it easy to produce secure application code.

adminCert:  mbrCert & { _mbrType: "admin" } <= netCert
sensorCert: mbrCert & { _mbrType: "sensor" } <= kmCap
capCert:    _network/"CAP"/_capId/_capArg/_keyinfo <= netCert
kmCap:      capCert & { _capId: "KM" }
#reportPub: #pub & {topic:"status"} <= sensorCert
#commandPub: #pub & {topic:"command"} <= adminCert
#cAddValidator: "EdDSA"
Figure 8: Enhancing security in the example trust schema

In DC, identities include the member cert and its entire signing chain. By adding capabilities or attributes via certificates of a member cert's signing chain, attribute-based security policies can be implemented without the need for separate servers accessed at run-time (and the attendant security weaknesses). More on DC certs will be covered in Section 2.6.

Converting desired behavioral structure into a TS is the major task of applying Defined-trust Communications to an application domain. Once completed, all the deployment information is contained in the TS. Although a particular TS cert defines a particular TD, the text version of a TS can be re-used for related applications. For example, a home IoT TS could be edited to be specific to a particular home network or a solar rooftop neighborhood and then signed with a chosen trust anchor.

2.6. DC certificates and identity bundles

DC's approach is partially based on the seminal SDSI [SDSI] approach to create user-friendly namespaces that create transitive trust through a certificate (cert) chain that validates locally controlled and managed keys, rather than requiring a global Public Key Infrastructure (PKI). Certificates are created that have a particular context in which they should be utilized and trusted rather than conferring total authority. This is particularly useful in OT where communicating applications share an administrative control and using a third party to certify identity is both unnecessary and a potential security vulnerability. Well-formed certificates and identity deployment are critical elements of DC. This section describes certificate requirements and the construction and installation of an identity bundle. DCT includes utilities to create certs and bundles.

2.6.1. About DC certificates

Use of third party certificate authorities (CAs) is often antithetical to OT security needs. Any use of a CA (remote or local) results in a single point of failure that greatly reduces system reliability. Employing an architecture with a single, local, trust root cert (trust anchor) and no CAs simplifies trust management and avoids the well-known CA federation and delegation issues and other weaknesses of the X.509 architecture (summarized at [W509], original references include [RSK][NVR]). DC certs (see Appendix B.2) can be generated and signed locally so there is no reason to aggregate a plethora of unrelated claims into one cert (avoiding the Aggregation problem [W509]).

A DC cert's one and only Subject Name is the name of the Publication that contains the public key as its content and neither name nor content are allowed to contain any optional information or extensions. Certificates are created with a lifetime; local production means cert lifetimes can be just as long as necessary (as recommended in [RFC2693]) so there's no need for the code burden and increased attack surface associated with certificate revocation lists (CRLs) or use of on-line certificate status protocol (OSCP). Keys that require longer lifetimes, like device keys, get new certs before the current ones expire and may distribute those through DeftT. If there is a need to exclude previously authorized identities from a TD, there are a variety of options. The most expedient is via use of the AEAD Validator by ensuring that the group key maker(s) of a TD exclude that entity from subsequent symmetric key distributions until the identity cert expires. Another option is to publish an identity that supplants that of the excluded member. Though more complex, it is also possible to distribute a new TS and identities (without changing the trust anchor), e.g., using remote attestation via the TPM.

From Section 2.5, a member cert is granted attributes and capabilities in the TS via the certs that appear in its signing chain. Thus member certs are always accompanied by their full signing chains, both when installed and when the member publishes its identity (without the private key, of course) to the cert collection. Without the entire chain, a signer's right to issue publications cannot be validated. Every signing chain in the TD has the same trust anchor at its root. DC cert validation is according to the TS which may specify attributes and capabilities for Publication signing from any certificate in the chain. For this model to be well founded, each cert's "key locator" must uniquely identify the cert that actually signed it. This property ensures that each locator resolves to one and only one signing chain. A DC cert's key locator is a thumbprint, a SHA256 hash of the entire signer's Publication (name, content, key locator, and signature), ensuring that each locator resolves to one and only one cert and signing chain. Use of the thumbprint locator ensures that DC certs are not open to the substitution attacks of name-based locators like X.509's "Authority Key Identifier" and "Issuer" [ConfusedDep][CAvuln][TLSvuln].

2.6.2. Identity bundles

Identity bundles hold the certificates needed to participate in a TD: trust anchor, trust schema, the member's identity chain, and the private key corresponding to the leaf certificate of that member's chain. Identity bundles are intended to be installed securely when a device is first commissioned (out-of-band) for a network. The public certs can be placed in a file in a well-known location; only the private key of the bundle must be secured. The process of enrolling a device by provisioning an initial secret and identity in the form of public-private key pair and using this information to securely onboard a device to a network has a long history. Current and emergent industry best practices provide a range of approaches for secure installation and update of private keys. For example, the private key of the bundle can be secured using the Trusted Platform Module, the best current practice in IoT [TATT][DMR][IAWS][TPM][OTPM][SIOT][QTPM][SKH], or secure enclave or trusted execution environment (TEE) [ATZ]. Then an authorized configurer adding a new device can use TPM tools to secure the private signing key and install the rest of the bundle file in a known location before deploying the device in the network. Figure 9 shows the steps involved in configuring entities and the correspondence of the steps to the "building plans" model. The corresponding tools available in DCT are shown across the bottom and the relationship to the "building plans" model is shown across the top.

tools.config tools.config text binary make signed identity certs for each entity r epeat for all entities draw up plans validate plans authentic copies of plans schemaCompile make_bundle make_cert make_cert & schema_cert DCT tools - retrieve trust anchor - create trust schema cert signed by trust anchor create/adapt trust schema make identity bundle w/ trust anchor, schema cert & identity signing chain certs compile schema
Figure 9: Creating and configuring identity bundles

In the examples at [DCT], an identity bundle is given directly to an application directly via the command line, useful for development. For deployment, good key hygiene using best current practices must be followed e.g., [COMIS]. In deployment, a small application manager may be programmed for two specific purposes. First, it is registered with a supervisor [SPRV] (or similar process control) for its own (re)start to serve as a bootstrap for the application. Second, it has access to the TPM functions and the ability to create "short-lived" (~hours to several days) public/private key pair(s) that will be signed by the private key of the installed identity cert using the TPM, which will happen at (re)start and at the periodicity of the cert lifetime. Since the signing happens via requests to the TPM, the key cannot be exfiltrated. At (re)start, the signing cert is added to the stored bundle file (the entire chain should be rechecked for validity) and passed to the application entity as it is invoked. For periodic signing cert updates, only the new cert needs to be passed to the already running entity as the rest of the bundle does not change. Then DeftT uses its cert distributor to publish its new certs. Figure 10 outlines the procedures.

InstallIdbundle InstallIdbundle TPM bundle file supervisor process app cert distributor publishes entity's signing chain start(id bundle) or pass new signing key pair commissioning Device 1. make key pair 2. make app's signing cert & key (lifetime = 1 day) 3. request TPM sign cert with device key 4. add cert and key to app's bundle 5. start app with this bundle 6. before cert's expiry repeat 1-3 and pass cert to app
Figure 10: Representative commissioning and signing key maintenance

All DCT certs have a validity period. Certs that sign publications are typically generated locally for the application that's going to use them so can easily be refreshed as needed. Trust anchors, TSs, and the secured signing identity are higher value and often require generation under hermetic conditions by some central authority. Their lifetime should be application- and deployment-specific, but the higher difficulty of cert production and distribution often necessitates liftetimes of weeks to years. Updating trust schemas and other certificates over the deployed network (OTA) is application-domain specific and can either make use of domain best practices or develop custom DeftT-based distribution. Changing the trust anchor is considered a re-commissioning and not expected to be done over-the-air.

3. Use Cases

3.1. Secure Industrial IoT

IIoT sensors offer significant advantages in industrial process control including improved accuracy, process optimization, predictive maintenance and analysis, higher efficiency, low-cost remote accessibility and monitoring, reduced downtime, power savings, and reduced costs [IIOT]. The large physical scale of many industrial processes necessitates that expensive cabling costs be avoided through wireless transport and battery power. This is a particular issue in nuclear power plant applications where radioactive shielding walls are very thick concrete and security regulations make any plant modifications to add cabling subject to expensive and time-consuming reviews and permitting. Wireless sensor deployments in an industrial environment can suffer from signal outages due to shielding walls and interference caused by rotating machinery and electrical generators. Multiple gateway devices that can receive sensor information and transmit to monitor/controllers and servers can run DeftT Relay applications and be deployed in a robust wireless mesh that is resilient against transmission outages, facilitating reliability. DeftT forms meshes with no additional configuration as Publications are sent once and heard by all in-range members while Publications missing from one DeftT's set can be supplied by another within range. Several gateways may typically be within a single sensor's wireless range, reducing the number of lost sensor packets. Other meshed gateways can relay the sensor's Publications either wirelessly or via a wired ethernet backhaul.

IIoT sensors require tight security. Critical Digital Assets (CDA) are a class of industrial assets such as power plants or chemical factories which must be carefully controlled to avoid loss-of-life accidents. Even when IIoT sensors are not used for direct control of CDA, spoofed sensor readings can lead to destructive behavior. There are real-life examples (such as uranium centrifuges) of nation-state actors changing sensor readings through cyberattacks leading to equipment damage. These risks result in a requirement for stringent security reviews and regulation of CDA sensor networks. Despite the advantages of deploying CDA sensors, adequate security is prerequisite to deploying the CDA sensors. Information conveyed via DeftT has an ensured provenance and may be encrypted in an efficient implementation making it ideal for this use.

IIoT sensors may be mobile (including drone-based) and different gateways may receive the wireless broadcast of a particular sensor over time. A DeftT mesh captures Publications anywhere within its combined wireless network coverage area and ensures it efficiently reaches all other subscribing DeftTs as long as they are in range of at least one that has received the information. An out-of-service or out-of-range DeftT can receive all active subscribed publications once it is in range and/or able to communicate. This type of use of DeftT is illustrated in Figure 11 where gateway devices are deployed with DeftT Relay applications that have a Bluetooth (BT) interface and a WiFi interface. A number of BT devices are deployed as sensors, switches, cameras, lock openers, etc. The WiFi network includes tablet devices and a monitor/controller computer. Gateways are placed so that there is always at least one gateway in range of a BT device and at least one gateway (or the controller) in its WiFi range. WiFi tablets can move around within range of one or more gateways. If all the DeftTs have an identical trust schema, devices on the WiFi network have access to all of the BT devices though applications on any particular device may subscribe to any subset of the information available. The WiFi DeftTs can be given a trust schema that requires encrypting its cAdds so that longer-range data is kept private. These configuration choices are made by changes in the trust schemas alone, the application code is exactly the same. No configuration is needed to make devices recognize one another and the dynamics of syncps will keep communications efficient, ensuring that all DeftTs in the trust domain know what information is available. The Face implementation ensures that requested Publications are only sent once (within a particular range). These features mean that DeftT forms efficient broadcast meshes with no additional configuration beyond their identity bundles, an important advantage.

relaymesh relaymesh BT Dev BT Dev BT Dev BT Dev BT Dev BT Dev BT Dev BT Dev BT Dev BT Dev BT Dev WiFI WiFI WiFI cont r oller BT WiFi r elay GW0 BT WiFi r elay GW4 BT WiFi r elay GW3 BT WiFi r elay GW2 BT WiFi r elay GW1 Da t a s t o re BT WiFi r elay GW5 TCP
Figure 11: IIOT meshed gateways using DeftT Relay applications

In addition to specifying encryption and signing types, trust rules control which users can access specific sensors. For example, an outside predictive maintenance analysis vendor can be allowed access to the vibration sensor data from critical motors which is relayed through the internet, while only plant Security can see images from the site cameras due to privacy concerns.

3.2. Secure access to Distributed Energy Resources (DER)

The electrical power grid is evolving to encompass many smaller generators with complex interconnections. Renewable energy systems such as smaller-scale wind and solar generator sites must be economically accessed by multiple users such as building owners, renewable asset aggregators, utilities, and maintenance personnel with varying levels of access rights. North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) regulations specify requirements for communications security and reliability to guard against grid outages [DER]. Legacy NERC CIP compliant utility communications approaches, using dedicated physically secured links to a few large generators, are no longer practical. DeftT offers multiple advantages over bilateral TLS sessions for this use case:

  • Security. Encryption, authentication, and authorization of all information objects. Secure broker-less pub/sub avoids single-point broker vulnerabilities. Large generation assets of hundreds of megawatts to more than 1 gigawatt, particularly nuclear power plants must be controlled securely or risk large-scale loss of life accidents. Hence, they are attractive targets for sophisticated nation-state cyber attackers seeking damage with national security implications. Even small-scale DER generators are susceptible to a coordinated attack which could still bring down the electric grid.
  • Scalability. Provisioning, maintaining, and distributing multiple keys with descriptive, institutionalized, hierarchical names. DeftT allows keys to be published and securely updated on-line. Where historically a few hundred large-scale generators could supply all of the energy needs for a wide geographic area, now small-scale DER such as residential solar photovoltaic (PV) systems are located at hundreds of thousands of geographically dispersed sites. Many new systems are added daily and must be accommodated economically to spur wider adoption.
  • Resiliency. A mesh network of multiple client users, redundant servers, and end devices adds reliability without sacrificing security. Generation assets must be kept on-line continuously or failures risk causing a grid-wide blackout. Climate change is driving frequent natural disasters including wildfires, hurricanes, and temperature extremes which can impact the communications infrastructure. If the network is not resilient communications breakdowns can disable generators on the grid leading to blackouts.
  • Efficiency. Data can be published once from edge gateways over expensive cellular links and be accessed through servers by multiple authorized users, without sacrificing security. For small residential DER systems, economical but reliable connectivity is required to spur adoption of PV compared to purchasing from the grid. However, for analytics, maintenance and grid control purposes, regular updates from the site by multiple users are required. Pub/sub via DefT allows both goals to be met efficiently.
  • Flexible Trust rules: Varying levels of permissions are possible on a user-by-user and site-by-site basis to tightly control user security and privacy at the information object level. In an energy ecosystem with many DER, access requirements are quite complex. For example, a PV and battery storage system can be monitored on a regular basis by a homeowner. Separate equipment vendors for batteries and solar generation assets, including inverters, need to perform firmware updates or to monitor that the equipment is operating correctly for maintenance and warranty purposes. DER aggregators may contract with a utility to supply and control multiple DER systems, while the utility may want to access production data and perform some controls themselves such as during a fire event where the system must be shut down. Different permissions are required for each user. For example, hourly usage data which gives detailed insight into customer behaviors can be seen by the homeowner, but for privacy reasons might only be shared with the aggregator if permission is given. These roles and permissions can be expressed in the trust rules and then secured by DeftT's use of compiled trust schemas.

The specificity of the requirements of NERC CIP can be used to create trust schemas that contain site-specifics, allowing applications to be streamlined and generic for their functionality, rather than containing security and site-specifics.

3.3. Using Defined-trust Communications without DeftT

Parts of the DC framework could be used without the DeftT protocol. There are two main elements used in DeftT: the integrated trust management engine and the multi-party communications networking layer that makes use of the properties of a broadcast medium. It's possible to make use of either of these without DeftT. For example, a message broker could implement the trust management engine on messages as they arrive at the broker (e.g., via TLS) to ensure the sender has the proper identity to publish such a message. If a credential is required in order to subscribe to certain messages, that could also be checked. Set reconciliation could be used at the heart of a transport protocol without using defined-trust security, though signing, encryption, or integrity hashing could still be employed.

4. Terms and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

5. Security Considerations

This document covers a transport protocol that secures the information it conveys (COMSEC in the language of [RFC3552]). Security of data in the application space is out-of-scope for this document, but use of a trusted execution environment (TEE), e.g., ARM's TrustZone, is recommended where this is of concern.

Unauthorized changes to DeftT code could bypass validation of received PDUs or modify the content of outgoing PDUs prior to signing (but valid PDUs would still have to be sent or else they will be dropped by uncompromised entities). Although the security of DeftT's code is out-of-scope for this document, DeftT has been designed to be easily deployed with a TEE. Revisiting Figure 3, Figure 12 highlights how all of the DeftT code and data can be placed in the secure zone (long-dashed line), reachable only via callgates for the Publish and Subscribe API calls.

hwtrust hwtrust-rfc On-Device App Device Specific Code Certs, keys and Trust schema Shim Subscribe Publish call gates secured code and data in TrustZone Publication Validator Publication Builder Network
Figure 12: DeftT secured with a Trusted Execution Environment

Providing crypto functions is out-of-scope of this document. The example implementation uses libsodium, an open source library maintained by experts in the field [SOD]. Crypto functions used in any alternative implementation should be high quality.

Enrollment of devices is out of scope. A range of solutions are available and selection of one can be dependent on specifics of a deployment. Example approaches include the Open Connectivity Foundation (OCF) onboarding and BRSKI [RFC8995].

Protecting private signing keys is out-of-scope for this document. Good key hygiene should be practiced, securing private credentials using best practices for a particular application class, e.g. [COMIS][OWASP].

DeftT's unit of information transfer is a Publication. It is an atomic unit sized to fit in a lower layer transport PDU (if needed, fragmentation and reassembly are done in shim or application). All Publications MUST be signed and the signature MUST be validated. All Publications start with a 'name' (Appendix B.1). Publications are used both for ephemeral communication, like commands and status reports, and long-lived information like certs. The set reconciliation-based syncps protocol identifies Publications using a hash of the entire Publication, including its signature. A sync collection can contain at most one instance of any Publication so replays of Publications in the collection are discarded as duplicates on arrival. The current DeftT implementation requires weakly synchronized clocks with a known maximum skew. Ephemeral Publications have a lifetime enforced by their sync collection and their names include a timestamp used both to enforce that lifetime and prevent replay attacks by keeping a Publication in the local collection (but not advertising its existence) until its lifetime plus the skew has passed. (Lifetimes in current applications range from days or years for certs to milliseconds for status and command communications). Publications arriving a skew time before their timestamp or a skew time plus lifetime after their timestamp are discarded.

An attacker can modify, drop, spoof, or replay any DeftT PDU or Publication but DeftT is designed for this to have minimal effect.

  1. modification - all DeftT cAdd PDUs MUST be either signed or AEAD encrypted with a securely distributed nonce group key. This choice is specified in the trust schema and the per-app startup checks that one of these two properties holds for the trust schema and throws an error if not.

    • for signed PDUs each receiving DeftT MUST already have the complete, fully validated signing chain of the signer or the PDU is dropped. The signing cert MUST validate the PDUs signature or the PDU is dropped.

    • for encrypted PDUs the symmetric group key is automatically and securely distributed using signing identities. Each receiver uses its copy of the current symmetric key to validate the AEAD MAC and decrypt the PDU content. Invalid or malformed PDUs are dropped.

    cState modification to continually send an older, less complete state in order to generate the sending of cAdds could create a DoS attack but counter measures could be implemented using available DeftT information in order to isolate that entity or remove it from the trust domain.

  2. dropped PDUs - DeftT's sync protocol periodically republishes cState messages which results in (re)sending cAdds. Unlike unicast transports, DeftT can and will obtain any Publications missing from its collection from any peer that has a valid copy.

  3. spoofing - DeftT uses a trust management engine that validates the signing. Malformed Publications and PDUs are dropped as early as possible.

  4. replay - A cAdd is sent in response to a specific cState, so a replayed cAdd that matches a current cState simply serves a retransmit of the cAdd's Publication which will be filtered for duplicates and obsolescence as described above. A cAdd that doesn't match a current cState will be dropped on arrival.

Peer entity authentication in DeftT comes through the integrated trust management engine. Every DeftT instance is started with an identity bundle that includes the domain trust anchor, the trust schema in certificate format signed by this trust anchor, and its own member identity chain with a private signing key and the chain signed at the root by trust anchor. Members publish their identity chains before any Publications are sent. The trust management engine unconditionally drops any Publication or PDU that does not have a valid signer or whose signer lacks the role or capabilities required for that particular Publication or PDU.

DeftT takes a modular approach to signing/validation of its PDUs and Publications, so a number of approaches to integrity, authenticity, and confidentiality are possible (and several are available at [DCT]). Security features that are found to have vulnerabilities will be removed or updated and new features are easily added.

A compromised member of a trust domain can only build messages that match the role and capabilities in its signing chain. Thus, a compromised lightbulb can lie about its state or refuse to turn on, but it can't tell the front door to unlock or send camera footage to a remote location. Multiple PDUs could be generated, resulting in flooding the subnet. There are possible counter-measures that could be taken if some detection code is added to the current DeftT, but this is deferred for specific applications with specific types of threats and desired responses.

The example encryption modules currently use encryption only on cAdd PDUs (so the specific entity that sent the cAdd cannot be determined) but the Publications it carries MUST be signed and will be validated. In DeftT, any member can resend a Publication from any other member (without modification) so group encryption (in effect, group signing) is no different. Some other encryption approaches are provided whose potential vulnerabilities are described with their implementations and a signed, encrypted approach is also available [DCT].

6. IANA Considerations

This document has no IANA actions.

7. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, , <>.

8. Informative References

Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and S. Martin, "TrustZone Explained: Architectural Features and Use Cases", , <>.
Marlinspike, M., "More Tricks for Defeating SSL in Practice", , <>.
CheckPoint, "The Dark Side of Smart Lighting: Check Point Research Shows How Business and Home Networks Can Be Hacked from a Lightbulb", , <>.
OperantNetworks, "Cybersecurity Intrusion Detection System for Large-Scale Solar Field Networks", , <>.
Lydersen, L., "Commissioning Methods for IoT", , <>.
Guy, W., "Wireless Industrial Networking Alliance, Wired vs. Wireless: Cost and Reliability", , <>.
Support, G. C., "Additional authenticated data guide", , <>.
Pollere, "Defined-trust Communications Toolkit", , <>.
NERC, "North American Electric Reliability Corporation: Distributed Energy Resources: Connection, Modeling, and Reliability Considerations", , <>.
Eppstein, D., Goodrich, M. T., Uyeda, F., and G. Varghese, "What's the difference?: efficient set reconciliation without prior context", .
Bandyk, M., "As Dominion, others target 80-year nuclear plants, cybersecurity concerns complicate digital upgrades", , <>.
Li, N., Grosof, B., and J. Feigenbaum, "Delegation logic", , <>.
al., M. C. E., "Device Management Requirements to Secure Enterprise IoT Edge Infrastructure", , <>.
Nichols, K., "Lessons Learned Building a Secure Network Measurement Framework Using Basic NDN", .
Blaze, M., Feigenbaum, J., and J. Lacy, "Decentralized Trust Management", , <>.
Demers, A. J., Greene, D. H., Hauser, C., Irish, W., Larson, J., Shenker, S., Sturgis, H. E., Swinehart, D. C., and D. B. Terry, "Epidemic Algorithms for Replicated Database Maintenance", , <>.
Ozisik, A. P., Andresen, G., Bissias, G., Houmansadr, A., and B. N. Levine, "Graphene: A New Protocol for Block Propagation Using Set Reconciliation", , <\_24>.
Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D., Bissias, G., and S. Katkuri, "Graphene: efficient interactive set reconciliation applied to blockchain propagation", , <>.
Kapersky, "Secure Element", , <>.
Ganapathy, K., "Using a Trusted Platform Module for endpoint device security in AWS IoT Greengrass", , <Using a Trusted Platform Module for endpoint device security in AWS IoT Greengrass>.
Goodrich, M. T. and M. Mitzenmacher, "Invertible bloom lookup tables", , <>.
IEC, "Power systems management and associated information exchange - Data and communications security - Part 8: Role-based access control for power system management", , <>.
Wikipedia, "IEC 61850", , <>.
Rajiv, "Applications of Industrial Internet of Things (IIoT)", , <>.
Nichols, K., "Trust schemas and {ICN:} key to secure home IoT", , <>.
ISO, "Industrial automation systems --- Manufacturing Message Specification --- Part 1: Service definition", , <>.
LANGSEC, "LANGSEC: Language-theoretic Security "The View from the Tower of Babel"", , <>.
Alliance, C. S., "Matter is the foundation for connected things", , <>.
Wikipedia, "MQTT", , <>.
Minsky, Y., Trachtenberg, A., and R. Zippel, "Set reconciliation with nearly optimal communication complexity", , <>.
Saleem, D., Granda, S., Touhiduzzaman, M., Hasandka, A., Hupp, W., Martin, M., Hossain-McKenzie, S., Cordeiro, P., Onunkwo, I., and D. Jose, "Modular Security Apparatus for Managing Distributed Cryptography for Command and Control Messages on Operational Technology Networks (Module-OT)", , <>.
Mitzenmacher, M. and R. Pagh, "Simple multi-party set reconciliation", .
OASIS, "MQTT: The Standard for IoT Messaging", , <>.
NDN, "Named Data Networking Packet Format Specification 0.3", , <>.
Jacobson, V., "Watching NDN's Waist: How Simplicity Creates Innovation and Opportunity", , <>.
NERC, "Emerging Technology Roundtable - Substation Automation/IEC 61850", , <>.
al, D. D. E., "Securing Small-Business and Home Internet of Things (IoT) Devices: Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD)", , <>.
Hashemian, H. M., "Nuclear Power Plant Instrumentation and Control", , <>.
Gutmann, P., "Everything you Never Wanted to Know about PKI but were Forced to Find Out", , <>.
OneDM, "One Data Model", , <>.
King, R., "Commercialization of NDN in Cybersecure Energy System Communications video", , <>.
NIST, "OSCAL: the Open Security Controls Assessment Language", , <>.
Hinds, L., "Keylime - An Open Source TPM Project for Remote Trust", , <>.
[OWASP], "SideKEK README", , <>.
e}bowicz, J. W., Cabaj, K., and J. Krawiec, "Messaging Protocols for IoT Systems---A Pragmatic Comparison", , <>.
Arthur, D. C. W., "Quick Tutorial on TPM 2.0", , <>.
Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, DOI 10.17487/RFC2693, , <>.
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, , <>.
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <>.
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, , <>.
Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, , <>.
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, , <>.
Ellison, C. and B. Schneier, "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure", .
Rivest, R. L. and B. W. Lampson, "SDSI - A Simple Distributed Security Infrastructure", .
Truong, T., "How to Use the TPM to Secure Your IoT/Device Data", , <>.
Yates, T., "Secure key handling using the TPM", , <>.
Smetters, D. K. and V. Jacobson, "Securing Network Content", , <>.
Bernstein, D., Lange, T., and P. Schwabe, "libsodium", , <>.
AgendalessConsulting, "Supervisor: A Process Control System", , <>.
Samsung, "SmartThings API (v1.0-PREVIEW)", , <>.
Yu, Y., Afanasyev, A., Clark, D. D., claffy, K., Jacobson, V., and L. Zhang, "Schematizing Trust in Named Data Networking", .
Microsoft, "TPM attestation", , <>.
al., C. B. E., "Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations", , <>.
Griffiths, P., "TPM 2.0 and Certificate-Based IoT Device Authentication", , <>.
Wikipedia, "X.509: Security", , <>.
Kintner-Meyer, M., Brambley, M., Carlon, T., and N. Bauman, "Wireless Sensors: Technology and Cost-Savings for Commercial Buildings", , <>.
Wegman, M. N. and L. Carter, "New Hash Functions and Their Use in Authentication and Set Equality", , <>.
zigbeealliance, "Zigbee Cluster Library Specification Revision 6", , <>.

Appendix A. DeftT run-time modules

DeftT's required functionality has been implemented in libraries in the example implementation [DCT]. DeftT is organized in functional modules that may provide services to other modules in the course of preparing application-level information for transport and for extracting application-level information from packets. Extensions and alternate module implementations are possible but the functionality and interfaces must be preserved. Following good security practice, DeftT's Publications are constructed and signed early in their creation, then are validated (or discarded) early in the reception process. The signing and validation modules (signature managers) are used for both Publications and cAdds.The schemaLib module provides certificate store access throughout DeftT along with access to distributors of group keys, Publication building and structural validation, and other functions of the trust management engine. This organization would not be possible in a strictly layered implementation.

Figure 13 shows the DC module libraries of DCT. The component descriptions and interactions can appear complex but the internals of DeftT are completely transparent to an application and the reference implementation is efficient in both lines of code and performance.The trust schema completely determines which modules are used. A DeftT participates in two required collections and MAY participate in others if required by the schema-designated signature managers. One of the required collections handles the Publications that carry out application communications and uses "pubs" for the descriptive collection name component (see Table 2). The other required collection manages the certificates of the trust domain and uses "cert" for the descriptive collection name component. Specific signature managers MAY require group key distribution in descriptive-named Collection "keys."

DeftTmodules DeftTmodules syncps : set reconciliation pub/sub protocol schemaLib : run-time use of trust schema and cert store shim : application- specifics: up calls, timing, lifetimes, API, QoS, seg/reas DeftT face : manage PDU transport via multicast UDP, unicast UDP or TCP distributors : handle all aspects of distributing certs or group keys sigmgrs : sign or validate publication or PDU cState & cAdd packets cState & cAdd PDUs publications application calls
Figure 13: Run-time library modules

A shim serves as the translator between application semantics and the named information objects (Publications) whose format is defined by the trust schema. Besides the shim, DeftT components are not application-specific. New signature managers, distributors, and Face modules may be added to the library to extend features. More detail on each module can be found at [DCT] in both code files and documents.

Appendix B. Formats

Application information is packaged in Publications which are carried in cAdds that are used along with cState PDUs to communicate about and synchronize Collections. This section documents the format of Publications, cStates, and cAdds along with certificates, which are a special case of Publication (where keys are the information carried). Publications and cAdds use a compatible format which allows them to use the same library signing/validation modules (sigmgrs) and the same parser. The cState/cAdd formats and dynamics were originally prototyped using Named Data Networking and a restricted version of the NDNv3 TLV encoding is still used, with TLV types from NDN's TLV Type Registry [NDNS], as is its IANA assigned port number [RFC6335].

In Tables 1-3, the Type in level i is contained within the TLV of the previous level i-1 TLV.

B.1. Publications

Publications are used throughout DeftT's modules. A Name TLV is used to encode the name defined in the trust schema. A Publication is valid if it starts with the correct TLV, its Name validates against the trust schema and it contains the five required Level 1 TLVs in the right order (top-down in Table 1) and nothing else. MetaInfo contains the ContentType (in DeftT either type Key or Blob). The Content carries the named information and MAY be empty. SignatureInfo indicates the SignatureType used to select the appropriate signature manager (Figure 13). The SignatureType for a collection's Publications is specified in the trust schema and each Publication MUST match it. (A list of current types can be found in [DCT] file include/dct/sigmgrs/sigmgr.hpp.) The KeyLocator associated with the SignatureType follows then the ValidityPeriod (if the Publication is a Certificate). Finally, SignatureValue is determined by the SignatureType and its format is verified by the signature manager.

Table 1: Publication Format
Level 0 Level 1 Level 2 Comments
Type MUST be 6
Name format specified by trust schema
ContentType MUST be type Key or Blob
Content arbitrary byte sequence; MAY have length 0
SignatureType Value specified by trust schema
KeyLocator MUST be a ThumbPrint
ValidityPeriod Only for Certificates
SignatureValue format determined by SignatureType

B.2. Certificates

Certificates (certs) are Publications with the ContentType set to Key and both a KeyLocator and a ValidityPeriod. DCT certs are compatible with the NDN Certificate standard V2 but adhere to a stricter set of conventions to make them resistant to substitution, work factor and DoS attacks. The only KeyLocator type allowed in a DCT cert is a KeyDigest type that MUST contain the 32 byte SHA256 digest of the entire signing cert (including SignatureValue). A self-signed cert (such as a trust anchor) MUST set this digest to all zero. This digest, a cert thumbprint [IOTK], is the only locator allowed in any signed DC object (e.g., Publications, cAdd, schemas, certs) and MUST be present in every signed object. A signed object using any other type of locator will be considered unverifiable and silently ignored. Certificate Names use a suffix:


where the cert's thumbprint is the keyID and its creation time is the version.

The original publisher of any signed object MUST ensure that that all certs, schemas, etc., needed to validate the object have been published before the object is published. If a member receives a signed object but is missing any of its signing dependencies, the object should be considered unverifiable and silently ignored. Such objects MUST NOT be propagated.

B.3. cState

cState and cAdds are are the PDUs exchanged with the system-level transport in use (e.g., UDP) but are only used by syncps and Face modules Figure 13. Syncps creates cState and cAdd PDUs while the Face manages the protocol interaction within the trust domain. A cState PDU (see Table 2) is used to report the state of a Collection at its originator. A cState serves to inform all subscribing entities of a trust domain about Publications currently in the Collection, both so an entity can obtain Publications it is missing and so an entity can add Publications it has that are not reflected in the received cState.

Table 2: cState format
Level 0 Level 1 Level 2 Comments
Type MUST be 5
Generic trust domain id
Generic descriptive collection name
Generic collection state (sender's view)
Nonce uniquely distinguishes this cState
Lifetime expiry time (ms after arrival)

A cState is valid if it starts with the correct TLV and it contains the three required Level 1 TLVs in the right order (top-down in Table 2) and nothing else. Its Name MUST start with the trust domain id of the DeftT, then a descriptive Collection name (of at least one component) and finally a representation of the the state of the Collection at the originator. There is no signature for a cState PDU. (The cState format is a restricted subset of an NDNv3 Interest.)

B.4. cAdd

A cAdd PDU is used to add Publications to a collection and carries Publications as Content. A cAdd PDU is created after a cState is received and only if the recipient has Publications that are not reflected in the recipient's local state. A cAdd is valid if it starts with the correct TLV, contains the five required Level 1 TLVs in the right order (top-down in Table 3) and nothing else. A cAdd name is identical to the cState to which it responds.

Table 3: cAdd format
Level 0 Level 1 Level 2 Comments
Type MUST be 6
Name MUST match Name of cState it's adding to
ContentType MUST be type cAdd
Publication(s) one or more Publications to add to the Collection
SignatureType Value indicates which signature manager
KeyLocator Presence depends on SignatureType
SignatureValue Value holds the signature for this PDU


Lixia Zhang
Roger Jungerman
Operant Networks Inc.

Roger contributed much to Section 3.

Authors' Addresses

Kathleen Nichols
Pollere LLC
Van Jacobson
Randy King
Operant Networks Inc.