Skip to main content

Defined-Trust Transport (DeftT) Protocol for Limited Domains

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Kathleen Nichols , Van Jacobson , Randy King
Last updated 2023-07-20 (Latest revision 2023-04-02)
Replaces draft-nichols-tsv-defined-trust-transport
RFC stream Independent Submission
Stream ISE state Response to Review Needed
Revised I-D Needed
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state I-D Exists::Revised I-D Needed
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                         K. Nichols
Internet-Draft                                               Pollere LLC
Intended status: Informational                               V. Jacobson
Expires: 4 October 2023                                             UCLA
                                                                 R. King
                                                   Operant Networks Inc.
                                                            2 April 2023

      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 is part of a Defined-trust Communications framework with an
   example codebase, not a protocol specification.  Combined with IPv6
   multicast and modern hardware-based methods for securing keys and
   code, it 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 4 October 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Nichols, et al.          Expires 4 October 2023                 [Page 1]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Environment and use . . . . . . . . . . . . . . . . . . .   4
     1.2.  Transporting information  . . . . . . . . . . . . . . . .   5
     1.3.  Securing information  . . . . . . . . . . . . . . . . . .   7
     1.4.  Defined-trust Communications Domains  . . . . . . . . . .   8
     1.5.  Current status  . . . . . . . . . . . . . . . . . . . . .   9
   2.  DeftT and Defined-trust Communications  . . . . . . . . . . .  10
     2.1.  Inside DeftT  . . . . . . . . . . . . . . . . . . . . . .  11
     2.2.  syncps: a set reconciliation protocol . . . . . . . . . .  12
     2.3.  Formats of DeftT Communications . . . . . . . . . . . . .  13
       2.3.1.  Publications  . . . . . . . . . . . . . . . . . . . .  13
       2.3.2.  Certificates  . . . . . . . . . . . . . . . . . . . .  15
       2.3.3.  cState  . . . . . . . . . . . . . . . . . . . . . . .  15
       2.3.4.  cAdd  . . . . . . . . . . . . . . . . . . . . . . . .  16
     2.4.  Interface between application and network interface . . .  17
     2.5.  Schema-based information movement . . . . . . . . . . . .  19
     2.6.  Congestion control  . . . . . . . . . . . . . . . . . . .  21
   3.  Defined-trust management engine . . . . . . . . . . . . . . .  22
     3.1.  Communications schemas  . . . . . . . . . . . . . . . . .  22
     3.2.  A schema language . . . . . . . . . . . . . . . . . . . .  23
   4.  Certificates and identity bundles . . . . . . . . . . . . . .  26
     4.1.  Obviate CA usage  . . . . . . . . . . . . . . . . . . . .  27
     4.2.  Identity bundles  . . . . . . . . . . . . . . . . . . . .  28
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  30
     5.1.  Secure Industrial IoT . . . . . . . . . . . . . . . . . .  30
     5.2.  Secure access to Distributed Energy Resources (DER) . . .  31
   6.  Using Defined-trust Communications without DeftT  . . . . . .  33
   7.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  38
   11. Informative References  . . . . . . . . . . . . . . . . . . .  38
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  45
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45

Nichols, et al.          Expires 4 October 2023                 [Page 2]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

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(_n_^2) (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]), a
   distributed set reconciliation PDU transport, a flexible pub/sub API,
   chain-of-trust membership identities, and secured rules that define
   the local context and communication constraints of a deployment in a
   declarative language.  These 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,

Nichols, et al.          Expires 4 October 2023                 [Page 3]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   independent of the richness and complexity of the deployment's
   constraints or the number of entites deployed.  Like QUIC, DeftT is a
   user-space transport protocol that sits between an application and a
   system-provided transport like UDP or UDP multicast (see Figure 1).

   (Artwork only available as svg: figs/defttlayer-rfc.svg)

                   Figure 1: DeftT's place in an IP stack

   Device enrollment consists of configuring a device with _identity
   bundles_ that contains the trust anchor certificate, a compact and
   secured copy of the communication rules, and a membership identity
   (for domain communications) which comprises all the certs in its
   signing chain (which can be used to confer attributes) terminated at
   the trust anchor.  The secret key corresponding to the leaf
   certificate of the identity should be securely configured while the
   security of the identity bundle can be deployment-specific.  The
   identity chains of all communicating members share a common trust
   anchor and the rules that 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

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 ( (

Nichols, et al.          Expires 4 October 2023                 [Page 4]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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 transports 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 2 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(_n^2_).  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.

   (Artwork only available as svg: figs/iotDeftt-rfc.svg)

                  Figure 2: 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 3).  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(_n_^2) to O(_n_): 18 transport sessions to 11 for this

Nichols, et al.          Expires 4 October 2023                 [Page 5]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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(_n^2_), 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.

   (Artwork only available as svg: figs/iotMQTT-rfc.svg)

     Figure 3: 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 a 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 optimal in
   both 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 2 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.

Nichols, et al.          Expires 4 October 2023                 [Page 6]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

1.3.  Securing information

   Conventional session-based transports combine multiple 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 3 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 using trust management that operates
   per-publication, using 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.  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 communication rules.  These rules
   can be employed to secure publications in 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.

   Instead of vulnerable third-party CAs [W509], sites employ a local
   root of trust and locally created certificates.  When the
   communication rules are expressed in a _declarative_ language [DLOG],
   they can be validated for consistency and completeness then converted
   to a compact runtime form which can be authorized and secured via
   signing with the system trust anchor.  This _communication schema_

Nichols, et al.          Expires 4 October 2023                 [Page 7]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   can be distributed as a certificate, then validated using on-device
   trusted enclaves [TPM][HSE][ATZ] as part of the device enrollment
   process.  In DeftT's publication-based transport, the schema is 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 3.1).
   DeftT embeds the trust management mechanism described above directly
   in the publish and subscribe data paths as shown below:

   (Artwork only available as svg: figs/trustElements-rfc.svg)

               Figure 4: 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 and the schema 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 schema shows its signing chain isn't appropriate for this
   *  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 schemas to
   reduce attack surface results in devices doing _less_ work.

1.4.  Defined-trust Communications Domains

   A Defined-trust Communications Limited Domain (or simply, _trust
   domain_) is a Limited Domain where all the members communicate via a
   DeftT Figure 5 and are configured with the same trust anchor, schema,
   a schema-conformant DeftT identity cert chain that terminates at the
   trust anchor and the secret key corresponding to the identity chain's
   leaf cert.  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)

Nichols, et al.          Expires 4 October 2023                 [Page 8]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   which DeftT accommodates by being invoked with a ruleset (schema)
   particular to a deployment.  We anticipate that the efforts to create
   common data models (e.g., [ONE]) for specific sectors will lead to
   easier and more forms-based configuration of DeftT deployments.

   A trust domain is perimeterless and may operate over one or more
   subnets, sharing physical media with non-member entities.  Member
   entities throughout the domain publish and subscribe to its topics
   using Publication Builders and Validators as shown in Figure 4.
   These Publications become the elements of a set, or named collection,
   that is confined to each subnet.  DeftT uses a distributed set
   reconciliation protocol on _each_ collection and _each_ subnet
   independently.  Every DeftT maintains at least two collections:
   *pubs* for application Publications and *cert* where identity bundle
   certs are published.  Figure 5

   (Artwork only available as svg: figs/trustdomain-rfc.svg)

                           Figure 5: Trust domain

   Trust domains are extended across physically separated subnets,
   subnets using different media and/or subdomains on the same subnet
   (see Section 2.5) by using *Relays* that have a DeftT in each subnet
   and pass Publications between subnets as long as they are valid at
   the receiving DeftT Figure 6.  Since set reconciliation does not
   accept duplicates, Relays are powerful elements in creating efficient
   configuration-free meshes.  The subnets of the figure could be
   different colocated media (e.g. bluetooth, wifi, ethernet) or may be
   physically distant.  The triangle Relay-only subnet can be carried
   over a unicast link.  The set reconciliation protocol ensures that
   items only transit a subnet once: an item must be specifically
   requested in order to be transmitted.  More Relay discussion is in
   Section 2.5 and Section 5.

   (Artwork only available as svg: figs/relayedtrustdomain-rfc.svg)

                       Figure 6: Relayed trust domain

1.5.  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.

Nichols, et al.          Expires 4 October 2023                 [Page 9]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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.  Our development
   philosophy is to start from solving useful problems with a well-
   defined scope and extend from there.  As the needs of our use cases
   expand, the Defined-trust communications framework will evolve with
   increased efficiencies.  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.

   The well-known issues with 802.11 multicast [RFC9119] can make DeftT
   less efficient than it should be.  Target OT deployments primarily
   use smaller packet sizes and DeftT's set reconciliation provides
   robust delivery that currently mitigates these concerns.  DeftT use
   may become another force for improved multicast on 802.11, joining
   the critical network infrastructure applications of neighbor
   discovery, address resolution, DHCP, etc.

   Cryptographic signing takes most of the application-to-network time
   in DeftT.  Though not prohibitively costly, increased use of signing
   in transports may incentivize creation of more efficient signing

2.  DeftT and Defined-trust Communications

   DeftT synchronizes and secures communications between enrolled
   members of a Limited Domain [RFC8799].  DeftT's multi-party
   synchronized collections of named, schema-conformant Publications
   contrast with the bilateral session of TCP or QUIC where a source and
   a destination coordinate with one another to transport
   undifferentiated streams of information.  DeftTs in a trust domain
   may hold different subsets of the collection at any time (e.g.,
   immediately after entities add elements to the collection) but the
   synchronization protocol ensures all converge to holding the complete
   set of elements within a few round-trip-times following the changes.

   Applications use DeftT to add to and access from a collection of
   Publications.  DeftT enforces "who can say what to which" as well as
   providing required integrity, authenticity and confidentiality.
   Transparently to applications, a DeftT both constructs and validates
   all Publications against its schema's formal, validated rules.  The

Nichols, et al.          Expires 4 October 2023                [Page 10]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   compiled binary communications schema is distributed as a trust-root-
   signed certificate and that certificate's thumbprint (see
   Section 2.3.2 and Section 7) _uniquely_ identifies each trust domain.
   Each DeftT is configured with the trust anchor used in the domain,
   the schema cert, and its own credentials for membership in the
   domain.  To communicate, DeftTs must be in the same domain.  Identity
   credentials comprise a unique private identity key along with a
   public certificate chain rooted at the domain's trust anchor.
   Certificates in identity chains are specified in the schema and
   contain the attributes granted to the identity.  Thus, attributes are
   stored in the identity *not* on an external server.

   Each member publishes its credentials to the certificate collection
   in order to join the domain.  DeftT validates credentials as a
   certificate chain against the schema and does not accept Publications
   without a fully validated signer.  This unique approach enables fully
   distributed policy enforcement without 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 omain.  Privacy via AEAD encryption is automatically
   handled within DeftT if selected in the schema.

   (Artwork only available as svg: figs/transportBD0v2-rfc.svg)

              Figure 7: DeftT's interaction in a network stack

   Figure 7 shows the data flow in and out of a DeftT.  DeftT uses its
   schema to package application information into Publications that are
   added to its local view of the collection.  Application information
   is packaged in Publications which are carried in cAdd PDUs that are
   used along with cState PDUs to communicate about and synchronize
   Collections. cStates are used to report the state of the local
   collection; cAdds carry Publications to other members that need them.
   These PDUs are broadcast on their subnet (e.g., UDP multicast).

2.1.  Inside DeftT

   DeftT's reference implementation [DCT] is organized in functional
   library modules that interact to prepare application-level
   information for transport and to extract application-level
   information from packets, see Figure 8.  Extensions and alternate
   module implementations are possible but the functionality and
   interfaces must be preserved.  Internals of DeftT are completely
   transparent to an application and the reference implementation is
   efficient in both lines of code and performance.  The schema
   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

Nichols, et al.          Expires 4 October 2023                [Page 11]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   collections, descriptive collection name component *pubs*, contains
   application Publications (see Table 2).  The other required
   collection, *cert*, manages the certificates of the trust domain.
   Specific signature managers _may_ require group key distribution in
   descriptively named collection *keys*.

   (Artwork only available as svg: figs/DeftTmodules-rfc.svg)

                     Figure 8: 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 schema.  The *syncps* module is the set reconciliation
   protocol used by DeftT (see Section 2.2).  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.

   The signing and validation modules (_signature managers_) are used
   for both Publications and cAdds.  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 _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 of interacting
   modules is not possible in a strictly layered implementation.

2.2.  syncps: a set reconciliation protocol

   DeftT requires a method or protocol that keeps collections
   synchronized, where the collection a set and the Publications are the
   elements of the set.  The *syncps* protocol uses IBLTs
   [DIFF][IBLT][MPSR] to 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.  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 member(s) are missing and (3) acknowledges
   Publication receipt.  The first may prompt the recipient to share its
   cState to get the new Publication(s).  The second results in sending
   a cAdd PDU containing all the missing and locally available
   Publications that fit.  The third may result in a progress
   notification sent to other local modules so anything waiting for
   delivery confirmation can proceed.

Nichols, et al.          Expires 4 October 2023                [Page 12]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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, independently 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 are
   missing any of its active 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.  Formats of DeftT Communications

   In DeftT, information containers (i.e., Publications, cAdds, Cstate)
   hold names, content and signatures in TLVs.  Tables 1-3 layout the
   formats of Publications, cStates, cAdds and certificates, which are a
   special type 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.
   Although the NDN code and architecture are not used in DeftT or DCT,
   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.

2.3.1.  Publications

   Publications use a Name TLV to encode the name defined in the schema.
   A Publication is _valid_ if it starts with the correct TLV, its Name
   validates against the 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

Nichols, et al.          Expires 4 October 2023                [Page 13]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   appropriate signature manager (Figure 8).  The SignatureType for a
   collection's Publications is specified in the 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 holds the
   thumbprint (see Section 2.3.2) of the certificate that signed this
   Publication.  If the Publication is a certificate, KeyLocator will be
   followed by the ValidityPeriod.  Finally, SignatureValue is
   determined by the SignatureType and its format is verified by the
   signature manager.

      | Level | Level 1        | Level 2        | Comments         |
      | 0     |                |                |                  |
      | Type  |                |                | the value 6      |
      |       | Name           |                | format specified |
      |       |                |                | by schema        |
      |       | MetaInfo       |                |                  |
      |       |                | ContentType    | either type Key  |
      |       |                |                | or Blob          |
      |       | Content        |                | arbitrary byte   |
      |       |                |                | sequence; may    |
      |       |                |                | have length 0    |
      |       | SignatureInfo  |                |                  |
      |       |                | SignatureType  | Value specified  |
      |       |                |                | by schema        |
      |       |                | KeyLocator     | must be a        |
      |       |                |                | thumbprint       |
      |       |                | ValidityPeriod | Only for         |
      |       |                |                | Certificates     |
      |       | SignatureValue |                | format           |
      |       |                |                | determined by    |
      |       |                |                | SignatureType    |

                       Table 1: Publication format

Nichols, et al.          Expires 4 October 2023                [Page 14]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

2.3.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 Defined-trust 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

   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 that is missing any of its signing dependencies, the
   object should be considered unverifiable and silently ignored.  Such
   objects must not be propagated.

2.3.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 the syncps and face
   modules Figure 8: 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.  Collections are denoted by structured names which
   include the identifier of a particular trust domain (thumbprint of
   its schema cert). in DeftT PDU headers.  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.

Nichols, et al.          Expires 4 October 2023                [Page 15]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   | Level 0 | Level 1  | Level 2 | Comments                           |
   | Type    |          |         | the value 5                        |
   |         | Name     |         |                                    |
   |         |          | 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)     |

                           Table 2: cState format

   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

2.3.4.  cAdd

   A cAdd PDU is used by _syncps_ to add Publications to a collection
   and carries Publications as Content. _syncps_ creates a cAdd PDU
   after receiving a cState and only if the recipient has Publications
   that are not reflected in the received 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.

Nichols, et al.          Expires 4 October 2023                [Page 16]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

    | Level | Level 1        | Level 2        | Comments              |
    | 0     |                |                |                       |
    | Type  |                |                | the value 6           |
    |       | Name           |                | must match Name of    |
    |       |                |                | cState it's adding to |
    |       | MetaInfo       |                |                       |
    |       |                | ContentType    | type cAdd             |
    |       | Content        |                |                       |
    |       |                | Publication(s) | one or more           |
    |       |                |                | Publications to add   |
    |       |                |                | to the Collection     |
    |       | SignatureInfo  |                |                       |
    |       |                | SignatureType  | Value indicates which |
    |       |                |                | signature manager     |
    |       |                | KeyLocator     | Presence depends on   |
    |       |                |                | SignatureType         |
    |       | SignatureValue |                | Value holds the       |
    |       |                |                | signature for this    |
    |       |                |                | PDU                   |

                            Table 3: cAdd format

   The structure of the cState and cAdd Names means that nothing about
   Publication Names (which are application-oriented) are exposed if
   encrypted cAdds are specified in a schema.  (The schema itself may be
   distributed in an encrypted cAdd if desired).

2.4.  Interface between application and network interface

   Figure 7 and Figure 8 show the blocks and modules application
   information passes through in DeftT.  Its handling of application
   information can be illustrated using an example of a new Publication
   at a trust domain member and following its progress into a collection
   and its reception by other members.  For more detail, see the library
   at [DCT].  DeftT uses [DCT]'s message-based pub/sub (_mbps_) *shim*
   which kicks off all the necessary DeftT startup when an mbps object

Nichols, et al.          Expires 4 October 2023                [Page 17]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   is instantiated by the application.  After startup, the *pub* syncps
   of each member will maintain a cState containing the IBLT of its view
   of the collection.  (In the stable, synchronized state, all IBLTs are
   the same.)

   Applications use an mbps _subscribe_ method to either subscribe to
   all messages or to a subset by topic, passing a callback function to
   handle matching items.  These application-level subscriptions are
   turned into syncps subscriptions via mbps.  When the application has
   new information to communicate, topic items (as parameters) and
   message are passed to mbps with a _publish_ call.  Only these topic
   components and the message, if any, are passed between the
   application and mbps.  The message may be segmented into multiple
   Publications by mbps, if the message size exceeds Publication
   content.  For each Publication, mbps-specific components are added to
   the parameter list and the services of *schemaLib* are invoked in
   order to build and publish a valid Publication according to the
   schema (no Publication will be built if the correct attributes are
   not contained in the member's identity chain).  The Publication is
   signed using the _sign_ method of the appropriate *sigmgr* and passed
   to *syncps*.

   syncps adds this Publication to its collection and updates its IBLT
   to contain the new Publication.  Since its application just created
   it, syncps knows this is a new addition to the collection and it is a
   response to the current cState.  Thus the Publication is packaged
   into a cAdd and signed using the _sign_ method of the designated
   *sigmgr* and passed to the face.  The updated IBLT is packaged into a
   new cState that is handed to the face.

   Members of the trust domain specifically respond only to IPv6 cAdds
   that share their trust domain identifier (Section 2.3.3 and
   Section 2.3.4).  When a new cAdd is received at a member, the face
   ensures it matches an outstanding cState and, if so, passes it on to
   matching syncps(es).  Syncps validates (both structurally and
   cryptographically) the cAdd using the appropriate sigmgr's _validate_
   and continues, removing Publications, if valid.  Each Publication is
   structurally validated via a sigmgr and valid Publications are added
   to the local collection and IBLT. syncps passes this updated cState
   to the local face.  If this Publication matches a subscription it is
   passed to mbps, invoking the sigmgr's decrypt if the Publication is
   encrypted (Publication decryption is _not_ available at Relays.) mbps
   receives the Publication and passes any topic components of interest
   to the application along with the content (if any) to the application
   via the callback registered when it subscribed.  (If the original
   content was spread across Publications, mbps will wait until all of
   the content is received.  The _sCnt_ component of a mbps Publication
   Name is used for this.)

Nichols, et al.          Expires 4 October 2023                [Page 18]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

2.5.  Schema-based information movement

   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, 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
   communication 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 be in different trust domains and
   DeftTs in the same trust domain may not be on the same subnet.  In
   some cases, it is useful to define sub-domains whose DeftTs have a
   compatible, but more limited, version of the trust domain's
   communications schema.  Compatible means there is at least one
   publication type and associated signer specification in common or one
   schema may be a subset of the other.  In the case of sub-domains,
   they be deployed on the same subnet or on different subnets.  The
   rules of a sub-domain compiled to a binary schema distributed as a
   schema cert will have a different thumbprint from that of the full
   trust domain.

   In the case of DeftTs on the same subnet but in different trust
   domains or different sub-domains, the cState and cAdd PDUs of
   different domains are differentiated by the _domain id_ (thumbprint
   of the domain's schema certificate as in Table 2) which can be used
   at the face module to determine whether or not to process a PDU.  A
   particular sync collection is managed on a single subnet: cState and
   cAdds are not forwarded off that subnet nor between DeftTs with
   different domain ids on the same subnet.  Instead, schema-compliant
   Relays connect Publications between separate sync collections of the
   same trust domain.  Collections are differentiated by both subnet
   (the physical media) and domain id (a required field of the cState
   and cAdd PDUs).  Consequently, cStates and cAdds are subnet-sprecific
   while Publications belong to a trust domain (or sub-domain).

Nichols, et al.          Expires 4 October 2023                [Page 19]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   A Relay is implemented [DCT] as an entity running on a device with a
   DeftT interface on each subnet (two or more) or with multiple DeftT
   interfaces to the same subnet Figure 9 where each uses a different
   but compatible version of the others' schema.  Each DeftT
   participates in different sync collections and uses a communication
   identity valid for the schema used by the DeftT.  Only Publications
   (including certs) are relayed between DeftTs and the Publication must
   validate against the schema of each DeftT.  Consequently cAdd
   encryption is unique per collection while Publication encryption
   holds across the domain.

   As Relays do not originate Publications, their DeftT API module (a
   "shim", see Section 2.1) performs _pass-through_ of valid
   Publications.  The Relay of Figure 9-left is on three separate
   wireless subnets.  If all three DeftTs are using an identical schema,
   a new validated cert added to the cert store of an incoming DeftT is
   then passed to the other two, which each validate the cert before
   adding to their own cert stores (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 schemas and published if it passes.

   (Artwork only available as svg: figs/relayextend-rfc.svg)

                      Figure 9: Relays connect subnets

   A Relay may have different identities and schemas for each DeftT but
   _must_ have the same trust anchor and schemas must be identical
   copies, proper subsets or overlapping subsets of the domain schema.
   Publications that are undefined for a particular DeftT will be
   silently discarded when they do not validate upon relay, just as they
   are when received from a face.  This means the Relay application of
   Figure 9-left can remain the same but Publications will only be
   published to a different subnet if its DeftT has that specification
   in its schema.  Relays may filter Publications at the application
   level or restrict subscriptions on some of their DeftT interfaces.
   Figure 9-right shows extending a trust domain 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
   communications schema 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 9-right, local communications for subnet 1
   can be kept local while subnet 2 might send commands and/or collect
   log files from subnet 1.

Nichols, et al.          Expires 4 October 2023                [Page 20]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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 and can join at any
   time).  The mesh is efficient: publications are only added to an
   individual DeftT's collection once regardless of how it is received.
   Relays with overlapping broadcast physical media will only add a
   Publication to any of its DeftTs *once*; syncps ensures there are no
   duplicates.  More on the applicability of DeftT meshes is in
   Section 5.

2.6.  Congestion control

   Each DeftT 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 DeftTs 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.2, 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 members
   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 member 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
   members - 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 trust domain over a path whose
   bandwidth delay product is many times larger than typical subnet MTUs
   (1.5-9KB), the one-outstanding-PDU per member constraint can result
   in poor performance (1500 bytes per 100ms transcontinental RTT is

Nichols, et al.          Expires 4 October 2023                [Page 21]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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.

3.  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 schemas 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.  DCT is example code, not
   currently optimized for performance.

3.1.  Communications schemas

   Defined-trust's use of communications schemas has been influenced by
   [SNC][SDSI] and the field of _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).
   Communications schemas also have roots in the _trust schemas_ for
   Named-Data Networking, 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

Nichols, et al.          Expires 4 October 2023                [Page 22]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   validate packets.  A new approach to both a trust schema language and
   its integration with communications was introduced in [NDNW] and
   extended in [DNMP][IOTK][DCT].  In this approach, a 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-

   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 Defined-trust
   Communications which uses the more descriptive term _communication
   schema_ as the rules define the communications of a trust domain.

   VerSec, an approach to creating schemas, is included with the
   Defined-trust Communications 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 diagnostic output of the
   compiler (including a digraph listing) can be used to inspect that
   the intent for the communications schema has indeed been implemented.
   The binary form is used by DeftT to build (case 2) or validate (case
   3) the Publications (format covered in Section 2.3.1).  Certificates
   (Section 2.3.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

3.2.  A schema language

   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 rules.  VerSec continues to evolve and
   add new features as its application domain is expanded; the latest
   released version is at [DCT].  Other languages and compilers are
   possible as long as they supply the features and output needed for

Nichols, et al.          Expires 4 October 2023                [Page 23]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   A communication schema expresses the intent for a domain's
   communications in fine-grained rules: "who can say what."
   Credentials that define "who" are specified along with complete
   definitions of "what".  Defined-trust communications has been
   targeted at OT networking where administrative control is explicit
   and it is not unreasonable to assume that identities and
   communication rules can be securely configured at every device.  The
   schema details the meaning and relationship of individual components
   of the filename-like names (URI syntax [RFC3986]) of Publications and
   certificates.  A simple communications schema (Figure 10) defines a
   Publication in this domain 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 schema contains information on what part of the name is
   considered common prefix.  For the sake of simplicity, the Figure 10
   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* which allows it to
   create legal communications (using the associated private key in
   signing).  A signing certificate must adhere to the schema;
   Publications or cAdds with unknown signers are discarded.  The
   timestamp component is used to prevent replay attacks.  A DeftT adds
   its identity certificate chain to the domain certificate collection
   (see Section 4.2) at its startup, thus announcing its identity to all
   other members.  Using the pre-configured trust anchor and schema, any
   member can verify the identity of any other member.  This approach
   means members are not pre-configured with identities of other members
   of a trust domain and new entities can join at any time.

Nichols, et al.          Expires 4 October 2023                [Page 24]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

 #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 10: An example communication schema

   To keep the communications schema both compact and secure, it is
   compiled into a binary format that becomes the content of a schema
   certificate.  The [DCT] _schemaCompile_ converts the text version
   (e.g.  Figure 10) of the schema into binary as well as reporting
   diagnostics (see Figure 11) used to confirm the intent of the rules
   (and to flag problems).

   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 11: schemaCompile diagnostic output for example of Figure 10

   Even this simple schema 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 10.  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 or
   AEADSGN (signed AEAD) to encrypt Publications.  To make those member
   types meaningful, a role-based security policy could be employed by
   defining Publications such that only admins can issue _commands_ and
   only sensors can issue _status_. Specifying the AEAD validator for
   the cAddValidator means that at least one member of a subnet will

Nichols, et al.          Expires 4 October 2023                [Page 25]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   need a key maker attribute in its signing chain.  If AEADSGN is
   specified for the pubValidator, at least one member of the trust
   domain will need key maker capability.  In Figure 11 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 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 12: Enhancing security in the example schema

   In DeftT, identities include the member cert and its entire signing
   chain.  By adding attributes via _capability certificates_ in 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 certs will be
   covered in Section 4.

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

4.  Certificates and identity bundles

   Defined-trust's approach is partially based on the seminal SDSI
   [SDSI] approach to create user-friendly namespaces that establish
   transitive trust through a certificate (cert) chain that validates
   locally controlled and managed keys, rather than requiring a global
   Public Key Infrastructure (PKI).  When certificates are created, they
   have a particular context in which they should be utilized and
   trusted rather than conferring total authority.  This is particularly

Nichols, et al.          Expires 4 October 2023                [Page 26]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   useful in OT where communicating entities 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 this
   framework.  This section describes certificate requirements and the
   identity _bundles_ that are securely distributed to trust domain
   members.  (DCT includes utilities to create certs and bundles.)

4.1.  Obviate CA usage

   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.  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]).  DCT certificates (see Section 2.3.2) can be
   generated and signed locally (using supplied utilities) so there is
   no reason to aggregate a plethora of unrelated claims into one cert
   (avoiding the Aggregation problem [W509]).

   A DCT 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 be distributed through DeftT (e.g.,
   using a variant of the group key distributors in DCT).  If there is a
   need to exclude previously authorized identities from a domain, there
   are a variety of options.  The most expedient is via use of an AEAD
   cAdd or Publication validator by ensuring that the group key maker(s)
   of a domain exclude that entity from subsequent symmetric key
   distributions until its identity cert expires (and it is not issued
   an update).  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 schema and identities (without changing
   the trust anchor), e.g., using remote attestation via the TPM.

   From Section 3, a member cert is granted attributes in the schema via
   the certs that appear in its member identity chain.  Member certs are
   _always_ accompanied by their full chain-of-trust, both when
   installed and when the member publishes its identity to the cert
   collection.  Every signing chain in the domain has the same trust

Nichols, et al.          Expires 4 October 2023                [Page 27]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   anchor at its root and its legal form specified in the schema.
   Without the entire chain, a signer's right to issue Publications
   cannot be validated.  Cert validation is according to the schema
   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 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 certs are not open to the
   substitution attacks of name-based locators like X.509's "Authority
   Key Identifier" and "Issuer" [ConfusedDep][CAvuln][TLSvuln].

4.2.  Identity bundles

   Identity bundles comprise the certificates needed to participate in a
   trust domain: trust anchor, schema, and the member's identity chain.
   The private key corresponding to the leaf certificate of the member's
   identity chain should be installed securely when a device is first
   commissioned (e.g., out-of-band) for a network.  The public certs of
   the bundle may be placed in a file in a well-known location or may,
   in addition, have their integrity attested or even be encrypted.
   Secure device configuration and on-boarding should be carried out
   using the best practices most applicable to a particular deployment.
   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 both 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][RFC8995], or
   secure enclave or trusted execution environment (TEE) [ATZ].  In that
   case, 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.
   Where entities have public-private key pair identities of _any_
   (e.g., non-DCT) type, these can be leveraged for DeftT identity
   installation.  Figure 13 shows the steps involved in configuring
   entities and their 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.)

   (Artwork only available as svg: figs/tools.config-rfc.svg)

Nichols, et al.          Expires 4 October 2023                [Page 28]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

            Figure 13: Creating and configuring identity bundles

   In the examples at [DCT], an identity bundle is given directly to an
   application via the command line, useful for development, and the
   application passes callbacks to utility functions that supply the
   certs and a signing pair separately.  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 can have access to the TPM
   functions and the ability to create "short-lived" (~hours to several
   days) public/private key pair(s) that are signed by the installed
   (commissioned) private identity key using the TPM.  This publication
   signing key pair is created at (re)start and at the periodicity of
   the signing cert lifetime.  Since the signing happens via requests to
   the TPM, the identity key cannot be exfiltrated.

   The DCT examples and library use member identities to create signing
   certs (with associated secret keys) and the example schemas give the
   format for these signing cert names.  A DeftT will request a new
   signing cert shortly before expiration of the one in use.

   Upon each signing cert update, only the new cert needs to be
   published via DeftT's cert distributor.  Figure 14 outlines a
   representative procedure.

   (Artwork only available as svg: figs/InstallIdbundle-rfc.svg)

    Figure 14: Representative commissioning and signing key maintenance

   All DCT certs have a validity period.  Certs that sign publications
   are generated locally so they can easily be refreshed as needed.
   Trust anchors, schemas, and the member identity chain are higher
   value and often require generation under hermetic conditions by some
   authority central to the organization.  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 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.  The
   example here is merely illustrative; with pre-established secure
   identities and well-founded approaches to secure on-line
   communications, a trust domain could be created OTA using secure
   identities established through some other system of identity.

Nichols, et al.          Expires 4 October 2023                [Page 29]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

5.  Use Cases

5.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 can receive sensor information and
   transmit it to monitor/controllers and servers.  These gateway
   devices 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 (beyond DeftT's usual identity bundle and private key)
   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 packets from a particular sensor over time.  A
   DeftT mesh captures Publications _anywhere_ within its combined
   network coverage area and ensures it efficiently reaches all members

Nichols, et al.          Expires 4 October 2023                [Page 30]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   as long as they are in range of at least one member that has received
   the information.  An out-of-service or out-of-range member can
   receive all active subscribed publications once it is in range and/or
   able to communicate.  This use of DeftT is illustrated in Figure 15
   where bluetooth-using devices (BT Dev) are deployed as sensors,
   switches, cameras, lock openers, etc.  A WiFi network includes tablet
   devices and a monitor/controller computer.  Gateway devices each have
   a Relay using both a Bluetooth interface and a WiFi interface.
   Gateways are placed so that there is always at least one in range of
   a BT device and at least one other Gateway (or the Controller) in its
   WiFi range.  WiFi tablets can move around within range of one or more
   Gateways.  All the DeftTs may use the same schema, giving devices on
   the WiFi network access to all of the BT devices.  Applications on
   any particular device may subscribe to a subset of the information
   available.  If privacy of longer-range data is required, the WiFi
   DeftTs can use a schema that requires encrypting its cAdds.  These
   configuration choices are made by changes in the schemas alone, the
   application code is exactly the same.  No configuration is needed to
   make devices recognize one another and syncps will keep
   communications efficient, ensuring that all DeftTs in the trust
   domain know what information is available.  The face ensures that
   identical cStates are only sent once (within broadcast range).  These
   features mean that DeftT forms efficient broadcast meshes with no
   additional configuration beyond identity bundles, an important

   (Artwork only available as svg: figs/meshEx-rfc.svg)

       Figure 15: IIOT meshed gateways connect a single trust domain

   In addition to specifying encryption and signing types, schema 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, relayed through
   the Internet, while only plant Security can see images from on-site

5.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

Nichols, et al.          Expires 4 October 2023                [Page 31]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   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 brokerless 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 DeftT allows both goals to be met
   *  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

Nichols, et al.          Expires 4 October 2023                [Page 32]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

      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 communication
      rules and then secured by DeftT's use of compiled schemas.

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

6.  Using Defined-trust Communications without DeftT

   Parts of the defined-trust communications 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.

7.  Terms

   *  certificate thumbprint: the 32 byte SHA256 digest of an _entire_
      certificate including its signature ensuring that each thumbprint
      resolves to one and only one cert and signing chain
   *  collection: a set of elements denoted by a structured name that
      includes the identifier of a particular communications schema
   *  communications schema: defined set of rules that cover the
      communications for a particular application domain.  Where it is
      necessary to distinguish between the human readable version and
      the compiled binary version, the modifiers "text" or "binary" will
      be used.  The binary version is placed in a certificate signed by
      the domain trust anchor.

Nichols, et al.          Expires 4 October 2023                [Page 33]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   *  DCT: Defined-trust Communications Toolkit.  Running code, examples
      and documentation for defined-trust communications tools, a schema
      language and compiler, a DeftT implementation, and illustrative
   *  face: maintains tables of DeftT's cState PDUs to manage efficient
      communications with the system transport in use (UDP multicast,
      TCP, etc.)
   *  identity: a certificate signing chain with a particular domain's
      trust anchor at its root and a unique member certificate as the
      leaf.  The public certificates in the chain contain attributes and
      capabilities for the leaf member cert.  The secret key associated
      with the public key of the member cert should be securely
      configured for member use.
   *  identity bundle - entities in a trust domain are commissioned with
      an identity bundle of trust anchor, signed communication schema
      cert, and the signing chain associated with a particular identity
   *  Publication: a named information object exchanged used by DeftT
      where name structure and the required identity roles and
      capabilities for Publications are specified by the schema.
      Publications are the elements of the sets that are reconciled by
      DeftT's sync protocol.  (Capitalization is used to distinguish
      this specific use from both the action and more generic use of the
   *  protocol data unit (PDU): a single unit of information transmitted
      among entities of a network composed of protocol-specific control
      information and user data.  DeftT uses two types: cState: (from
      "collection state") and cAdd: (from "collection additions")
   *  sync protocol: a synchronization protocol that implements set
      reconciliation of Publications on a subnet making use of cState
      and cAdd PDUs
   *  Things: as per [RFC8520], networked digital devices specifically
      not intended to be used for general purpose computing
   *  trust anchor: NIST SP 800-57 Part 1 Rev. 5 definition "An
      authoritative entity for which trust is assumed.  In a PKI, a
      trust anchor is a certification authority, which is represented by
      a certificate that is used to verify the signature on a
      certificate issued by that trust-anchor.  The security of the
      validation process depends upon the authenticity and integrity of
      the trust anchor's certificate.  Trust anchor certificates are
      often distributed as self-signed certificates."  In defined-trust
      communications, a trust anchor is a self-signed certificate which
      is the ultimate signer of all certificates in use in a trust
      domain, including the communications schema.  From RFC4949: trust
      anchor definition: An established point of trust (usually based on
      the authority of some person, office, or organization) which
      allows the validation of a certification chain.

Nichols, et al.          Expires 4 October 2023                [Page 34]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   *  trust domain: a shorthand form for _Defined-trust Communications
      Limited Domain_, a zero trust domain governed by a single trust
      anchor and communications schema which is enforced at run-time by
      a library (e.g., DCT) using a signed binary copy of the schema at
      each member.  Nothing is accepted without validation; non-
      conforming communications are silently discarded.  As the schema
      cert is signed by the trust anchor, a trust comain is uniquely
      identified by the schema cert's thumbprint.  Where context is
      clear, just _domain_ may be used.
   *  trust-based Relay: (or just Relay) a special-purpose entity that
      connects a trust domain across different subnets

8.  Security Considerations

   This document presents 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 only valid PDUs are accepted at receiver; invalid PDUs are
   dropped by uncompromised member).  Although securing DeftT's code is
   out-of-scope for this document, DeftT has been designed to be easily
   deployed with a TEE.  Revisiting Figure 4, Figure 16 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.

   (Artwork only available as svg: figs/hwtrust-rfc.svg)

       Figure 16: 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 of similar high quality.

   Enrollment of devices is out of scope.  A range of solutions are
   available and selection of one is dependent on specifics of a
   deployment.  Example approaches include the Open Connectivity
   Foundation (OCF) onboarding and BRSKI [RFC8995].  NIST NCCOE network
   layer onboarding might be adapted, treating a communications schema
   like a MUD URL.

Nichols, et al.          Expires 4 October 2023                [Page 35]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   Protecting private identity and 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 (Section 2.3.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.  Publications have a
   lifetime enforced by their sync collection; 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 schema and each DeftT checks at
       startup that one of these two properties holds for the 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 PDU's
          signature or the PDU is dropped.

       *  for encrypted PDUs (and Publications) 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 and Publications are

Nichols, et al.          Expires 4 October 2023                [Page 36]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

       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 dropped cAdds.
       Unlike unicast transports, DeftT can and will obtain any
       Publications missing from its collection from any member 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 member 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 schema in
   certificate format signed by this trust anchor, and its own member
   identity chain with a private identity 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 attributes 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.

Nichols, et al.          Expires 4 October 2023                [Page 37]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   The example encryption modules provide for encryption on both cAdd
   PDUs and Publications.  The latter _must_ be signed by the originator
   in addition to being encrypted.  This is not required for cAdd PDUs,
   so the specific entity that sent the cAdd cannot be determined but
   the Publications it carries _must_ be signed, even if not encrypted.
   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].

   DeftT relies on libsodium and linux random implementations with
   respect to entropy issues.  In general, these are quite application-
   dependent and should be further addressed for particular deployments.

9.  IANA Considerations

   This document has no IANA actions.

10.  Normative References

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,

   [RFC9119]  Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
              Zuñiga, "Multicast Considerations over IEEE 802 Wireless
              Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,

11.  Informative References

   [ATZ]      Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and S.
              Martin, "TrustZone Explained: Architectural Features and
              Use Cases", 2016, <>.

   [CAvuln]   Marlinspike, M., "More Tricks for Defeating SSL in
              Practice", 2009, <

   [CHPT]     CheckPoint, "The Dark Side of Smart Lighting: Check Point
              Research Shows How Business and Home Networks Can Be
              Hacked from a Lightbulb", February 2020,

Nichols, et al.          Expires 4 October 2023                [Page 38]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   [CIDS]     OperantNetworks, "Cybersecurity Intrusion Detection System
              for Large-Scale Solar Field Networks", 2021,

   [COMIS]    Lydersen, L., "Commissioning Methods for IoT", February

   [COST]     Guy, W., "Wireless Industrial Networking Alliance, Wired
              vs. Wireless: Cost and Reliability", October 2005,

              Support, G. C., "Additional authenticated data guide",
              July 2021, <

   [DCT]      Pollere, "Defined-trust Communications Toolkit", 2022,

   [DER]      NERC, "North American Electric Reliability Corporation:
              Distributed Energy Resources: Connection, Modeling, and
              Reliability Considerations", February 2017,

   [DIFF]     Eppstein, D., Goodrich, M. T., Uyeda, F., and G. Varghese,
              "What's the difference?: efficient set reconciliation
              without prior context", 2011.

   [DIGN]     Bandyk, M., "As Dominion, others target 80-year nuclear
              plants, cybersecurity concerns complicate digital
              upgrades", November 2019,

   [DLOG]     Li, N., Grosof, B., and J. Feigenbaum, "Delegation logic",
              February 2003, <>.

   [DMR]      al., M. C. E., "Device Management Requirements to Secure
              Enterprise IoT Edge Infrastructure", April 2021,

Nichols, et al.          Expires 4 October 2023                [Page 39]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   [DNMP]     Nichols, K., "Lessons Learned Building a Secure Network
              Measurement Framework Using Basic NDN", September 2019.

   [DTM]      Blaze, M., Feigenbaum, J., and J. Lacy, "Decentralized
              Trust Management", June 1996,

   [Demers87] 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", 1987,

   [Graphene] Ozisik, A. P., Andresen, G., Bissias, G., Houmansadr, A.,
              and B. N. Levine, "Graphene: A New Protocol for Block
              Propagation Using Set Reconciliation", 2017,

              Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D.,
              Bissias, G., and S. Katkuri, "Graphene: efficient
              interactive set reconciliation applied to blockchain
              propagation", 2019,

   [HSE]      Kapersky, "Secure Element", 2022,

   [IAWS]     Ganapathy, K., "Using a Trusted Platform Module for
              endpoint device security in AWS IoT Greengrass", November
              2019, <Using a Trusted Platform Module for endpoint device
              security in AWS IoT Greengrass>.

   [IBLT]     Goodrich, M. T. and M. Mitzenmacher, "Invertible bloom
              lookup tables", 2011,

   [IEC]      IEC, "Power systems management and associated information
              exchange - Data and communications security - Part 8:
              Role-based access control for power system management",
              2022, <>.

   [IEC61850] Wikipedia, "IEC 61850", 2021,

Nichols, et al.          Expires 4 October 2023                [Page 40]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   [IIOT]     Rajiv, "Applications of Industrial Internet of Things
              (IIoT)", June 2018, <

   [IOTK]     Nichols, K., "Trust schemas and {ICN:} key to secure home
              IoT", 2021, <>.

              ISO, "Industrial automation systems --- Manufacturing
              Message Specification --- Part 1: Service definition",
              2003, <

   [LANG]     LANGSEC, "LANGSEC: Language-theoretic Security "The View
              from the Tower of Babel"", 2021, <>.

   [MATR]     Alliance, C. S., "Matter is the foundation for connected
              things", 2021, <>.

   [MHST]     Wikipedia, "MQTT", 2022,

   [MINSKY03] Minsky, Y., Trachtenberg, A., and R. Zippel, "Set
              reconciliation with nearly optimal communication
              complexity", 2003,

   [MODOT]    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)",
              January 2022,

   [MPSR]     Mitzenmacher, M. and R. Pagh, "Simple multi-party set
              reconciliation", 2018.

   [MQTT]     OASIS, "MQTT: The Standard for IoT Messaging", 2022,

   [NDNS]     NDN, "Named Data Networking Packet Format Specification
              0.3", 2022,

Nichols, et al.          Expires 4 October 2023                [Page 41]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   [NDNW]     Jacobson, V., "Watching NDN's Waist: How Simplicity
              Creates Innovation and Opportunity", July 2019,

   [NERC]     NERC, "Emerging Technology Roundtable - Substation
              Automation/IEC 61850", November 2016,

   [NMUD]     al, D. D. E., "Securing Small-Business and Home Internet
              of Things (IoT) Devices: Mitigating Network-Based Attacks
              Using Manufacturer Usage Description (MUD)", May 2021,

   [NPPI]     Hashemian, H. M., "Nuclear Power Plant Instrumentation and
              Control", 2011, <

   [NVR]      Gutmann, P., "Everything you Never Wanted to Know about
              PKI but were Forced to Find Out", 2002,

   [ONE]      OneDM, "One Data Model", 2022, <>.

   [OPR]      King, R., "Commercialization of NDN in Cybersecure Energy
              System Communications video", 2019, <

   [OSCAL]    NIST, "OSCAL: the Open Security Controls Assessment
              Language", 2022, <>.

   [OTPM]     Hinds, L., "Keylime - An Open Source TPM Project for
              Remote Trust", November 2019,

   [OWASP], "SideKEK README", June
              2020, <>.

   [PRAG]     e}bowicz, J. W., Cabaj, K., and J. Krawiec, "Messaging
              Protocols for IoT Systems---A Pragmatic Comparison", 2021,

   [QTPM]     Arthur, D. C. W., "Quick Tutorial on TPM 2.0", January
              2015, <

Nichols, et al.          Expires 4 October 2023                [Page 42]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   [RFC2693]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
              B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
              DOI 10.17487/RFC2693, September 1999,

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <>.

   [RFC6335]  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, August 2011,

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <>.

   [RSK]      Ellison, C. and B. Schneier, "Ten Risks of PKI: What
              You're Not Being Told About Public Key Infrastructure",

   [SDSI]     Rivest, R. L. and B. W. Lampson, "SDSI - A Simple
              Distributed Security Infrastructure", April 1996.

   [SIOT]     Truong, T., "How to Use the TPM to Secure Your IoT/Device
              Data", January 2017, <

Nichols, et al.          Expires 4 October 2023                [Page 43]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

   [SKH]      Yates, T., "Secure key handling using the TPM", October
              2018, <>.

   [SNC]      Smetters, D. K. and V. Jacobson, "Securing Network
              Content", October 2009, <

   [SOD]      Bernstein, D., Lange, T., and P. Schwabe, "libsodium",
              2022, <>.

   [SPRV]     AgendalessConsulting, "Supervisor: A Process Control
              System", 2022, <>.

   [ST]       Samsung, "SmartThings API (v1.0-PREVIEW)", 2020,

   [STNDN]    Yu, Y., Afanasyev, A., Clark, D. D., claffy, K., Jacobson,
              V., and L. Zhang, "Schematizing Trust in Named Data
              Networking", 2015.

   [TATT]     Microsoft, "TPM attestation", June 2021,

   [TLSvuln]  al., C. B. E., "Using Frankencerts for Automated
              Adversarial Testing of Certificate Validation in SSL/TLS
              Implementations", November 2014,

   [TPM]      Griffiths, P., "TPM 2.0 and Certificate-Based IoT Device
              Authentication", September 2020,

   [W509]     Wikipedia, "X.509: Security", October 2021,

   [WSEN]     Kintner-Meyer, M., Brambley, M., Carlon, T., and N.
              Bauman, "Wireless Sensors: Technology and Cost-Savings for
              Commercial Buildings", 2002,

Nichols, et al.          Expires 4 October 2023                [Page 44]
Internet-Draft       Defined-Trust Transport (DeftT)          April 2023

              Wegman, M. N. and L. Carter, "New Hash Functions and Their
              Use in Authentication and Set Equality", 1981,

   [ZCL]      zigbeealliance, "Zigbee Cluster Library Specification
              Revision 6", 2019, <


   Lixia Zhang

   Roger Jungerman
   Operant Networks Inc.

   Roger contributed much to Section 5.

Authors' Addresses

   Kathleen Nichols
   Pollere LLC

   Van Jacobson

   Randy King
   Operant Networks Inc.

Nichols, et al.          Expires 4 October 2023                [Page 45]