Hi there, I have a question about this proposal (that is unrelated to your points below, hence the subject change).
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? Thanks in advance, Gavin. > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
