Re: [dnsext] Draft: RRTYPE B - Web Resource Integrity

[James Addison <[e-mail]>]

Thanks for the response, kre - I'll mention that I didn't receive your
message by email, but noticed it on the web-based dnsext[.ietf.org]
mailing list archive.  Please find my comments inline:

On Fri, 17 Nov 2023 02:15:36 -0000, kre wrote:
>
> The proposal seems to assume that two different objects (this proposed
> new DNS resource, and the web page to which it refers) can be updated
> synchronously somehow - the DNS doesn't do that, it takes a definitely
> measurable period of time for any data in the DNS to be altered, old
> copies are still present at secondary servers for some period after
> the primary is updated, and caches all over the planet don't even look
> for updates until the TTL on the last answer they had received expires.
>
> As described (and other than in local, single server, testing) this
> scheme simply cannot work reliably.

This timing problem is genuine, yes.

> I'd expect that you'd want to allow at least 2 (perhaps more) of these
> records to exist, and consider a page valid if any of them provides the
> correct hash - that way the hash for an updated page can be installed,
> then wait for that to have propogated (sum of secondary reload time,
> plus TTL expiry) then update the page, then it should be safe to delete
> the old entry.   Allowing for more than 2 to co-exist might be needed
> if two quick changes were needed to the web page, that is, a new version
> while still waiting for the previous one to be ready to be installed,
> but after its resource record is already in the DNS (haven't really
> thought through all the possible scenarios, but someone needs to).

This multi-record suggestion has a parallel in the HTML SubResource
Integrity spec: it is valid to list multiple[1] hash values in an
integrity attribute; the client is instructed to consider the fetched
payload as valid if it matches _any_ of those hashes.

So given a TTL of 3600 seconds, we could temporarily deploy a two-hash
DNS B record containing both the current and updated hashes for a
static site, subsequently deploy the updated site to the webserver(s),
and eventually simplify to a new baseline state with a single-hash DNS
B record again after 3600 seconds have expired.

> I don't understand the purpose (that's just me, I don't follow much
> security or web related stuff at all, and so anything which is those
> two combined is guaranteed outside my area) - but why the insistence
> on only covering the root page at a domain name?   As I understand the
> way many web servers overate, there is often no such page, and any
> valid URL at the server must have some kind of path appended to the
> domain name in the URL to receive a meaningful answer (that is, a
> non-error reply of one form or other).

I admit it is somewhat arbitrary to associate the record strictly with
the root web path, and acknowledge that websites aren't required to
serve meaningful content from that path.

The goal of this record type is to provide an opt-in increase in
trustworthiness for static HTML-based content served from domains,
while maintaining the desirable ability to deploy that content in
cost-effective and widely-available ways.

The particular risk area that this record type attempts to mitigate is
that of untrustworthy or compromised webservers for a given domain
name.  In the case of a TLS-secured session, negotiation and
communication with an individual such host and the client may succeed;
the DNS B integrity record provides an additional method to detect
tampered content, and one that is outside of the immediate security
boundary of the compromised host.

In simplified terms, the record is an expect/checksum value that the
client can use to confirm that the _initial_ access into a website
(bearing in mind the fixed path) maintains integrity.  From there, the
website may or may offer navigation through a fully-connected graph of
webpages, may or may not provide subresource integrity guarantees on
content within the page and beyond, and may or may not link to content
on other domains.



An additional note / addendum:

About the reasoning for a single, fixed root path: I don't see DNS as
being a place to store large amounts of potentially-dynamic data, and
would prefer to ignore all kinds of problems that I'd anticipate
related to attempting to map a set of multiple URI paths to either
one-or-more DNS record(s).  Those in combination with the fact that a
single-page HTML application _can_ be served from a single URL drew me
towards idea of a single fixed path, for simplicity.

[1] - https://www.w3.org/TR/2016/REC-SRI-20160623/#does-response-match-metadatalist