This document defines the problem statement, common terminology, security models, and technical requirements for identifying, validating, and establishing secure connections with local network devices. It outlines the challenges of extending the Web's Public Key Infrastructure (PKI) to local, offline, or "limited domain" environments. The document specifies requirements for privacy-preserving discovery, generating and distributing local trust anchors, and establishing mutually authenticated secure contexts without relying on global certificate authorities or problematic Trust On First Use (TOFU) mechanisms.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 25 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/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.¶
Local networks have historically used a mix of encrypted and unencrypted communications with no common method to establish trust. Access is provided to those who have the Wi-Fi password or an Ethernet cable, and the connected device simply trusts the information provided to it by the DHCP service on that network. In contrast, the Internet increasingly uses encrypted communications with a well-regulated system of Certificate Authorities, Domain Name Providers, Address Registries, and distributed Domain Name Services that form the basis of trust on the "modern web."¶
With the advent of HTTPS everywhere, browsers disadvantage web services using unencrypted communications by requiring a Secure Context for features such as Direct Sockets, Geolocation, Service Workers, Web Bluetooth, WebCrypto, WebTransport, and WebRTC. The concept of "Limited Domains" [RFC8799] encapsulates these local, constrained environments, but existing web security models struggle to adapt to them. Furthermore, modern browser security models, such as Local Network Access (LNA), restrict public websites from making requests to private IP addresses without explicit secure contexts and user permissions.¶
Existing deployments of TLS on local networks typically use "self-signed" X.509 certificates that lack the endorsement of a trusted party, relying instead on Trust on First Use (TOFU) mechanisms. Because the client User Agent lacks a cryptographic trust anchor for the local device, it presents a "scary" certificate warning. Users frequently disregard these warnings, leading to warning fatigue and leaving them vulnerable to active interception. Conversely, network devices are unable to determine the trustworthiness of the local network, humorous solutions such as the "evil bit" from [RFC3514] aside.¶
This document defines common terminology and requirements for discovering, identifying, validating, and establishing secure connections with local network devices without relying on Trust On First Use (TOFU) or continuous Internet connectivity.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Secure Context:
An environment meeting the minimum standards of authentication and confidentiality as defined by the W3C Secure Contexts specification [W3C.SecureContexts].¶
Bootstrapping:
The process of establishing an initial trust relationship and secure communication channel between a User Agent and a Device where no prior relationship exists.¶
Certificate Authority:
A party or service [RFC8555] that provides Cryptographic Identities that are signed by one or more Trust Anchors for the purpose of establishing trust [RFC5280].¶
Client Device:
A Device used primarily by End Users to access services, e.g., a smartphone, a laptop, a tablet.¶
Client Identity:
A Cryptographic Identity bound to a Client Device that has been signed by a Trust Anchor.¶
Cryptographic Identity:
A persistent, cryptographically verifiable identifier, e.g., an X.509 public key infrastructure certificate [RFC5280].¶
Device:
An entity with a network interface that connects to a local network.¶
Device Identity:
A Cryptographic Identifier bound to a specific Device. This may be derived from a hardware manufacturer root, e.g., Initial Device Identifier, IDevID [IEEE.802.1AR], or locally generated value.¶
Device Name:
A DNS or mDNS label for a Device. [MOVE THIS: It MUST be locally unique, and SHOULD be globally unique to prevent collisions.]¶
Infrastructure Device:
A Device providing a service on the local network, e.g., a printer, a router, an IoT hub.¶
Infrastructure Identity:
A Cryptographic Identity bound to an Infrastructure Device that has been signed by a Trust Anchor.¶
A program that can originate authoritative responses for a given target resource [RFC9110], e.g. a web server..¶
Out-of-Band (OOB) Ceremony:
A mechanism for transferring trust entropy via a channel physically separate from the network. [MOVE THIS: Different mechanisms offer varying security properties, including QR codes (visual, high entropy), PIN entry (manual, low entropy), Short Authentication Strings (SAS), Near Field Communication (NFC), or Push-Button Configuration (PBC).]¶
Trust Anchor:
A Cryptographic Identity that is trusted by a Client Device and/or UA.¶
Trust On First Use (TOFU):
An approach where a Client Device and/or UA accepts the first Cryptographic Identity presented by an Infrastructure Device or Origin Server. The identity is sometimes confirmed by an End User before acceptance.¶
Referee (Local Manager):
An Infrastructure Device that is designated as the Local Certificate Authority/trust broker, transitioning a mesh of unverified devices into a hub-and-spoke trust topology. [QUESTION: Is the latter a hard requirement or just how current referees are defined/implemented?]¶
User Agent (UA):
A client program that initiates a request to an Origin Server [RFC9110], e.g., a web browser.¶
The SETTLE architecture operates under the assumption of a Zero-Trust Local Area Network. Trust cannot be spontaneously generated within a channel controlled by an active adversary; it must be introduced from an external source (a Trust Anchor). The threat model includes the following constraints and capabilities:¶
Active On-Path Attacker (Dolev-Yao): The local network is assumed to be hostile. An adversary can intercept, drop, modify, and inject packets. This includes spoofing DNS/mDNS responses and cloning SSIDs to act as a rogue access point (Evil Twin attacks).¶
No Implicit Trust on First Use (TOFU): Because an active attacker may be present at the moment of initial connection, blind acceptance of a self-signed certificate (TOFU) is cryptographically indistinguishable from accepting an attacker's key. TOFU is explicitly disqualified as a primary bootstrapping mechanism.¶
Compromised Pledges and Supply Chain: Malicious or compromised devices may attempt to join the network. Furthermore, while manufacturer-installed certificates (IDevID) provide a hardware root of trust, the supply chain itself may experience private key leakage, necessitating constrained scoping of manufacturer trust.¶
Intermittent Connectivity: The solution MUST NOT fail closed if the local network is disconnected from the broader Internet. Devices must be able to securely pair and communicate in an air-gapped or offline environment.¶
Supply Chain Variability: While some devices will possess IDevIDs, the architecture must accommodate "self-hosted" devices built on generic computing hardware (where no single supply chain authority exists).¶
Because global PKI is unsuited for local names, and TOFU provides no active-attacker protection, a Secure Context requires either a rigorous pre-installed root (which fails for generic hardware) or the physical User to mediate the initial trust binding via an Out-of-Band (OOB) Ceremony.¶
The core challenge of securing local network communications stems from the disconnect between the global Web PKI and local network topologies. Securing an HTTPS connection requires clearing three hurdles:¶
Resolution: The identifier provided by the user or discovered on the network must translate to an IP address.¶
Identity Binding: The certificate presented by the target must correspond to the requested name.¶
Trust Anchor Validation: The certificate must be cryptographically signed by a trust anchor recognized by the client.¶
On the public Internet, these are solved via global DNS, Web PKI, and browser-bundled Root CAs. On a local network, devices reside behind NAT, use non-routable IP addresses (e.g., [RFC3927], [RFC4193]), lack delegated public domain names, and face address-space ambiguity (e.g., CGNAT 100.64.0.0/10 spaces being treated as public by some parsers and private by others).¶
This represents an application of Zooko's Triangle [ZookosTriangle]: naming systems struggle to be simultaneously Human-meaningful, Secure, and Decentralized. To solve this, SETTLE must bypass the following flawed approaches:¶
The Cloud/Dynamic DNS Workaround (e.g., Plex Model): Approaches using dynamic DNS to map local IPs to global subdomains paired with wildcard certificates require persistent Internet connectivity, external infrastructure, and fail completely in air-gapped environments. They also leak local topologies to global DNS.¶
Manufacturer-Only Trust: Relying solely on manufacturer-installed certificates (IDevID) creates a "naming disconnect" (the cert binds a key to a serial number, not a local name like "printer.local"). Furthermore, it excludes "self-hosted" software running on generic hardware.¶
Trust On First Use (TOFU): As established in the Threat Model, TOFU automates vulnerability rather than solving warning fatigue.¶
Conclusion: To establish Secure Contexts without Cloud or Manufacturer-only infrastructure, the system must utilize the User to mediate trust via an OOB Ceremony. Consequently, User Agents MUST possess a mechanism to ingest and store these user-verified roots in a dynamic local trust store (S_Local).¶
The SETTLE architecture builds upon and differentiates itself from several existing approaches:¶
BRSKI and BRSKI-PRM: Bootstrapping Remote Secure Key Infrastructure [RFC8995] automates provisioning using manufacturer IDevIDs. BRSKI-PRM [I-D.ietf-anima-brski-prm] demonstrates the value of object security (signed Vouchers) over transport security for environments where pledges cannot initiate TLS connections. While powerful, BRSKI requires a supply chain root of trust, which is absent in self-hosted consumer scenarios.¶
Matter Protocol: Matter utilizes Password-Authenticated Session Establishment (PASE) [Matter] for onboarding. However, security analyses have highlighted flaws including low-entropy (27-bit) passcodes and static salts, emphasizing the need for higher entropy in OOB ceremonies.¶
Wi-Fi Easy Connect (DPP): Uses QR codes containing public keys to bootstrap WPA3 credentials [DPP]. This provides a strong precedent for OOB ceremonies, though it targets network-layer access rather than application-layer TLS identity.¶
Open Screen Protocol: The W3C Open Screen Network Protocol [W3C.OpenScreen] provides a particularly clean construction for local device pairing without pre-shared keys. Devices establish a provisional QUIC/TLS connection using self-signed certificates, then authenticate it via SPAKE2 [RFC9382] bound to a user-transferred PIN. This pattern of "connect first, authenticate via PAKE second" is directly applicable to SETTLE's Track A. Emerging IETF work on integrating PAKEs directly into TLS 1.3 [I-D.ietf-tls-pake] may provide a standardized transport for this class of bootstrapping.¶
AirDrop / PrivateDrop: Traditional local discovery using truncated hashes leaks user identifiers. Research into Private Set Intersection (PSI) [PrivateDrop] demonstrates that privacy-preserving mutual discovery is feasible with sub-second latency.¶
SDSI/SPKI: Simple Distributed Security Infrastructure [RFC2693] proposed a decentralized PKI binding authorizations directly to keys. While conceptually aligned with local trust, modern web browsers mandate X.509 [RFC5280] for compatibility.¶
Local Public Key Hashes: Approaches that embed public key hashes into local domain names [I-D.wing-settle-public-key-hash] offer self-certifying namespaces but sacrifice human-readability.¶
Local Referees and ACME: Architectures utilizing a central local hub to authenticate servers [I-D.wing-settle-referee] or issue certificates via a local ACME server [I-D.sweet-iot-acme] optimize UX but require initial bootstrapping of the Referee itself.¶
To prevent circular dependencies, SETTLE requirements are organized into two composable tracks. Implementers may choose the track appropriate for their ecosystem.¶
This track addresses the bootstrapping of a single link between a UA and a Target when shared trust is initially zero. It relies on an Out-of-Band (OOB) Ceremony (e.g., scanning a QR code as in DPP [DPP]) to transfer trust entropy and establish a mutual Trust Anchor directly. This track may use transport security (e.g., Bootstrapped TLS [I-D.ietf-emu-bootstrapped-tls]) or object security (e.g., signed payloads). A promising pattern is to establish a provisional TLS connection using self-signed certificates, then authenticate it via a Password-Authenticated Key Exchange (PAKE) such as SPAKE2 [RFC9382] bound to the OOB secret, as demonstrated by the Open Screen Protocol [W3C.OpenScreen]. Separately, [I-D.ietf-tls-pake] proposes native TLS 1.3 support for PAKE-based authentication, reflecting broader interest in standardizing PAKE mechanisms at the transport layer. This track is optimized for ad-hoc connections and generic hardware, bridging the gap without relying on any intermediaries.¶
To avoid the user friction of performing manual OOB Ceremonies for every device, this track introduces a trusted local intermediary (a Referee [I-D.wing-settle-referee]). The user bootstraps trust with the Referee (via Track A). The Referee subsequently acts as a local Certificate Authority (e.g., using ACME [RFC8555], [I-D.sweet-iot-acme] or EST [RFC7030]) to issue credentials to other Infrastructure Devices. The UA inherently trusts the network via its binding to the Referee.¶
The system MUST provide a mechanism to assign unique names to local devices. To prevent collisions, names SHOULD incorporate high-entropy device-specific data, such as MAC addresses [I-D.housley-lamps-macaddress-on] or public key hashes [I-D.wing-settle-public-key-hash].¶
REQ-NAME-02: Local Namespace Compatibility
Local device names MUST utilize standardized namespaces reserved for local or non-DNS use to ensure broad client support. Valid namespaces include ".local" for mDNS [RFC6762], "home.arpa." for unicast DNS [RFC8375], or ".alt" [RFC9476].¶
REQ-NAME-03: Independence from Global DNS
Name resolution MUST NOT depend on the availability of global DNS infrastructure.¶
REQ-NAME-04: Standardized Discovery
The system MUST utilize standard local discovery protocols, such as DNS-Based Service Discovery (DNS-SD) [RFC6763] or Captive Portal APIs [RFC8910], to locate devices prior to authentication.¶
REQ-NAME-05: Privacy-Preserving Discovery
The discovery mechanism MUST prevent passive tracking of devices or users. The system MUST NOT broadcast static identifiers (like MAC addresses or static account hashes) in plaintext if the device is portable. Systems SHOULD utilize rotating identifiers or cryptographic mechanisms like Private Set Intersection (PSI).¶
The architecture MUST NOT rely on Trust On First Use (TOFU) executed exclusively over the local network interface for initial authentication.¶
REQ-TRUST-02: Out-of-Band (OOB) Ceremony
The system MUST define or profile an OOB mechanism to transfer trust entropy. The OOB material MUST provide at least 128 bits of entropy to resist offline dictionary and GPU brute-force attacks.¶
REQ-TRUST-03: Pre-Installed Trust Optimization
The system SHOULD support the use of manufacturer-installed certificates (e.g., IDevID [IEEE.802.1AR], [I-D.irtf-t2trg-taxonomy-manufacturer-anchors]). When used, the system MUST define a mechanism (e.g., Vouchers [RFC8366]) to cryptographically bind the manufacturer-provided identity to the user-facing Local Device Name. This mechanism MUST NOT be the only method supported.¶
REQ-TRUST-04: Dynamic Local Trust Store
User Agents MUST implement a scoped, dynamic trust store capable of ingesting and persisting Trust Anchors generated or verified via OOB Ceremonies, independent of the OS-level global PKI trust store.¶
REQ-TRUST-05: Mutual Authentication
The bootstrapping protocol MUST support mutual authentication, allowing both the User Agent to verify the Target, and the Target to verify the authorization of the User Agent connecting to it.¶
All communications requiring a secure context MUST utilize TLS 1.3 [RFC8446] or equivalent modern transport security protocols.¶
REQ-TRANS-02: Implicit TLS Preference
To minimize downgrade attacks, the system SHOULD utilize Implicit TLS (connect-then-handshake) rather than connection-upgrade mechanisms (e.g., STARTTLS) [RFC8314].¶
REQ-TRANS-03: Subject Alternative Name (SAN) Matching
Device certificates MUST populate the Subject Alternative Name (SAN) extension. User Agents MUST verify these identities in accordance with [RFC9525] and IoT TLS profiles [I-D.ietf-uta-tls13-iot-profile].¶
REQ-TRANS-04: Browser Policy Compatibility
The protocol MUST integrate seamlessly with browser Local Network Access (LNA) policies. Devices MUST be capable of serving verifiable certificates to answer preflights, enabling transparent authorization and minimizing unnecessary user friction.¶
REQ-TRANS-05: Interoperability and Agility
The protocols chosen MUST support cryptographic agility to accommodate future algorithm deprecations and ensure interoperability between independent vendor implementations.¶
The system MUST operate securely without requiring Internet connectivity.¶
REQ-ARCH-02: Referee / Delegation Support
The system MUST support a hierarchical local trust model (Track B) where a mutually authenticated Referee can issue credentials to other local devices.¶
REQ-ARCH-03: Device Lifecycle and Key Rotation
The system MUST provide mechanisms for routine key rotation, certificate renewal without user intervention, and trust revocation. A factory reset of a Device MUST cryptographically invalidate and purge all prior local trust bindings.¶
REQ-ARCH-04a: Authorization
The system MUST provide mechanisms to explicitly authorize clients for specific roles (e.g., administrator vs. guest), preventing unauthorized configuration changes.¶
REQ-ARCH-04b: Audit and Transparency
Devices SHOULD provide a standard API allowing authorized controllers to audit all active trust bindings and access control lists to prevent "hidden" administrative fabrics.¶
REQ-ARCH-05: User Consent
User Agents and Referees MUST clearly present trust decisions to the user, ensuring the user is actively aware of which devices are trusted.¶
An attacker may clone a local Wi-Fi access point (Evil Twin), spoof BSSIDs, or poison mDNS caches to redirect traffic to a malicious endpoint. Because SETTLE mandates an OOB Ceremony (REQ-TRUST-02) and rejects pure TOFU, the UA will detect the certificate mismatch and abort the connection, neutralizing the impersonation.¶
In Track B deployments, the Referee acts as the root of trust for the local network. If the Referee is compromised, the attacker can issue trusted certificates for any name within the local namespace, enabling widespread MITM attacks against the UA. Referees MUST be implemented on hardened devices with minimal external attack surfaces, and clients SHOULD scope Referee trust to the explicit local namespace.¶
If installing trust anchors is made significantly easier, malicious actors (e.g., fake "customer support") may instruct users to scan a malicious QR code, thereby installing a rogue trust anchor. UAs MUST provide clear, unambiguous UI warnings during the OOB ceremony about the implications of trusting a new device or Referee.¶
Public websites often attempt to use the browser as a "confused deputy" to attack local network devices via Cross-Site Request Forgery (CSRF). SETTLE's requirement for mutual authentication (REQ-TRUST-05) and compatibility with Local Network Access (LNA) policies (REQ-TRANS-04) ensures devices reject unauthenticated cross-origin requests.¶
Research into IoT protocols has shown that hardware factory resets frequently fail to clear all administrative fabrics or ACLs, leaving devices vulnerable to prior owners. REQ-ARCH-03 mandates that a factory reset MUST completely destroy all cryptographic material linking the device to prior trust domains.¶
When utilizing Pre-Installed Trust (IDevID), a compromised manufacturer or stolen batch of private keys allows an attacker to masquerade as a legitimate device. UAs SHOULD support mechanisms to constrain manufacturer trust to specific scopes or require secondary local validation.¶
While DHCP options exist to distribute network configurations, modern operating systems actively isolate DHCP-provided data from User Agents (browsers) to prevent rogue DHCP servers from injecting malicious trust anchors. Consequently, SETTLE cannot rely on DHCP for the distribution of Trust Anchors to User Agents, reinforcing the need for OOB or application-layer bootstrapping.¶
Local networks are vulnerable to resource exhaustion. Malicious peers may flood the network with mDNS advertisements, initiate thousands of TLS handshakes, or attempt to exhaust certificate enrollment limits (e.g., attacking a local ACME server). Implementations SHOULD employ rate-limiting and prioritize OOB-authenticated traffic.¶
In accordance with [RFC6973], privacy vulnerabilities in local networks must be considered.¶
Device Tracking: Utilizing MAC addresses or static hardware identifiers in Local Device Names (e.g., mDNS broadcasts) allows passive observers on the local network to track device presence and infer user behavior. Portable devices SHOULD utilize privacy-preserving, rotating identifiers.¶
Account-Scoped Identifiers: Embedding account-level UUIDs into local certificates (as seen in some proprietary local sharing protocols) allows devices belonging to the same user to be correlated by passive observers. Device identities MUST be scoped to the device itself, not a global user account, unless protected by an encrypted transport.¶
Hash-Based Contact Leaks: Transmitting truncated hashes of contact information (e.g., phone numbers or emails) for mutual discovery is vulnerable to brute-force reversal. Implementations prioritizing privacy SHOULD utilize Private Set Intersection (PSI) [PrivateDrop] or similar cryptographic techniques for discovery.¶
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3927]
Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, , <https://www.rfc-editor.org/info/rfc3927>.
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, , <https://www.rfc-editor.org/info/rfc6973>.
[RFC7030]
Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, , <https://www.rfc-editor.org/info/rfc7030>.
[RFC8314]
Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, , <https://www.rfc-editor.org/info/rfc8314>.
[RFC8366]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, , <https://www.rfc-editor.org/info/rfc8366>.
[RFC8555]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/info/rfc8555>.
Kumari, W. and E. Kline, "Captive-Portal Identification in DHCP and Router Advertisements (RAs)", RFC 8910, DOI 10.17487/RFC8910, , <https://www.rfc-editor.org/info/rfc8910>.
[RFC8995]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, , <https://www.rfc-editor.org/info/rfc8995>.