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. 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. * HTTP resources admit a variety of representations, resulting in distinct digest values. * The security offered by this feature would be extremely limited in the common case where DNSSEC is not applied end-to-end. * 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. * 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. I believe in the value of enabling web servers to commit to the contents of certain web pages, but I don't think DNS is likely to play a significant role in any good solution to that problem. --Ben Schwartz ________________________________ From: DNSOP <[email protected]> on behalf of James Addison <[email protected]> Sent: Wednesday, November 22, 2023 12:52 PM To: [email protected] <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
