New I-D: draft-callec-dive-01

Hi everyone,





I have submitted a new version of my individual Internet-Draft: "Domain-based Integrity Verification Enforcement (DIVE)" (draft-callec-dive-01).



I previously presented this proposal to the DNSOP Working Group and received valuable feedback, which I have integrated into this latest version of the draft. Based on those discussions, it was suggested that I bring this work to HTTPBIS, as the protocol is primarily built upon HTTP.



- Draft link: https://datatracker.ietf.org/doc/draft-callec-dive/ 

- Reference Implementation: https://github.com/diveprotocol/opendive-client 



---



1. Abstract & Problem Statement



DIVE is a protocol designed to ensure resource integrity by using the DNS as a secondary out-of-band source of trust.



While existing solutions (like PGP-signed repositories or specific package manager keys) work, they often face challenges regarding key revocation, rotation, and distribution. If an attacker gains full access to a web server’s infrastructure, they can often serve malicious files along with updated (but compromised) checksums.



---



2. How DIVE Works



DIVE decouples the file storage from the integrity verification key:



- Transport: The server delivers the resource and a signature (via RFC 9421).

- Verification: The client fetches the public key from a DNS resource record, secured by DNSSEC.

- Validation: The client verifies the resource's integrity using the out-of-band key.



This mechanism ensures that even if the HTTP server is fully compromised, an attacker cannot bypass integrity checks without also gaining control over the DNSSEC-protected zone.



---



3. Key Benefits



- Rapid Revocation: Key revocation is as fast as DNS TTL propagation.

- Multi-Key Support: The protocol allows for multiple active public keys, enabling key rotation without downtime and supporting diverse signing authorities for the same domain.

- Granular Control: Keys can be restricted to specific subdomains.

- Deployment Ease: Supports a report-only mode for progressive rollout without breaking existing workflows.

- Resilience: An attacker must compromise both the web infrastructure AND the DNS/DNSSEC signing infrastructure (or the private keys associated with the DNS records) to successfully serve a signed malicious file.



---



4. Proof of Concept



A reference client is available via "pip install opendive-client". You can test the verification logic with the sandbox:



- Valid file: opendive download https://sandbox.diveprotocol.org/downloads/valid.txt 

- Invalid file: opendive download https://sandbox.diveprotocol.org/downloads/invalid.txt 



I would greatly appreciate your feedback. Is this something the WG would find interest in pursuing?



Best regards,

Matéo Callec