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."¶
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. Importantly, nothing here will help determine whether a network or network device is actually trustworthy, merely that it possesses a verifiable identity.¶
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.¶
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).]¶
Protected Communications:
Communications between two Devices whose Identities have been verified and use methods such as cryptography to protect any data from eavesdropping or undetected modification.¶
Secure Context:
An environment meeting the minimum standards of authentication and confidentiality as defined by the W3C Secure Contexts specification [W3C.SecureContexts].¶
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.¶
SEcure access To Tls Local rEsources (SETTLE) [SETTLE] is concerned with enabling Protected Communications within any Zero-Trust Local Area Network. Protected Communications typically are implemented using of TLS [RFC9846] with X.509 certificates [RFC5280] signed by a known Trust Anchor. Importantly, SETTLE does not deal with the notion of trustworthiness (authentication, authorization, access control, and/or attestation) or Users but instead is focused on the more basic issues of Device Identity verification and the use of a Local Certificate Authority and Trust Anchor to permit local autonomous operation without an active connection to the Internet.¶
Autonomous/Semi-Autonomous Operation: Allow Devices to connect and obtain credentials automatically whenever possible.¶
Common Connection/Policy Support:: Make it possible for Devices to better adapt and participate on LANs with different capabilities and/or policies, particularly home vs. enterprise networks.¶
Improved Security: Eliminate the use of TOFU policies for IoT Devices by using X.509 certificates that are signed by a Local Trust Anchor.¶
Improved User Experience: Enable normal HTTPS access to Devices such as cameras, printers, routers, etc. using a standard User Agent such as a web browser.¶
Standalone Operation: Do not require an Internet connection to function. Obviously there could be cloud/distributed/managed solutions but the core architecture/protocols do not require it.¶
SETTLE MUST provide a mechanism to assign unique Device Names. 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
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
Device Name resolution MUST NOT depend on the availability of global DNS infrastructure.¶
REQ-NAME-04: Standardized Discovery
SETTLE 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. SETTLE MUST NOT broadcast static identifiers (like MAC addresses or static account hashes) in plaintext if the Device is portable. SETTLE SHOULD utilize rotating identifiers or cryptographic mechanisms like Private Set Intersection (PSI).¶
SETTLE MUST NOT rely on automatic Trust On First Use (TOFU) executed exclusively over the local network interface for initial authentication.¶
REQ-VERIFY-02: Out-of-Band (OOB) Ceremony
SETTLE MUST define or profile an OOB mechanism to transfer verification entropy when a suitable Device Identity is not available. The OOB material MUST provide at least 128 bits of entropy to resist offline attacks.¶
SETTLE SHOULD support the use of manufacturer-installed certificates (e.g., IDevID [IEEE.802.1AR], [I-D.irtf-t2trg-taxonomy-manufacturer-anchors]). When used, SETTLE MUST define a mechanism (e.g., Vouchers [RFC8366]) to cryptographically bind the manufacturer-provided identity to the user-facing Device Name.¶
All communications requiring a secure context MUST utilize TLS 1.3 [RFC9846] 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
SETTLE 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
SETTLE MUST support cryptographic agility to accommodate future algorithm deprecations and ensure interoperability between independent vendor implementations.¶
SETTLE MUST operate securely without requiring Internet connectivity.¶
REQ-ARCH-02: Referee / Delegation Support
SETTLE MUST support a hierarchical local trust model where a mutually authenticated Referee can issue credentials to Devices.¶
REQ-ARCH-03: Device Lifecycle and Key Rotation
SETTLE 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.¶
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.¶
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. 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 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.¶
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>.
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.¶