



Network Working Group                                       M. F. Callec
Internet-Draft                                               Independent
Intended status: Experimental                              24 April 2026
Expires: 26 October 2026


   Domain-based Integrity Verification Enforcement (DIVE) Version 0.1
                          draft-callec-dive-01

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

   This Internet-Draft will expire on 26 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Callec                   Expires 26 October 2026                [Page 1]

Internet-Draft                    DIVE                        April 2026


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Scopes  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Standard Scopes . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Custom Scopes . . . . . . . . . . . . . . . . . . . . . .   5
   5.  DNS Configuration . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  DNSSEC Requirement  . . . . . . . . . . . . . . . . . . .   6
     5.2.  Record Format . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Policy Record (_dive) . . . . . . . . . . . . . . . . . .   6
       5.3.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   6
       5.3.2.  Parameters  . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  Key Records . . . . . . . . . . . . . . . . . . . . . . .   7
       5.4.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
       5.4.2.  Parameters  . . . . . . . . . . . . . . . . . . . . .   8
     5.5.  Subdomain-Specific Records  . . . . . . . . . . . . . . .   8
   6.  HTTP Signatures . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Signature Coverage  . . . . . . . . . . . . . . . . . . .   8
     6.2.  Key Identification and Multiple Signatures  . . . . . . .   9
       6.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Hash Algorithm Binding  . . . . . . . . . . . . . . . . .  10
   7.  Client Implementation . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Step 1: Policy Discovery  . . . . . . . . . . . . . . . .  10
     7.2.  Step 2: Scope Determination . . . . . . . . . . . . . . .  10
     7.3.  Step 3: Signature Header Validation . . . . . . . . . . .  11
     7.4.  Step 4: Key Resolution  . . . . . . . . . . . . . . . . .  11
     7.5.  Step 5: Signature Verification  . . . . . . . . . . . . .  11
     7.6.  Step 6: Reporting . . . . . . . . . . . . . . . . . . . .  12
     7.7.  Cache Management  . . . . . . . . . . . . . . . . . . . .  14
   8.  Operational Security  . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  14
     8.2.  Response to Key Compromise  . . . . . . . . . . . . . . .  14
     8.3.  Private Key Storage . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  15
     9.2.  DNSSEC as Trust Anchor  . . . . . . . . . . . . . . . . .  15
     9.3.  Algorithm Restrictions  . . . . . . . . . . . . . . . . .  16



Callec                   Expires 26 October 2026                [Page 2]

Internet-Draft                    DIVE                        April 2026


     9.4.  Cache Poisoning . . . . . . . . . . . . . . . . . . . . .  16
     9.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.6.  Scope of Protection . . . . . . . . . . . . . . . . . . .  16
     9.7.  Interaction with HTTP Caches  . . . . . . . . . . . . . .  16
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  DIVE Scope Registry  . . . . . . . . . . . . . . . . . .  16
     10.2.  DIVE Directive Registry  . . . . . . . . . . . . . . . .  17
     10.3.  Hash Algorithms for HTTP Digest Fields . . . . . . . . .  17
     10.4.  DNS Resource Record Types  . . . . . . . . . . . . . . .  18
   11. Implementation Status . . . . . . . . . . . . . . . . . . . .  18
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     12.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   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.  Subresource Integrity (SRI)
   embeds expected hashes in HTML markup, but because that markup is
   itself served by the potentially compromised host, it provides
   limited security during a full infrastructure breach.

   DIVE addresses this 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 designed for non-browser automated clients such as package
   managers, CLI tools, and software-update agents.  Browser clients
   MUST NOT implement or enforce DIVE.

   DIVE is incrementally deployable: servers add DNS records and HTTP
   signatures; clients that do not implement DIVE are unaffected.








Callec                   Expires 26 October 2026                [Page 3]

Internet-Draft                    DIVE                        April 2026


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
      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:













Callec                   Expires 26 October 2026                [Page 4]

Internet-Draft                    DIVE                        April 2026


     Origin Server                   DNS (DNSSEC)
     +---------------+               +-----------------------+
     | Body response |               | _dive TXT: policy     |
     | signed with   |               | <keyid>._divekey TXT: |
     | private key   |               |   public key, params  |
     +--------+------+               +-----------+-----------+
              |                                  |
              | 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.

4.  Scopes

   A scope identifies the category of resources to which DIVE
   verification applies.

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.







Callec                   Expires 26 October 2026                [Page 5]

Internet-Draft                    DIVE                        April 2026


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

   _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):




Callec                   Expires 26 October 2026                [Page 6]

Internet-Draft                    DIVE                        April 2026


   *  "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.

   *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




Callec                   Expires 26 October 2026                [Page 7]

Internet-Draft                    DIVE                        April 2026


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.

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





Callec                   Expires 26 October 2026                [Page 8]

Internet-Draft                    DIVE                        April 2026


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.

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.




Callec                   Expires 26 October 2026                [Page 9]

Internet-Draft                    DIVE                        April 2026


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.

   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.



Callec                   Expires 26 October 2026               [Page 10]

Internet-Draft                    DIVE                        April 2026


   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:

   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.




Callec                   Expires 26 October 2026               [Page 11]

Internet-Draft                    DIVE                        April 2026


   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.

   *  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 26 October 2026               [Page 12]

Internet-Draft                    DIVE                        April 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 26 October 2026               [Page 13]

Internet-Draft                    DIVE                        April 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 26 October 2026               [Page 14]

Internet-Draft                    DIVE                        April 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

   Operators SHOULD NOT store private signing keys on HTTP servers.
   Private keys SHOULD be stored in offline environments or within
   Hardware Security Modules (HSMs).  However, the security of the
   signing path itself MUST also be enforced: HSM access interfaces and
   any remote signing services MUST be strongly authenticated,
   authorized, rate-limited, and audited, since an attacker who cannot
   retrieve the private key material may still obtain unauthorized
   signatures by abusing or compromising a signing endpoint.  Signatures
   SHOULD be pre-computed where feasible and injected at deployment
   time.

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.

   DIVE does NOT protect against simultaneous compromise of both the DNS
   infrastructure and the origin server, or against compromise of the
   private signing keys.

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





Callec                   Expires 26 October 2026               [Page 15]

Internet-Draft                    DIVE                        April 2026


   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.

9.6.  Scope of Protection

   DIVE verifies response body integrity and authenticity.  It does not
   protect HTTP response headers other than those defined in [RFC9421]
   and [RFC9530], nor request parameters or cookies.

9.7.  Interaction with HTTP Caches

   The client MUST NOT hide, suppress, or otherwise obscure HTTP
   resources or HTTP header fields.

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 26 October 2026               [Page 16]

Internet-Draft                    DIVE                        April 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 26 October 2026               [Page 17]

Internet-Draft                    DIVE                        April 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 26 October 2026               [Page 18]

Internet-Draft                    DIVE                        April 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 26 October 2026               [Page 19]

Internet-Draft                    DIVE                        April 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.

Author's Address

   Mateo Florian Callec
   Independent
   France
   Email: mateo@callec.net





















Callec                   Expires 26 October 2026               [Page 20]
