Hi Gavin, On Thu, Nov 23, 2023 at 5:08 PM Gavin Brown <gavin.br...@icann.org> wrote: [snip] > Neither DNS nor HTTP are end-to-end protocols; there are often multiple > intermediaries between stub resolver and authority server (for DNS) and user > agent and origin (for HTTP), which often cache things that pass through them. > > Given the above, if a website operator wants to update their home page, won't > they need to pre-publish the digest of the new content, so that user agents > that rely on this information won't refuse to load pages because the previous > digest is cached?
Yes, that's correct. Relatedly: it seems important to support transition phases during which at least one stale/cached digest is published alongside the current/fresh digest, and for user-agents to consider any of those values acceptable as an equality-match after applying the appropriate hash method to the response content[1] received from the homepage. Webserver operators should configure HTTP response directives that instruct web caches to expire homepage content within a duration no longer than the TTL of the DNS integrity record. Web clients intending to validate integrity should use the TTL value from the integrity record as an upper-bound on their local cache lifetime for the associated homepage URI. Regards, James [1] - I'm not aware of any practical integrity attacks on web user-agents that would rely solely on non-body-content of an HTTP response, a way an attacker might attempt to evade the suggested check, but I get the feeling that such possibilities could exist. > > On 22 Nov 2023, at 17:52, James Addison <ja...@reciperadar.com> wrote: > > > > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dnsext/vtbGXqBKSKzBqYAAE1VMhATiuw4/__;!!PtGJab4!6VsrAJgeCCR4aJGNQ_juW436AZ8nUPiSOpp982SgmU01OjuXwZElcdBrnh420XTVkkGBYw3Vil73Q6et-hsRNCTA$ > > [mailarchive[.]ietf[.]org] > > > > [2] - > > https://urldefense.com/v3/__https://www.w3.org/TR/2016/REC-SRI-20160623/__;!!PtGJab4!6VsrAJgeCCR4aJGNQ_juW436AZ8nUPiSOpp982SgmU01OjuXwZElcdBrnh420XTVkkGBYw3Vil73Q6et-lKtTESB$ > > [w3[.]org] > > > > [3] - > > https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9460.html*section-9.5__;Iw!!PtGJab4!6VsrAJgeCCR4aJGNQ_juW436AZ8nUPiSOpp982SgmU01OjuXwZElcdBrnh420XTVkkGBYw3Vil73Q6et-qOUabI-$ > > [rfc-editor[.]org] > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!6VsrAJgeCCR4aJGNQ_juW436AZ8nUPiSOpp982SgmU01OjuXwZElcdBrnh420XTVkkGBYw3Vil73Q6et-qArxRad$ > > [ietf[.]org] > > -- > Gavin Brown > Principal Engineer, Global Domains & Strategy > Internet Corporation for Assigned Names and Numbers (ICANN) > > https://www.icann.org > > _______________________________________________ > 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
