Replying with hindsight: On Thu, Nov 30, 2023 at 4:56 PM James Addison <ja...@reciperadar.com> wrote: ... [snip] ... > * Catering for situations where rapid updates are applied to > integrity records seems like it may be required, at least during short > durations. One typo fix is frequently followed by others, for > example, and some application deployments require hotfixes after > production metrics are received. Those moments are cache-disruptive, > and in a frustratingly annoying way: it shouldn't really be necessary > for the authority to hold multiple integrity records -- what might be > preferable is for a resolver to remember (or query) a few > temporally-stale entries, and only to request an updated integrity > record when content cannot be validated (suggesting that the workflow > is in fact: DNS A* lookup, followed by an HTTP(S) request, followed by > an optional DNS integrity request).
Recapping: the requirement to hold multiple valid integrity checksums following a homepage update seems invioable given the practical reality of a gradual-deployment model (where rollout of web content to hosts occurs incrementally, and therefore clients may receive stale content from some hosts). I do not believe that the DNS protocol does -- or should -- support client queries that include a time dimension/parameter, and so despite the wording of my previous message, I certainly would not propose anything like that in relation to the proposed webintegrity record. Therefore a RR type or SvcParamKey to support webintegrity must (I think - I'm wary of using that word) provide for multi-valued contents. To re-state my preference: I think the existing W3C SRI multi-value-capable base64-encoded hash format would be suitable, since browsers are likely to contain code to parse that format already. My sense is that SHA-512 checksums are probably a good baseline to cater for. From practical experience, up to two base64-encoded SHA512 hashes with corresponding 'sha512-' prefixes fit within the most-widely-compatible practical implementations of TXT records (255 bytes) -- despite TXT records theoretically providing support for longer-length string values. Given that RecipeRadar's deployment process hasn't yet had a requirement for more than two (current, stale) concurrent hash values at any given point-in-time, and given that I believe that the value provided by adoption of a webintegrity feature should, in itself, eventually encourage both web clients, site operators, and DNS management interfaces to push for greater support for extended-length TXT records, I feel comfortable to proceed using the existing unmodified TXT RRtype to offer webintegrity for clients. Thank you for your time, James _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
