Hello, I am seeking DNS operational review of the DNS draft publication model described in the following individual Internet-Draft:
draft-jackson-csp-reporting-policy-00<https://datatracker.ietf.org/doc/draft-jackson-csp-reporting-policy/> DNS-Published Content Security Policy Reporting Policy The draft addresses an operational problem: in many organisations, the party responsible for domain security governance controls DNS, but does not consistently control every HTTP service deployed beneath the domain. A domain may include legacy applications, SaaS platforms, CMS-hosted sites, reverse proxies, CDN edges, and subdomains administered by different teams. The draft proposes a DNS-published mechanism for declaring one or more domain-authorised Content Security Policy reporting endpoints. The proposal deliberately does not attempt DNS-based CSP enforcement. It does not allow DNS to grant CSP permissions, weaken CSP policy, override HTTP headers, or alter the disposition of an enforcing or report-only CSP policy. It is limited to reporting endpoint discovery and selection. In environments with distributed application ownership, CSP reporting can be inconsistent, absent, or configured reactively. This limits the ability of the domain operator to receive useful CSP violation reports across the wider estate. The draft currently proposes publication under: `_csp.<Policy-Domain>` using a TXT record beginning with: `v=CSP1` and defines tags for: * report-uri * mode * max_age * sp * format * tag * contact The two proposed modes are: * fallback: use the DNS-declared reporting endpoint only where the HTTP response does not declare a valid reporting endpoint. * augment: send reports to both the HTTP-declared reporting endpoint and the DNS-declared endpoint, subject to user-agent policy, privacy controls, rate limiting, and delivery constraints. I am particularly interested in operational feedback on the following points: * whether DNS publication is a reasonable fit for this problem; * whether the owner name `_csp` is appropriate, or too broad; * whether TXT is appropriate for an initial version of the draft, or whether an alternative record type should be considered from the outset; * whether the cache and freshness model is sufficiently clear; * whether the default subdomain policy is appropriate; * whether the security and privacy considerations are sufficient; * whether DNSOP is a suitable venue for discussion, or whether this should be routed elsewhere. I am not asking DNSOP to validate CSP browser behaviour. My immediate goal is to determine whether the publication model is operationally sound and worth pursuing further. Regards, Simon Jackson Alltime Technologies Ltd
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
