Lakeside Robotics Corporation

Canada msweet@lakesiderobotics.ca

mail@backkem.me

Internet SETTLE REQUIREMENTS TLS LOCAL 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.

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" 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 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 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 that provides Cryptographic Identities that are signed by one or more Trust Anchors for the purpose of establishing trust .

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 .

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

Local Certificate Authority:

A Certificate Authority for the local network.

Local Trust Anchor:

A Trust Anchor for the local network.

Origin Server:

A program that can originate authoritative responses for a given target resource , 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 .

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 , e.g., a web browser.

SEcure access To Tls Local rEsources (SETTLE) is concerned with enabling Protected Communications within any Zero-Trust Local Area Network. Protected Communications typically are implemented using of TLS with X.509 certificates 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. The goals of SETTLE include:

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

REQ-NAME-01: Unique Identifiers

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 or public key hashes .

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 , "home.arpa." for unicast DNS , or ".alt" .

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) or Captive Portal APIs , 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).

REQ-VERIFY-01: Rejection of Network TOFU

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.

REQ-VERIFY-03: Pre-Installed Identity Optimization

SETTLE SHOULD support the use of manufacturer-installed certificates (e.g., IDevID , ). When used, SETTLE MUST define a mechanism (e.g., Vouchers ) to cryptographically bind the manufacturer-provided identity to the user-facing Device Name.

REQ-VERIFY-04: Dynamic Local Trust Store

User Agents MUST support a Local Trust Anchor.

REQ-TRANS-01: Modern Transport Security

All communications requiring a secure context MUST utilize TLS 1.3 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) .

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 and IoT TLS profiles .

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.

REQ-ARCH-01: Standalone Operation

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 , 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) or similar cryptographic techniques for discovery.

This document has no IANA actions.

Wi-Fi Alliance IEEE Connectivity Standards Alliance IETF W3C

The SETTLE architecture builds upon and differentiates itself from several existing approaches:

• BRSKI and BRSKI-PRM: Bootstrapping Remote Secure Key Infrastructure automates provisioning using manufacturer IDevIDs. 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) 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 . 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 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 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 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) demonstrates that privacy-preserving mutual discovery is feasible with sub-second latency.
• SDSI/SPKI: Simple Distributed Security Infrastructure proposed a decentralized PKI binding authorizations directly to keys. While conceptually aligned with local trust, modern web browsers mandate X.509 for compatibility.
• Local Public Key Hashes: Approaches that embed public key hashes into local domain names offer self-certifying namespaces but sacrifice human-readability.
• Local Referees and ACME: Architectures utilizing a central local hub to authenticate servers or issue certificates via a local ACME server optimize UX but require initial bootstrapping of the Referee itself.

[ RFC Editor: This section to be deleted before RFC publication ] September 29, 2026 - draft-ietf-settle-requirements-00

• Initial revision.