Hi Gavin,
On Thu, Nov 23, 2023 at 5:08 PM Gavin Brown 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 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/ 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
