Open simon-friedberger opened 11 months ago
That would solve the problem of setting an origin policy via a request header...
It certainly would :)
It may introduce a number of other problems; I haven't thought it through completely, but the issue of using a response header to convey what should be origin-wide configuration detail has always been problematic. (See #2 for discussion even 4+ years ago)
Configuring NEL through DNS - presumably through a well-known TXT record, like email SPF does - would provide a single source of truth for the origin. The set of people who can change DNS records may be close to the set of people who care about network failures (this isn't necessarily true, but it might be closer than the set of people who can set response headers)
I'm not sure how much of the DNS infrastructure is currently unencrypted; we currently require https in order to enable NEL/reporting, and I think we'd want to do the same here.
There might also be some issues with DNS-over-HTTP (I'm not actually sure, but there are multiple protocols involved, and an API that's supposed to expect network failures, so I'd want to think carefully about the potential failure modes)
SCVB/HTTPS might be a better option here than TXT. With a stretch of imagination - a single origin in a multi-CDN'd setup might want a per-CDN NEL configuration. A new HTTPS param could allow that.
+1 support for DNS based advertisement. It also means the client does not need to make an initial successful HTTPS connection with the origin to configure the NEL policy. HTTPS DNS record type can be used (similar to how ECH configs are set).
Adding this as a SvcParam to SVCB/HTTPS RRs is an interesting idea. There might be privacy (and record size) considerations to doing so, but as suggested above it would allow for having different reporting for different endpoints. This would work better in a Multi-CDN environment and would also allow advertising at DNS time.
Receiving NEL policies from the server has some inherent tracking problems because each client could be assigned a different report-to URL. This could be ameliorated by distributing policies via DNS.