]> Whisper Security (viaGraph B.V.)

NL kaveh@whisper.security

Security DANE DNSSEC device identity agent identity TLSA A rapidly growing set of protocols for autonomous agents, connected devices, and machine workloads bootstraps trust in an endpoint's public key over the Web PKI together with an HTTPS .well-known fetch, a bespoke certificate authority, or a centralized registry. These approaches inherit domain-takeover exposure, depend on a reachable call-home endpoint, are not verifiable across organizational boundaries, and frequently provide no timely revocation. This document describes a complementary identity model in which an endpoint's key is anchored directly in DNSSEC-signed DNS using DANE (a TLSA record), bound to a routable address whose reverse and forward names are served from a signed zone, and described by RDAP. The model, consistent with the architecture developed in the DANE Authentication for Network Clients Everywhere (DANCE) working group, lets any relying party verify an endpoint's identity from stock DNS tooling with no account or private trust root, and lets the identity's holder revoke it worldwide at DNS TTL. It is intended as an anchor that existing agent-, device-, and content-identity schemes can adopt without abandoning their own transports or object formats.

Introduction Identity for autonomous agents, connected devices, and machine workloads is being specified in many venues at once. A recurring pattern is visible across them: the identity of an endpoint, its signing or authentication key, is bootstrapped over the Web PKI and discovered through an HTTPS fetch of a .well-known resource, through a scheme-specific certificate authority, or through a centralized registry that the relying party must call at verification time. Examples include agent cards fetched over HTTPS, HTTP Message Signature key directories, content-provenance trust anchors published as a JSON Web Key Set, and per-scheme device PKIs. Each of these mechanisms works, and this document does not seek to replace any of them. For a relying party that is itself a web client, already operating inside a WebPKI-secured transaction with the origin it is verifying, discovering the key over that same web endpoint is the pragmatic choice, and anchoring it elsewhere buys little: the transaction rides on the WebPKI regardless. The limitations below bite in a different setting, one these schemes increasingly have to serve: verification that happens outside any such transaction. Examples include an agent verifying another agent, a workload authenticating across an organizational boundary, a non-HTTP protocol, or a key directory that lives in a different trust domain than the resource being accessed. There, the authority's web endpoint is a distinct trust and availability dependency, not a free side effect of a connection the verifier was making anyway. In that setting, the following limitations follow from where the key is anchored rather than from how it is used: Domain-takeover exposure. When trust in a key rests on the ability to serve an HTTPS resource under a domain, an adversary who transiently controls that domain (through a lapsed registration, a hijacked name server, or a mis-issued certificate) controls the identity. Call-home dependency and privacy. Verifying an identity by fetching a document from the subject's server reveals to the subject which relying parties are checking it, and fails when that server is unreachable. No cross-organization verifiability. Keys anchored in a private or scheme-specific root cannot be validated outside the ecosystem that operates the root; cross-organization trust requires out-of-band cross-certification. Weak or absent revocation. Several device-identity profiles issue long-lived credentials with no CRL or OCSP, leaving no timely off-switch. DNSSEC-signed DNS together with DANE addresses these at the anchor for the party positioned to use it: an operator that already controls, and can sign, the zone under which its identities live. For such an operator, DNSSEC is not an additional deployment step bolted onto identity provisioning; it is the same act, the identity and its signed anchoring record provisioned together. This document does not propose that the long tail of unsigned web origins adopt DNSSEC to participate. Where an origin is unsigned and the verifier is a web client, an HTTPS .well-known fetch remains the reasonable path. This document describes the anchor for the complementary case, operator-controlled, cross-organization, and non-transaction verification, where a key published as a TLSA record under a DNSSEC-signed name is verifiable by any party from the DNS root of trust, without contacting the subject and without a private CA; can be removed, revoking the identity, within a DNS TTL; and is verifiable across every organizational boundary because the name is part of the global DNS. This is the model the DANCE working group has developed for DNS-bound client and device identity . This document generalizes that model into an identity anchor that agent-, device-, and content-identity schemes can adopt, and describes the additional bindings (a routable address and RDAP registration metadata) that make the anchor a complete, operable identity.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses DNS terminology from .

DANE-anchored identity:

The public key of an endpoint, published as a TLSA record under a DNSSEC-signed name and thereby verifiable from the DNS root of trust.

Anchoring name:

The DNSSEC-signed domain name under which an endpoint's TLSA record is published. In this document the anchoring name is derived from a routable address assigned to the endpoint (see ).

Relying party:

Any party that verifies an endpoint's identity. A relying party needs only a validating DNS resolver; it needs no account, API key, or membership in a private trust ecosystem.

Problem Statement The mechanisms surveyed in anchor an endpoint's key in one of three places: the Web PKI plus an HTTPS .well-known document, a scheme-specific certificate authority, or a centralized registry. None of these anchors is the DNS, and so none inherits DNSSEC's properties. That is not by itself a deficiency: DNSSEC deployment is uneven, and for a verifier already inside a WebPKI transaction with a web origin, an .well-known fetch over that transaction is lower-friction than requiring the origin to sign its zone. The gap this document addresses is narrower and does not depend on universal DNSSEC. It is the case where (a) the identity operator controls the anchoring zone, so signing it is part of provisioning the identity rather than an external prerequisite, and (b) the relying party verifies outside any WebPKI-secured transaction with the subject, so the web origin's continued control and availability are a real, separate dependency. The goal of this document is to describe a single anchor that, for operators who sign their own anchoring zones, (a) is verifiable by any relying party from the DNS root of trust, (b) requires no call-home to the subject, (c) is valid across organizational boundaries, and (d) can be revoked worldwide within a DNS TTL, adoptable underneath the existing agent-, device-, and content-identity schemes without disturbing their transports or object formats. It is explicitly not a proposal to require DNSSEC of parties that do not already operate signed zones, nor a replacement for .well-known discovery in the web-client case.

DANE-Anchored Identity

Anchoring a Key to a Name An endpoint holds a key pair whose private half never leaves the endpoint. The endpoint's public key is published as a TLSA record under a DNSSEC-signed anchoring name. The RECOMMENDED TLSA usage is DANE-EE with a SubjectPublicKeyInfo selector and a SHA-256 matching type (3 1 1), which binds the identity to the key itself rather than to any issuing authority, consistent with . A relying party retrieves the TLSA record, validates the DNSSEC chain from the root, and thereby learns the endpoint's authentic public key with no dependency on the Web PKI and no fetch from the endpoint. Because the binding is to the SubjectPublicKeyInfo, an endpoint MAY present the same key it already uses at another layer (for example the key in a TLS client certificate, an application-instance certificate, or a signed object), so that adopting a DANE anchor requires no re-keying of already-deployed endpoints. This document specifies the TLSA record as the anchoring record because it is deployable today with existing DNS and DANE-aware tooling, and because the DANCE architecture already defines its use for endpoint keys. The TLSA record carries an implication of TLS use. Where the anchored key serves a non-TLS purpose, for example an HTTP message signature, a purpose-specific resource record type, or a signed identity envelope carried in a TXT record so that the record type itself asserts nothing, may be a cleaner long-term binding; this is noted as an open design question, not resolved here. The anchoring model, a DNSSEC-signed name binding a key by its SubjectPublicKeyInfo, is independent of the record type chosen to carry it.

Binding the Name to a Routable Address To make the identity reachable as well as verifiable, the anchoring name is associated with a routable address assigned to the endpoint. The address's reverse name (for IPv6, under ip6.arpa) is served from a DNSSEC-signed zone and resolves to the anchoring name, and the anchoring name resolves back to the address. The endpoint's TLSA record is published relative to this name. An address bound in this way is not a disposable label that an intermediary can rotate: it is a cryptographic fact that only the holder of the corresponding private key can stand behind, because a relying party that reaches the address can require the peer to prove possession of the DANE-anchored key. The address is chosen as the anchor because it is the one identifier actually present, unforgeably, on every packet the endpoint sends. When an endpoint egresses or opens a connection, the wire carries a source address, not a name, so a relying party can attribute and verify the peer at the moment it acts, with no out-of-band lookup and nothing to trust first. A name has to be asserted and then resolved; the address asserts itself. Binding the DNSSEC-signed anchoring name to that address carries this property into a form any relying party can verify from the DNS root of trust. This document does not mandate a particular address assignment or key-to-name derivation. It requires only that the anchoring name be DNSSEC-signed, that the TLSA record bind the endpoint's public key, and that the reverse/forward names be mutually consistent.

Registration Metadata via RDAP Contact, holder, and status metadata for the identity are published through RDAP anchored on the address. RDAP gives a relying party a standard, machine-readable way to answer "who is accountable for this identity" without a proprietary lookup service, and complements the DNS anchor with the registration-data layer that DANE alone does not carry.

Revocation at DNS TTL An identity is revoked by removing or replacing its TLSA record. Because relying parties validate against live DNS, a revocation propagates within the record's TTL, giving a global off-switch on the order of seconds to minutes rather than the lifetime of a certificate. Operators SHOULD choose TTLs that balance revocation latency against resolver load, and SHOULD treat the anchoring zone's DNSSEC key management as security-critical (see ).

Applicability The anchor described in is deliberately independent of any single application. The following schemes each define a place where an endpoint's key is asserted; each can carry, or be complemented by, a DANE-anchored identity without changing its wire format: Autonomous agents. Agent-interoperability protocols publish an "agent card" whose signature key is discovered over HTTPS; a DANE anchor lets a counterparty verify that the key belongs to the claimed domain from DNS, independent of transport TLS. The Agent Identity & Discovery convention already places an agent record in DNS TXT but does not require DANE; DANE closes that gap. Automated HTTP clients. HTTP Message Signature key directories are fetched over HTTPS only; a DANE anchor provides a DNS-rooted alternative to the .well-known directory. Connected devices and industrial assets. Device identity profiles bind a globally unique name to a certificate held by the device (for example an OPC UA ApplicationUri, an IEEE 802.1AR IDevID, or an IEEE 2030.5 LFDI); a DANE anchor makes that key-bound name publicly verifiable and revocable across the vendor/integrator/operator boundary. Network functions. In service-based architectures a function's instance identifier already appears in its certificate; anchoring it via DANE makes peer identity verifiable at trust boundaries independent of a private operator PKI. Content provenance. Content-provenance trust anchors published as an HTTPS-fetched JSON Web Key Set can instead, or additionally, be anchored in DNSSEC via DANE, removing the domain-takeover and call-home exposure the authors themselves note. In every case the DANE anchor is complementary: it changes where the key is rooted, not how the application uses it.

Relationship to Existing Work This document is consistent with, and depends on, the DANCE architecture and client-authentication work ; it can be read as a deployment-oriented generalization of that architecture to agent and content identity. It is complementary to workload-identity efforts , which define identity documents and their exchange but not a DNS anchor, and to the did:dns method , which stores decentralized-identifier data in DNS but does not mandate DNSSEC or use DANE. Where those efforts define the identity object or its exchange, this document defines the anchor beneath them.

Deployment Experience The model has been implemented and operated in production on real, registered address space. The operator announces an IPv6 space under a public Autonomous System, serves DNSSEC-signed forward and reverse zones for per-endpoint addresses, publishes DANE-EE TLSA records binding each endpoint's key, and exposes RDAP for each address. Relying parties verify identities using only dig, kdig, and curl against public resolvers, with no account. This demonstrates that the anchor is operable with existing DNS, DNSSEC, and RDAP infrastructure, and that verification is possible from unmodified client tooling. Detailed operational parameters are out of scope for this document.

Security Considerations The security of a DANE-anchored identity rests on the DNSSEC validation chain of the anchoring zone. Relying parties MUST validate DNSSEC and MUST NOT accept a TLSA record whose chain does not validate to a trusted anchor. The operator of the anchoring zone MUST protect the zone-signing and key-signing keys accordingly; compromise of those keys is equivalent to compromise of every identity anchored in the zone. Because the anchor binds an endpoint's public key rather than an issued certificate, there is no issuing-CA layer to compromise, but there is also no external party attesting to the subject's real-world identity beyond the RDAP registration data; applications that require such attestation MUST obtain it by other means and treat the DANE anchor as proof of key control, not of provenance. Revocation depends on DNS propagation; an operator cannot revoke faster than the TTL previously served. Operators SHOULD keep anchoring-record TTLs short enough that revocation is timely for their threat model. This anchor complements, and does not replace, transport-layer and application-layer authentication (for example mutual TLS or object signatures); it changes where a key is rooted, and provides a verification and revocation path, but it does not by itself authenticate individual protocol messages.

Privacy Considerations A DANE-anchored identity is, by construction, public: the anchoring name, the TLSA record, and the RDAP registration are visible to anyone. This is a deliberate trade that removes the call-home privacy problem of fetch-based discovery. Relying parties learn nothing that the subject reveals to them, and the subject learns nothing about which relying parties verify it. However, publishing a stable, enumerable identity for an endpoint enables correlation of that endpoint's activity . Deployments that assign one anchoring name per endpoint SHOULD consider whether such correlation is acceptable for their use case, and MAY rotate or scope anchoring names where it is not. RDAP registration data SHOULD be minimized to what accountability requires.

IANA Considerations This document has no IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. Valimail Salesforce Edvina.net Sandelman Software Works Inc This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. Salesforce OpenSSL Corporation The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE Client Identity, to convey the client's domain name identity to the server. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Cloudflare Google This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence.

Acknowledgments This work builds on the DANE Authentication for Network Clients Everywhere (DANCE) working group's architecture and on decades of DNSSEC, DANE, and RDAP deployment experience in the operator community. The author thanks Ben Schwartz and Eric Rescorla, whose comments sharpened the scoping of this document as a complement to, rather than a replacement for, WebPKI-based mechanisms; Wes Hardaker for guidance on where this work belongs; and Geoff Huston for a candid reading that shaped the plain-language framing. Acknowledgment here reflects review and discussion, not endorsement.