Distribute NEL policies with DNS

[simon-friedberger]

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.

[Sora2455]

That would solve the problem of setting an origin policy via a request header...

[clelland]

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)

[LPardue]

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.

[SulemanAhmadd]

+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).

[enygren]

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.

[valenting]

So the concern here is that a server could distribute client-specific reporting endpoints. One suggested mitigation is to distribute reporting endpoints via DNS, most likely using an HTTPS (SVCB) record.

Including the full NEL policy or the complete Report-To / Reporting-Endpoints configuration in DNS seems unnecessary. A user agent cannot safely act on a NEL policy until it has established a successful HTTPS connection to the origin, because the authenticity of DNS data alone is insufficient. Even when using DoH, allowing recursive resolvers to dictate NEL policies would be undesirable. While DNSSEC could theoretically authenticate such records, it is not widely validated by clients today, and even then, DNS is not an appropriate trust anchor for NEL policy delivery.

The primary goal, instead, is to ensure that all clients receive the same reporting endpoints. DNS is one mechanism that can help enforce this property. Therefore, rather than encoding full policies, DNS could be limited to conveying only the information we care about for this purpose: the allowed reporting endpoints.

One possible approach would be to define a new SvcParam that encodes a reporting URL, for example:

allowed-reporting-url="https://example.com/nel/v1"

or

allowed-reporting-url="https://example.com/.well-known/nel"

However, this has some drawbacks. Supporting multiple URLs would increase the size of the HTTPS record, and even a single URL contains redundant information (such as the https:// scheme) that is already implied by the record context.

A cleaner alternative would be to make the path implicit by convention (e.g., a fixed .well-known location), and have the SvcParam specify only the allowed domains. This also prevents servers from assigning user-specific subdomains.

For example:

allowed-reporting-domain="example.com"

This would indicate that the site uses https://example.com/.well-known/nel as its reporting endpoint, and provides reasonable assurance that the endpoint is shared across users and not uniquely assigned per client.

Thoughts?

[SulemanAhmadd]

I do not see any obvious concerns with this proposal. The DNS signal for reporting endpoints must act as a hard constraint that the HTTP server cannot override when returning the complete NEL policy (the user agent can ignore any reporting endpoint whose registrable domain is not a member of the DNS-advertised allowlist).

Another aspect to consider is that a NEL policy has its own expiration timestamp (max_age), which may differ from the TTL of the HTTPS record that advertises the reporting endpoint.