Using DNS in this way is particularly operationally challenging because DNS is "eventually consistent". DNS TTLs are routinely "stretched" by resolvers and clients: even short-lived records can take many hours to reach 100% effective rollout. In the "B" proposal, every HTTP content update could be blocked for hours or days waiting on DNS, with no way for the server operator to know when it is finally safe to make the change.
I think DNS is simply the wrong tool for this job. The most direct solution I've thought of involves a new X.509 OID for "HTTP content auditor" and a signature from the auditor on every returned resource, but that's off-topic for this working group. You might also want to review the Mirror Protocol, which solves a different variant of this problem: https://datatracker.ietf.org/doc/draft-group-privacypass-consistency-mirror/. --Ben Schwartz ________________________________ From: James Addison <ja...@reciperadar.com> Sent: Tuesday, November 28, 2023 6:51 AM To: Ben Schwartz <bem...@meta.com> Cc: dnsop@ietf.org <dnsop@ietf.org> Subject: Re: [DNSOP] RFC 9460: ServiceParamKey for web integrity !-------------------------------------------------------------------| This Message Is From an Untrusted Sender You have not previously corresponded with this sender. |-------------------------------------------------------------------! Hi Ben, Thanks for your response. Please find some comments inline, with one intra-line edit from your message, annotated with pipe symbols. On Tue, Nov 28, 2023 at 3:35 AM Ben Schwartz <bem...@meta.com> wrote: > > Hi James, > > RFC 9460 is quite flexible, and its IANA registration procedures are > relatively open, so there are few barriers to attempting a specification like > you describe.| Thanks - I'd like to be able to participate. The intended goal is to find existing mechanisms to provide high integrity assurance for delivery of a static single-page HTML web application to clients -- or to explore what those mechanisms could be if they do not yet exist. > |However, I do not think it would be a wise approach, for several reasons: > > HTTP is not normally used to serve a single resource per origin. Acknowledged - I don't have an on-topic response for this, although I do believe that integrity within websites (and I admit that is not all HTTP services) could be enhanced, and am aware of one[1] such request for the W3C SRI spec. > HTTP resources admit a variety of representations, resulting in distinct > digest values. This is certainly true in a number of situations - dynamic websites and differing character set encodings spring to mind. Despite that I think that there are cases where it is valuable to deliver static content with high integrity. Doing so can align well with client implementation simplicity and cache hit rates. > The security offered by this feature would be extremely limited in the common > case where DNSSEC is not applied end-to-end. The proposal should allow some limited tampering of webserver responses to be detected in the absence of DNSSEC, but I agree that adding DNSSEC provides stronger guarantees. > Deploying this feature would be operationally challenging if the content can > ever change, because of the need to perform coordinated updates to HTTP > content and DNS records. The deployment mechanism that I use currently -- a TXT record where the character string is prefixed with an uppercase B -- involves two invocations of the openssl command (one dgst, one base64) and then entry of the resulting hash into DNS. For software development lifecycles that include automation, I do not believe that it should be onerous to optionally publish one or two digest values into DNS, although I also do not think that the specification should constrain the record update procedure. > Resource integrity is most valuable when the resource digest is held by a > party who is not the resource publisher, in order to prevent the publisher > from substituting a malicious resource. However, in this design, the > resource publisher (i.e. the origin) also controls the DNS records on its own > zone. Agreed, although I think it should be acceptable (despite perhaps appearing less trustworthy) for both entities to be the same. To further improve integrity (outside of the scope of either the DNS or SRI specifications) it could make sense to allow independent parties to rebuild the deployed web resource content from its source code (perhaps retrieved from yet another entity) -- to verify that all three of the DNS-published digest, the digest calculated from the fetched resource, and the digest calculated after building the web application entrypoint page from source have the same value (this is similar to the idea of reproducible builds). [1] - https://github.com/w3c/webappsec/issues/497 [snip] > ________________________________ > From: DNSOP <dnsop-boun...@ietf.org> on behalf of James Addison > <ja...@reciperadar.com> > Sent: Wednesday, November 22, 2023 12:52 PM > To: dnsop@ietf.org <dnsop@ietf.org> > Subject: [DNSOP] RFC 9460: ServiceParamKey for web integrity > > !-------------------------------------------------------------------| > This Message Is From an Untrusted Sender > You have not previously corresponded with this sender. > |-------------------------------------------------------------------! > > Hello, > > This is a follow-up / redirection from a discussion thread[1] on the > dnsext mailing list regarding a proposal for an additional DNS RR > type. Feedback received there indicates that instead of a distinct > record type, a ServiceParamKey for use with the RFC 9460 HTTPS record > type could potentially cater to the requirements. > > In short summary of the previous thread: the request is for addition > of an integrity record, in a similar or identical format to that > specified by W3C HTML SubResource Integrity specification[2], to be > available alongside existing A/AAAA records for domains containing > webservers. The contents of the record would be used by web browser > clients to validate whether the response they receive from an initial > request to the root URI path from any of the hosts in the domain > matches an expected hash value. > > The motivation of the request is to provide an optional > out-of-HTTP-band integrity check for web clients that download a > single-page web application from a fixed URI path on a domain name. > The risk that it intends to mitigate is that one or more hosts within > the domain could have become compromised to respond with web content > that does not match that intended by the domain owner, regardless of > the presence of TLS during the web requests. > > I have two questions about this in relation to RFC 9460: > > * Would it seem valid to suggest an HTTPS ServiceParamKey to contain > an integrity record of this kind? > > * Given a desire to deliver content using _either_ plaintext HTTP _or_ > TLS-enabled HTTPS (traditionally TCP ports 80, 443 respectively) - > would Section 9.5 of RFC 9460 (footnote three) conflict with the > plaintext HTTP delivery mechanism? > > Thank you, > James > > [1] - > https://mailarchive.ietf.org/arch/msg/dnsext/vtbGXqBKSKzBqYAAE1VMhATiuw4/ > > [2] - https://www.w3.org/TR/2016/REC-SRI-20160623/ > > [3] - https://www.rfc-editor.org/rfc/rfc9460.html#section-9.5 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
