Domain-based Integrity Verification Enforcement (DIVE) Version 0.1
draft-callec-dive-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Mateo Florian Callec | ||
| Last updated | 2026-06-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Organization
GitHub Repository Additional Web Page |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-callec-dive-02
Network Working Group M. F. Callec
Internet-Draft Independent
Intended status: Experimental 16 June 2026
Expires: 18 December 2026
Domain-based Integrity Verification Enforcement (DIVE) Version 0.1
draft-callec-dive-02
Abstract
Domain-based Integrity Verification Enforcement (DIVE) is an
application-layer protocol that provides cryptographic integrity and
authenticity verification of HTTP response bodies by leveraging the
Domain Name System Security Extensions (DNSSEC) as an out-of-band
distribution channel for public keys.
DIVE is designed for non-browser automated clients operating in
controlled infrastructure: software update agents, package managers,
and IoT device fleets. It is specifically suited to the distribution
of static, pre-signable content (firmware images, packages, and
versioned binary artifacts), where signatures can be computed offline
and injected at deployment time.
DIVE has two independent components: (1) an object-security layer,
which uses HTTP Message Signatures (RFC 9421) to carry per-resource
signatures in HTTP response headers, and (2) a DNS key-distribution
layer, which publishes public keys and policy in DNSSEC-protected TXT
records. A client implementing DIVE verifies each covered resource
against the corresponding DNS-published public key before accepting
it. An attacker must therefore compromise both the DNS
infrastructure and the origin server simultaneously to deliver a
tampered resource to a DIVE-compliant client.
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 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."
Callec Expires 18 December 2026 [Page 1]
Internet-Draft DIVE June 2026
This Internet-Draft will expire on 18 December 2026.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Design . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Standard Scopes . . . . . . . . . . . . . . . . . . . . . 7
4.2. Custom Scopes . . . . . . . . . . . . . . . . . . . . . . 7
5. DNS Configuration . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DNSSEC Requirement . . . . . . . . . . . . . . . . . . . 7
5.2. Record Format . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Policy Record (_dive) . . . . . . . . . . . . . . . . . . 7
5.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.2. Parameters . . . . . . . . . . . . . . . . . . . . . 8
5.4. Key Records . . . . . . . . . . . . . . . . . . . . . . . 9
5.4.1. Example . . . . . . . . . . . . . . . . . . . . . . . 9
5.4.2. Parameters . . . . . . . . . . . . . . . . . . . . . 9
5.5. Subdomain-Specific Records . . . . . . . . . . . . . . . 10
6. HTTP Signatures . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Signature Coverage . . . . . . . . . . . . . . . . . . . 10
6.2. Key Identification and Multiple Signatures . . . . . . . 10
6.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Hash Algorithm Binding . . . . . . . . . . . . . . . . . 11
7. Client Implementation . . . . . . . . . . . . . . . . . . . . 11
7.1. Step 1: Policy Discovery . . . . . . . . . . . . . . . . 11
7.2. Step 2: Scope Determination . . . . . . . . . . . . . . . 12
7.3. Step 3: Signature Header Validation . . . . . . . . . . . 12
7.4. Step 4: Key Resolution . . . . . . . . . . . . . . . . . 12
7.5. Step 5: Signature Verification . . . . . . . . . . . . . 13
Callec Expires 18 December 2026 [Page 2]
Internet-Draft DIVE June 2026
7.6. Step 6: Reporting . . . . . . . . . . . . . . . . . . . . 14
7.7. Cache Management . . . . . . . . . . . . . . . . . . . . 16
8. Operational Security . . . . . . . . . . . . . . . . . . . . 16
8.1. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Response to Key Compromise . . . . . . . . . . . . . . . 16
8.3. Private Key Storage . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17
9.2. DNSSEC as Trust Anchor . . . . . . . . . . . . . . . . . 18
9.3. Algorithm Restrictions . . . . . . . . . . . . . . . . . 18
9.4. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 18
9.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.6. Scope of Protection . . . . . . . . . . . . . . . . . . . 19
9.7. Interaction with HTTP Caches . . . . . . . . . . . . . . 19
9.8. Relationship to WebPKI . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. DIVE Scope Registry . . . . . . . . . . . . . . . . . . 19
10.2. DIVE Directive Registry . . . . . . . . . . . . . . . . 20
10.3. Hash Algorithms for HTTP Digest Fields . . . . . . . . . 20
10.4. DNS Resource Record Types . . . . . . . . . . . . . . . 21
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
1.1. Problem Statement
Transport-layer security protects data in transit but does not
protect against a compromised origin server that serves malicious
content over a legitimate TLS session.
For automated clients distributing static artifacts such as firmware
images, packages, and binaries, the dominant mitigations are:
1. *Embedded trust anchors*: the client ships with a public key
baked in, and verifies a signature over each downloaded artifact.
This works but creates a circular dependency: rotating a
compromised key requires pushing an update to all deployed
clients through the very update mechanism whose trust anchor is
now compromised. In IoT environments, where devices may be
deployed for years with infrequent or unreliable update cycles,
this is a critical operational risk.
Callec Expires 18 December 2026 [Page 3]
Internet-Draft DIVE June 2026
2. *CA-based signing*: an operator uses a Certificate Authority to
sign distributed artifacts, either by running their own private
CA or by obtaining a code-signing certificate from a publicly
recognised CA. This addresses the key-rotation problem for
operators with sufficient security infrastructure, but introduces
a dependency on a third party that the operator does not fully
control. A private CA requires significant operational
sophistication that is not realistic for smaller manufacturers or
resource-constrained organisations. A publicly recognised CA,
while operationally simpler, introduces both an external trust
dependency and additional operational costs: a CA that is
compromised or coerced can issue a fraudulent certificate that is
indistinguishable from a legitimate one to the client.
In practice, the operational complexity and cost of both approaches
lead smaller manufacturers and resource-constrained organisations to
deploy no artifact integrity verification at all. DIVE is designed
to address this gap by providing a lightweight, incrementally
deployable mechanism that does not require dedicated security
infrastructure or dependency on a third-party CA.
DIVE offers a third path: integrity verification is decoupled from
both the server and the client by anchoring it in the DNS. Public
keys are published as DNS resource records secured by DNSSEC, giving
operators a revocation mechanism as simple and fast as updating a DNS
record, with no changes required to deployed clients and no
dependency on a third-party CA.
1.2. Scope
DIVE is designed exclusively for static, pre-signable content:
firmware images, packages, archives, and versioned binary artifacts.
The requirement that private signing keys be stored offline
(Section 8.3) is a deliberate design choice, not an operational
inconvenience: keeping a signing key off the origin server eliminates
the risk of that key being compromised through the origin server
itself. This constraint limits DIVE to content whose signatures can
be computed before deployment and injected into the serving
infrastructure at distribution time.
DIVE is not designed for dynamically generated HTTP responses.
Operators serving mixed static and dynamic content MUST NOT apply
DIVE verification to dynamic resources.
Callec Expires 18 December 2026 [Page 4]
Internet-Draft DIVE June 2026
DIVE is designed for non-browser automated clients such as software
update agents and CLI tools operating in controlled infrastructure
environments, including enterprise networks, IoT device fleets, and
managed update pipelines. Browser clients MUST NOT implement or
enforce DIVE.
1.3. Design
DIVE addresses the above threat by separating two concerns:
* *Object security*: HTTP Message Signatures [RFC9421] carry a
cryptographic signature over the response body. The signature
travels with the resource and can be verified at any point after
receipt.
* *Key distribution*: DNSSEC-protected DNS TXT records publish the
authoritative public keys and policy. Because DNS is administered
independently from the origin server, an attacker who controls
only the origin cannot forge a valid DNS-published key.
DIVE is incrementally deployable: servers add DNS records and HTTP
signatures; clients that do not implement DIVE are unaffected.
2. Terminology
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
DIVE client: An HTTP client that implements the verification
algorithm defined in this document.
DIVE server: An HTTP origin server that publishes DIVE DNS records
and includes DIVE-conformant HTTP Message Signatures on covered
resources.
Resource: A single HTTP response body received with status code 200.
Scope: A named category of resources subject to DIVE verification
(Section 4).
Key ID: An operator-assigned label that names a specific DNS key
record and is referenced in HTTP Message Signatures via the keyid
parameter ([RFC9421] Section 2.3).
Policy record: The _dive DNS TXT record that publishes the DIVE
Callec Expires 18 December 2026 [Page 5]
Internet-Draft DIVE June 2026
configuration for a domain (Section 5.3).
Key record: A DNS TXT record that publishes a public key, placed at
<Key-ID>._divekey.<domain> (Section 5.4).
Structured Field: A value encoded per [RFC9651].
Unix timestamp: Seconds since 1970-01-01T00:00:00Z (UTC), excluding
leap seconds, as a signed integer.
3. Architecture
DIVE separates object security from key distribution:
Origin Server DNS (DNSSEC)
+---------------+ +-----------------------+
| Body response | | _dive TXT: policy |
| signed with | | <keyid>._divekey TXT: |
| private key | | public key, params |
| (offline) | | |
+--------+------+ +-----------+-----------+
| |
| HTTP response | DNS/DNSSEC query
| (Signature: header) |
v v
+--------+----------------------------------+-----------+
| DIVE Client |
| 1. Discover policy via _dive DNS record |
| 2. Determine resource scope |
| 3. Resolve public key from _divekey DNS record |
| 4. Verify HTTP Message Signature over response body |
+-------------------------------------------------------+
Figure 1: DIVE Architecture and Verification Flow
The Signature and Signature-Input headers are defined by [RFC9421].
The DNS records are defined by this document. The private signing
key is held offline and never deployed to the origin server;
signatures are pre-computed and injected at distribution time
(Section 8.3).
4. Scopes
A scope identifies the category of resources to which DIVE
verification applies.
Callec Expires 18 December 2026 [Page 6]
Internet-Draft DIVE June 2026
4.1. Standard Scopes
strict: DIVE verification MUST be applied to ALL resources served
under the domain covered by the policy record.
4.2. Custom Scopes
Operators MAY define custom scopes for application-specific resource
categories. Custom scope names MUST begin with x-, be entirely
lowercase, and contain only a-z and - after the prefix.
Custom scopes are intended for closed environments where server and
client are under the same operator's control. Detection logic for
custom scopes is application-defined.
A DIVE client that does not recognise a custom scope MUST ignore it.
5. DNS Configuration
5.1. DNSSEC Requirement
A DIVE server SHOULD enable DNSSEC [RFC4033] for all zones publishing
DIVE records. If a client retrieves a _dive record without DNSSEC
validation, it MUST treat DIVE as not supported for that domain.
5.2. Record Format
All DIVE DNS records are DNS TXT records. Values MUST be formatted
as Structured Field Values [RFC9651]. Parameter names and values
MUST be lowercase unless otherwise stated. Timestamps are Unix
timestamps represented as Structured Field Integers.
5.3. Policy Record (_dive)
The _dive TXT record is placed at the _dive label of the domain or
subdomain it governs (e.g., _dive.example.com). A record at a given
level applies to all subordinate labels unless overridden by a more
specific record.
5.3.1. Example
Callec Expires 18 December 2026 [Page 7]
Internet-Draft DIVE June 2026
_dive.example.com. 300 IN TXT (
"v=\"dive-draft-01\", "
"scopes=(\"strict\"), "
"directives=(\"https-required\"), "
"cache=300, "
"invalidate-keys-cache=1700000000, "
"report-to=\"https://reports.example.com/dive\""
)
Figure 2: Example of a DIVE Policy Record
5.3.2. Parameters
v (REQUIRED): Protocol version string. MUST be "dive-draft-01". If
absent, unrecognised, or unparseable, the client MUST treat DIVE
as not supported for this domain.
scopes (OPTIONAL): Structured Field List of scope names (Strings).
If absent or empty, no resource-level verification is performed,
though other directives still apply.
directives (OPTIONAL): Structured Field List of behavioural
directives (Strings):
* "https-required": the client MUST refuse or upgrade plain-HTTP
requests for resources under the covered domain.
* "report-only": the client MUST NOT block resources that fail DIVE
verification; it MUST report failures per Section 7.6 instead.
Unrecognised directive values MUST be ignored.
cache (OPTIONAL): Structured Field Integer. Number of seconds the
client MAY cache this record (default: 0). MUST NOT exceed 3600
(Section 7.7).
invalidate-keys-cache (OPTIONAL): Structured Field Integer (Unix
timestamp). When present, the client MUST purge cached key
records for the domain stored at or before this timestamp. If the
timestamp is in the future, the client MUST issue a fresh DNS
query on each verification attempt until the timestamp has passed.
report-to (OPTIONAL): Structured Field String. An absolute HTTPS
URL to which failure reports MUST be sent (Section 7.6). Plain
HTTP URLs MUST be ignored.
Unrecognised parameters MUST be ignored.
Callec Expires 18 December 2026 [Page 8]
Internet-Draft DIVE June 2026
*Operational note:* Operators SHOULD set the DNS TTL of _dive records
to 300 seconds.
5.4. Key Records
When one or more scopes are declared, at least one key record MUST be
present and valid. If no valid key record is reachable, the client
MUST refuse all resources in the declared scopes.
Key records are DNS TXT records at <Key-ID>._divekey.<domain>. A Key
ID MAY contain A-Z, a-z, 0-9, and _; it MUST NOT contain other
characters; it is case-sensitive.
5.4.1. Example
keyABC._divekey.example.com. 900 IN TXT (
"sig=\"ed25519\", "
"key=:BASE64RAWKEY:, "
"allowed-hash=(\"sha256\" \"sha384\" \"sha3-256\"), "
"cache=900"
)
Figure 3: Example of a DIVE Key Record
5.4.2. Parameters
sig (REQUIRED): Signature algorithm. MUST be one of "ed25519"
([RFC8032] Section 5.1) or "ed448" ([RFC8032] Section 5.2). All
other algorithms MUST be rejected.
key (REQUIRED): Structured Field Byte Sequence containing the raw
public key bytes for the declared algorithm (32 bytes for Ed25519,
57 bytes for Ed448).
allowed-hash (OPTIONAL): Structured Field List of permitted hash
algorithms (Strings). Permitted values: "sha256", "sha384",
"sha512", "sha3-256", "sha3-384", "sha3-512". MD5, CRC32, and
SHA-1 MUST NOT be listed and MUST be rejected. When present, the
hash algorithm used in the corresponding signature MUST appear in
this list; otherwise verification MUST be treated as failed.
cache (OPTIONAL): Structured Field Integer. Number of seconds the
client MAY cache this record (default: 0). MUST NOT exceed 86400
(Section 7.7).
Unrecognised parameters MUST be ignored.
Callec Expires 18 December 2026 [Page 9]
Internet-Draft DIVE June 2026
*Operational note:* Operators SHOULD set the DNS TTL of key records
to 900 seconds and SHOULD perform regular key rotation (Section 8.1).
A Key ID SHOULD NOT be reused after its associated record has been
removed.
5.5. Subdomain-Specific Records
Operators MAY publish policy and key records at any subdomain level.
The most specific matching record takes precedence.
6. HTTP Signatures
DIVE uses HTTP Message Signatures [RFC9421] to carry per-resource
signatures. A DIVE server MUST include Signature and Signature-Input
response headers on all 200 responses for resources within a declared
scope.
6.1. Signature Coverage
Each DIVE signature MUST cover the content-digest derived component
([RFC9421] Section 2.4), which commits the signature to the response
body. Servers MUST include a Content-Digest header [RFC9530] in each
covered response.
6.2. Key Identification and Multiple Signatures
The keyid parameter in Signature-Input MUST be set to the Key ID of
the DNS key record used to create the signature. The alg parameter
MUST be set to "ed25519" or "ed448" as appropriate.
To support key rotation (Section 8.1), a server MAY include multiple
signatures in a single response by providing multiple Signature and
Signature-Input entries ([RFC9421] Section 4.2), each referencing a
different Key ID.
A DIVE client MUST attempt verification using the available signature
entries in order. The client MUST NOT assume prior knowledge of key
ordering semantics beyond the order provided in the response. If the
client has previously cached a public key matching a given keyid, it
SHOULD prefer using the cached key for verification of the
corresponding signature entry. Otherwise, the client MUST use the
first available signature entry, and proceed to the next entry only
if verification fails. The resource MUST be accepted as soon as one
verification succeeds.
Callec Expires 18 December 2026 [Page 10]
Internet-Draft DIVE June 2026
6.2.1. Example
The following example illustrates two concurrent signatures for key
rotation. keyDEF is the newly introduced signing key being rolled in,
while keyABC is the previously active key.
Content-Digest: sha-256=:BASE64DIGEST:
Signature-Input: sigDEF=("content-digest");keyid="keyDEF"; \
alg="ed25519", \
sigABC=("content-digest");keyid="keyABC"; \
alg="ed25519"
Signature: sigDEF=:BASE64SIG2:, \
sigABC=:BASE64SIG1:
Figure 4: Example of Concurrent Signatures for Key Rotation
Clients that have already cached keyDEF will verify using sigDEF
directly. Clients that have not cached any key will attempt
verification starting with the first signature entry (sigDEF), and
will fall back to sigABC if needed. Clients that have cached keyABC
MAY directly use sigABC for verification, but MUST still follow the
ordered fallback behavior if verification fails.
The list of signatures SHOULD contain no more than three entries to
maintain compatibility with HTTP implementations that impose header-
length limits.
6.3. Hash Algorithm Binding
The hash algorithm used to compute Content-Digest MUST be consistent
with the allowed-hash parameter of the key record (Section 5.4), when
that parameter is present.
Permitted hash algorithms for Content-Digest: sha-256, sha-384, sha-
512, sha3-256, sha3-384, sha3-512. MD5, CRC32, and SHA-1 MUST NOT be
used and MUST be rejected by the client.
7. Client Implementation
7.1. Step 1: Policy Discovery
The client MUST locate the applicable _dive TXT record by querying
from the resource's full FQDN upward, one label at a time, until a
record is found or no labels remain. The most specific (deepest)
record found applies.
If no record is found, DIVE is not supported.
Callec Expires 18 December 2026 [Page 11]
Internet-Draft DIVE June 2026
If the policy record was retrieved without DNSSEC validation, the
client MUST treat DIVE as not supported.
If a valid cached copy of the policy record has not expired, the
client MUST use it.
Upon retrieving the record, the client MUST verify the v parameter
and parsability. It MUST apply invalidate-keys-cache and the https-
required directive as specified in Section 5.3. It MUST cache the
record per the cache parameter, subject to the 3600-second cap.
DIVE verification is based on the resource's own origin. If a
resource is fetched from a third-party domain, the client MUST look
up that domain's _dive record, not the referring domain's.
If DIVE is not supported, the client MAY choose to block the resource
based on its own requirements.
7.2. Step 2: Scope Determination
If scopes is absent or empty, no resource-level verification is
performed. Other directives (e.g., https-required) still apply.
If the resource falls within at least one declared scope, proceed to
Step 3. Standard scope detection:
* strict: all resources under the covered domain are in scope.
Custom scope detection is application-defined.
7.3. Step 3: Signature Header Validation
The client MUST verify that Signature and Signature-Input headers are
present and syntactically conformant per [RFC9421]. If either header
is absent or invalid, the client MUST refuse the resource.
The client MUST also verify that a Content-Digest header is present
and parseable per [RFC9530].
7.4. Step 4: Key Resolution
For each signature entry in Signature-Input, the client resolves the
key record as follows:
Callec Expires 18 December 2026 [Page 12]
Internet-Draft DIVE June 2026
If keyid contains an @-qualified FQDN (e.g., keyABC@example.com), the
client MUST verify that the specified FQDN is equal to or a parent of
the resource's origin FQDN. If not, the entry MUST be treated as
invalid. The client MUST query exactly <Key-ID>._divekey.<fqdn> and
MUST NOT search at levels above the specified FQDN.
Otherwise, the client queries from the resource's FQDN upward, label
by label, stopping at the level of the applicable policy record,
querying <Key-ID>._divekey.<level> at each step. The first record
found is used.
In all cases, the DNS query MUST be DNSSEC-validated. A record
retrieved without DNSSEC validation MUST be treated as absent.
If no key record is found after cache eviction and a fresh DNS query,
the Key ID is unresolvable and verification fails for that entry.
The client MUST cache a valid key record per its cache parameter,
subject to the 86400-second cap and any invalidate-keys-cache
constraint.
7.5. Step 5: Signature Verification
For each signature entry, the client MUST:
1. Recompute the Content-Digest over the received response body
using the hash algorithm declared in the Content-Digest header
and verify it matches.
2. Reconstruct the signature base as defined by [RFC9421]
Section 2.5 from the Signature-Input components.
3. Retrieve the public key from the resolved key record.
4. If allowed-hash is present in the key record, verify the hash
algorithm in Content-Digest is listed; if not, fail this entry.
5. Verify the decoded signature over the signature base using the
algorithm declared in sig of the key record.
If at least one entry verifies successfully, the resource MUST be
accepted.
If all entries fail:
* By default, the resource MUST be rejected.
* If report-to is present, a report MUST be sent per Section 7.6.
Callec Expires 18 December 2026 [Page 13]
Internet-Draft DIVE June 2026
* If report-only is present, the resource MUST be accepted.
The client MUST NOT act upon the resource body before completing
verification. The body MAY be downloaded concurrently with DNS
resolution, but MUST NOT be delivered to the application until
verification is complete.
7.6. Step 6: Reporting
When a resource fails verification (whether blocked or allowed under
report-only), and report-to is set, the client MUST POST to that URL
with Content-Type: application/json:
Callec Expires 18 December 2026 [Page 14]
Internet-Draft DIVE June 2026
{
"report-version": "0.1",
"timestamp": 1700000000,
"client": {
"user-agent": "ExampleClient/1.0"
},
"policy": {
"domain": "example.com",
"fqdn": "sub.example.com",
"dnssec-validated": true
},
"resource": {
"url": "https://sub.example.com/downloads/invalid.zip",
"method": "GET",
"status-code": 200,
"scope": "strict"
},
"headers-received": {
"signature-input":
"sig1=(\"content-digest\");keyid=\"keyABC\";alg=\"ed25519\"",
"signature": "sig1=:BASE64SIG:",
"content-digest": "sha-256=:BASE64DIGEST:"
},
"key-resolution": [
{
"key-id": "keyABC",
"fqdn-queried": "keyABC._divekey.sub.example.com",
"found": true,
"dnssec-validated": true,
"sig-algorithm": "ed25519"
}
],
"validation": {
"hash-algorithm": "sha-256",
"hash-computed": "BASE64HASHVALUE",
"signature-valid": false,
"failure-reason": "signature-mismatch",
"final-decision": "blocked"
}
}
Figure 5: Example of a DIVE Issue Report
Fields that are absent or not applicable MUST be set to JSON null.
failure-reason permitted values: "missing-headers", "key-not-found",
"key-invalid", "dnssec-unavailable", "hash-algorithm-not-allowed",
"signature-mismatch", "no-valid-key".
Callec Expires 18 December 2026 [Page 15]
Internet-Draft DIVE June 2026
final-decision permitted values: "blocked", "allowed-report-only".
Failure to deliver a report MUST NOT affect the resource acceptance
decision.
7.7. Cache Management
Clients MUST enforce an absolute maximum cache duration of 3600
seconds for all _dive records and 86400 seconds for all _divekey
records, regardless of the cache parameter. When a key record cannot
be resolved, the client MUST evict any cached entry and issue a fresh
DNS query before failing.
8. Operational Security
8.1. Key Rotation
To rotate a signing key without service disruption:
1. Generate a new key pair and publish the new public key under a
new Key ID in DNS.
2. Wait for the new key record to propagate throughout the DNS.
3. Begin including both the old and new signatures in HTTP responses
(using multiple Signature entries per Section 6).
4. Once the new signature has been successfully validated across all
resources (ensuring no service disruption), remove the old
signature from HTTP responses.
5. Remove the old key record from DNS.
Key IDs MUST NOT be reused after their associated key records have
been removed from DNS.
8.2. Response to Key Compromise
Upon discovering a compromised private key, the operator MUST:
1. Immediately begin key rotation (Section 8.1).
2. Set invalidate-keys-cache in all applicable _dive policy records
to a timestamp at or after the time of compromise.
3. Remove the compromised key record from DNS as soon as the new key
is operational.
Callec Expires 18 December 2026 [Page 16]
Internet-Draft DIVE June 2026
4. Maintain the invalidate-keys-cache directive for at least 86400
seconds to ensure all clients have flushed the compromised key,
then remove it from the policy record to restore normal caching
behavior.
Operators MUST NOT set report-only as a temporary measure during key
compromise remediation.
8.3. Private Key Storage
Private signing keys MUST NOT be stored on origin servers. They MUST
be kept in offline environments or within Hardware Security Modules
(HSMs). This requirement is fundamental to DIVE's security model:
the protocol assumes that the signing key is never present on the
system serving the content. As a result, compromise of an origin
server alone does not enable an attacker to obtain the private key or
generate signatures that a DIVE client will accept.
This design constrains DIVE to content whose signatures can be
generated prior to deployment. Accordingly, DIVE is intended for
static, pre-signable artifacts such as firmware images, software
packages, archives, and other versioned binary resources.
Dynamically generated responses cannot be signed offline and are
therefore outside the scope of this protocol.
Where HSMs or remote signing services are used, access to signing
operations MUST be strongly authenticated, authorized, rate-limited,
and audited. Although such systems prevent extraction of private key
material, an attacker may still obtain unauthorized signatures by
abusing a signing interface. Wherever practical, signatures SHOULD
be pre-computed and embedded during deployment rather than generated
on demand.
9. Security Considerations
9.1. Threat Model
DIVE protects against an attacker who has compromised the origin web
server but not the DNS infrastructure. Such an attacker cannot
publish a forged DNSSEC-validated key record, so a DIVE-compliant
client will reject any response not signed with a DNS-published key.
Because private signing keys are stored offline and never deployed to
the origin server, a server compromise does not expose the signing
material needed to forge a valid signature.
Callec Expires 18 December 2026 [Page 17]
Internet-Draft DIVE June 2026
DIVE does NOT protect against simultaneous compromise of both the DNS
infrastructure and the origin server, compromise of the private
signing keys or the signing pipeline itself, or failure of the
underlying cryptographic assumptions on which the signature scheme
relies.
9.2. DNSSEC as Trust Anchor
DNSSEC is the root of trust for DIVE. Clients MUST obtain DNSSEC
validation status for all DNS records they retrieve. Two models are
recognised:
* *Stub validator* (RECOMMENDED): the client performs DNSSEC
verification itself.
* *Validating resolver*: the client trusts the AD bit from a
resolver. The connection to the resolver MUST be over DoH
[RFC8484] or DoT [RFC7858].
A record for which DNSSEC validation cannot be confirmed MUST be
treated as absent.
9.3. Algorithm Restrictions
Only Ed25519 and Ed448 are permitted for signing. Only SHA-256, SHA-
384, SHA-512, SHA3-256, SHA3-384, and SHA3-512 are permitted for
hashing. Clients MUST reject records or responses referencing any
other algorithm. This prevents downgrade attacks.
9.4. Cache Poisoning
Enforcing bounded cache lifetimes for _dive and _divekey records
limits the impact of cache-poisoning attacks in which a malicious
record with an artificially long cache value is injected. DNSSEC
substantially mitigates this attack.
9.5. Privacy
DNS queries for _dive and _divekey records may reveal resource-access
patterns to the resolver. Clients SHOULD use DoH or DoT.
Failure reports sent to report-to include the resource URL and User-
Agent. Operators MUST handle report data in accordance with
applicable privacy regulations.
Callec Expires 18 December 2026 [Page 18]
Internet-Draft DIVE June 2026
9.6. Scope of Protection
DIVE verifies response body integrity and authenticity for static,
pre-signed artifacts. It does not protect HTTP response headers
other than those defined in [RFC9421] and [RFC9530], nor request
parameters or cookies. It does not apply to dynamically generated
content.
9.7. Interaction with HTTP Caches
The client MUST NOT hide, suppress, or otherwise obscure HTTP
resources or HTTP header fields.
9.8. Relationship to WebPKI
WebPKI certificates bind a key to a domain name and guarantee
transport-channel integrity, but make no assertion about the content
delivered over that channel. A valid TLS certificate does not attest
that the artifact served is legitimate; it only attests that the
connection reaches the expected server. DIVE operates at the content
layer: it binds the artifact itself to a key that the origin server
does not hold, providing integrity guarantees that remain valid even
if the origin server is fully compromised.
More broadly, any CA-based signing scheme introduces a third-party
trust dependency. A CA that is compromised or coerced can issue a
fraudulent code-signing certificate that is indistinguishable from a
legitimate one to the client. DIVE has no such intermediary: the
only authoritative source for the public key is the operator's own
DNS zone, under their direct control.
10. IANA Considerations
10.1. DIVE Scope Registry
IANA is requested to create the registry "DIVE Scope Names" under a
new registry group "Domain-based Integrity Verification Enforcement
(DIVE)", with policy "Specification Required" [RFC8126].
Initial contents:
Callec Expires 18 December 2026 [Page 19]
Internet-Draft DIVE June 2026
+============+====================+=====================+===========+
| Scope Name | Description | Detection | Reference |
| | | Criterion | |
+============+====================+=====================+===========+
| strict | All resources in | Applies to all | This |
| | the covered domain | resources. | document |
+------------+--------------------+---------------------+-----------+
Table 1: Initial Contents of the DIVE Scope Names Registry
Custom scopes using the x- prefix are not subject to IANA
registration.
10.2. DIVE Directive Registry
IANA is requested to create the registry "DIVE Directive Names" under
the same registry group, with policy "Specification Required"
[RFC8126].
Initial contents:
+================+==================================+===========+
| Directive Name | Description | Reference |
+================+==================================+===========+
| https-required | Client MUST NOT issue plain-HTTP | This |
| | requests; MUST upgrade or abort. | document |
+----------------+----------------------------------+-----------+
| report-only | Client MUST NOT block failures; | This |
| | MUST report them instead. | document |
+----------------+----------------------------------+-----------+
Table 2: Initial Contents of the DIVE Directive Names Registry
10.3. Hash Algorithms for HTTP Digest Fields
DIVE requires hash algorithms beyond those currently registered in
the IANA "Hash Algorithms for HTTP Digest Fields" registry [RFC9530].
IANA is requested to add the following entries to that registry:
Callec Expires 18 December 2026 [Page 20]
Internet-Draft DIVE June 2026
+==========+========+=============+===========+
| Key | Status | Description | Reference |
+==========+========+=============+===========+
| sha-384 | Active | SHA-384 | [RFC6234] |
+----------+--------+-------------+-----------+
| sha3-256 | Active | SHA3-256 | [FIPS202] |
+----------+--------+-------------+-----------+
| sha3-384 | Active | SHA3-384 | [FIPS202] |
+----------+--------+-------------+-----------+
| sha3-512 | Active | SHA3-512 | [FIPS202] |
+----------+--------+-------------+-----------+
Table 3: Additions to the Hash Algorithms
for HTTP Digest Fields Registry
These algorithms are required to satisfy the cryptographic posture
mandated by CNSA Suite 2.0 [CNSA2] and to provide algorithm diversity
between the SHA-2 and SHA-3 families, ensuring continued integrity
guarantees in the event of a weakness discovered in either family.
SHA-384 provides a stronger security margin than SHA-256 within the
SHA-2 family at acceptable performance cost. The SHA-3 family
(Keccak) has an entirely different internal construction from SHA-2,
meaning a structural break in one family does not compromise the
other. For high-assurance environments, the ability to mandate SHA-3
exclusively via the allowed-hash key record parameter is a deliberate
design goal of DIVE.
MD5, CRC32, and SHA-1 MUST NOT be registered or used within DIVE.
10.4. DNS Resource Record Types
No new DNS resource record types are defined. DIVE uses DNS TXT
records (type 16) [RFC1035].
11. Implementation Status
An experimental implementation of the DIVE protocol is available:
* OpenDIVE Client: https://github.com/diveprotocol/opendive-client
(https://github.com/diveprotocol/opendive-client)
* Protocol information: https://diveprotocol.org
(https://diveprotocol.org)
12. References
12.1. Normative References
Callec Expires 18 December 2026 [Page 21]
Internet-Draft DIVE June 2026
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
12.2. Informative References
Callec Expires 18 December 2026 [Page 22]
Internet-Draft DIVE June 2026
[FIPS202] National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", DOI 10.6028/NIST.FIPS.202, August 2015,
<https://doi.org/10.6028/NIST.FIPS.202>.
[CNSA2] National Security Agency, "Commercial National Security
Algorithm Suite 2.0", September 2022,
<https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/
CSA_CNSA_2.0_ALGORITHMS.PDF>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
Acknowledgements
The author would like to thank Benjamin Schwartz for his review and
constructive feedback on earlier versions of this document, Eric
Rescorla for his thorough review and identification of framing issues
in draft-callec-dive-01, and S. Kishore for his careful reading and
feedback on the static content scope of the protocol.
Author's Address
Mateo Florian Callec
Independent
France
Email: mateo@callec.net
Callec Expires 18 December 2026 [Page 23]