Internet DRAFT - draft-pardue-httpbis-preconnect-hint-svc-param
draft-pardue-httpbis-preconnect-hint-svc-param
HTTP L. Pardue
Internet-Draft 24 October 2022
Intended status: Experimental
Expires: 27 April 2023
A Preconnect Hint for SVCB/HTTPS RR
draft-pardue-httpbis-preconnect-hint-svc-param-00
Abstract
HTTP resources from one origin often have relationships to resources
on other origins. This document outlines how a "preconnectHint"
SvcParamKey for SVCB, could be used to provide an early indication of
origins that are related to the current origin. Clients could use
this information to opportunistically prepare and open connections,
with the expectation that they will be used to fetch related
resources. This mechanism provides information from a source that is
not the authenticated origin, which could cause the client to perform
actions that no other party would ask them to do; privacy
considerations due to this are visited.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://LPardue.github.io/draft-pardue-httpbis-preconnect-hint-svc-
param/draft-pardue-httpbis-preconnect-hint-svc-param.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-pardue-httpbis-preconnect-
hint-svc-param/.
Discussion of this document takes place on the HTTP Working Group
mailing list (mailto:ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/.
Source for this draft and an issue tracker can be found at
https://github.com/LPardue/draft-pardue-httpbis-related-origins.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Pardue Expires 27 April 2023 [Page 1]
Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. The preconnectHint SvcParamKey . . . . . . . . . . . . . . . 4
4. Security and Privacy Considerations . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
HTTP resources from one origin often have relationships to resources
on other origins. For example, when a user agent loads the main HTML
document of a webpage from one one origin, it can discover critical
dependencies at additional first-party or third-party origins. In
order to fetch these resources, additional connections might be
required. The additional time required to establish new connections
can inflate the perceived latency of rendering or using resources.
Pardue Expires 27 April 2023 [Page 2]
Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
In some cases, a server may be authoritative for several origins.
HTTP/2 [RFC9113] and HTTP/3 [RFC9114] allow clients to coalesce
different origins onto the same connection when certain conditions
are met. The ORIGIN frame ([RFC8336] and
[I-D.ietf-httpbis-origin-h3]) enhances this further. These
techniques can help minimize perceived latency by eliminating
connection setup time entirely, but they apply only for the subset of
origins that can safely be coalesced.
The 103 (Early Hints) status code [RFC8297] can convey hints about
resource relationships. A server can emit interim responses to help
the client start making preparations, such as creating new
connections. This is especially useful when the origin might take
time to generate the final response. Where related resources reside
on third-party origins, this technique helps minimize perceived
latency by providing the client with information as early as possible
in the HTTP message exchange. Thus it fills a capability gap left by
coalescing. However, the technique is dependent on the timing of
message exchanges, which might might make it difficult to achieve
performance gains in practice.
It is common for a web page to fetch resources from a fairly stable
set of additional origins, even if the specific resource paths are
more volatile. For example, a page may be designed to load scripts
from third-party resource CDNs, or images from content sub-domains
under the same top-level origin. User agents can only learn of these
relationships once a resource has been fetched. This "run-time
learning" of stable relationships delays the time at which a client
discovers it might need to create additional connections. Between
fetching a resource and learning its dependencies, here is an
opportunity to reduce performance delays caused by the delayed run-
time learning of these relationships, even in light of the techniques
described above.
This document defines the "preconnectHint" SvcParamKey for SVCB
[I-D.ietf-dnsop-svcb-https], to indicate origins that are related to
the current origin. Clients that query HTTPS RRs can use the
information contained in this parameter to opportunistically prepare
and open connections, with the expectation that they will be used to
fetch related resources. This could include chaining DNS queries for
the hinted origins. Preconnect origins might satisfy the conditions
required for HTTP connection coalescing, in which case the
optimization could still reduce the delay before clients perform
coalescing-related checks; for example, certificate fetching or
validation.
Pardue Expires 27 April 2023 [Page 3]
Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The preconnectHint SvcParamKey
SVCB and HTTPS Resource Records can include the preconnectHint
SvcParamKey to indicate related origins. Its presentation format
value is a comma-separated list of <domain-name> (Section 5.1 of
[RFC1035]).
For example, consider the resource at https://example.org/index.html
that has the dependencies https://www.example.com/style.css, and
https://scripts.example.org/script.js. As an HTTPS RR, the
relationship between example.org and other origins could be
represented as:
example.org IN HTTPS 1 . alpn=h2,h3 preconnectHint=www.example.com,scripts.example.org
A common pattern in HTTP is to use 3xx redirect status codes to move
from www subdomains to domain apexes. Building on the previous
example, if www.example.com were intended to be redirected to
example.com, this could be represented in an additional RR as:
www.example.com IN HTTPS 1 . alpn=h2,h2 preconnectHint=example.com
Clients that learn about preconnect origins MAY use this information
to make whatever preparations they deem fit. For instance, they
could use it to perform the same connection coalescing authority
checks ([RFC9113] and [RFC9114]) that would otherwise happen later in
a connection lifecycle. Similarly, they could use this information
to help maintain a connection pool and, where needed, proactively
create or keep open connections to those origins in anticipation of
being used.
There are new privacy considerations to make when using any
preconnect origin information provided via the DNS. The records are
presented by resolvers that act on behalf of, but are not
authoritative for, the origin. As such, the resolvers could present
unauthenticated information that could cause a client to take actions
that the authenticated origin would not. This could be abused to
leak information about the client. A malicious resolver could also
abuse this mechanism unbeknownst to the origin.
Pardue Expires 27 April 2023 [Page 4]
Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
The preconnectHint SvcParamKey is a hint and could contain stale,
incorrect or superfluous information. A client SHOULD implement
checks and heuristics that limit state or resource commitment based
on this information. For example, a client could track how often
preconnect origins are matched to related resources. Notably, the
scope of relationships is at the origin level, not any other
component that might later comprise a URI that is to be fetched. As
such, constraining the set of values in the preconnectHint parameter,
to those that are most likely to be used by a client, can help avoid
commitment of resources that might subsequently go unused.
Knowledge of HTTP resource relationships might be restricted to
authorized clients. Exposing those origins as a preconnectHint to
unauthorised DNS clients could leak confidential or sensitive
information. Therefore, the preconnectHint SvcParmKey SHOULD NOT
contain origins that relate to information that would otherwise only
be accessible to authorized clients.
4. Security and Privacy Considerations
Information about origin relationships is typically presented by the
authenticated origin itself. Delegating this information to an
unauthenticated and untrusted DNS resolver provides opportunities to
manipulate client behaviour, which could risk privacy problems; see
Section 3.
The preconnectHint parameter reveals information about the
relationships of resources hosted on a server. While this
information is typically already available to any client that visits
the server, some resources may only be discoverable by authorized
clients. Guidance for managing this is given in Section 3.
5. IANA Considerations
TBD
6. References
6.1. Normative References
[I-D.ietf-dnsop-svcb-https]
Schwartz, B. M., Bishop, M., and E. Nygren, "Service
binding and parameter specification via the DNS (DNS SVCB
and HTTPS RRs)", Work in Progress, Internet-Draft, draft-
ietf-dnsop-svcb-https-11, 11 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
svcb-https-11>.
Pardue Expires 27 April 2023 [Page 5]
Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
6.2. Informative References
[I-D.ietf-httpbis-origin-h3]
Bishop, M., "The ORIGIN Extension in HTTP/3", Work in
Progress, Internet-Draft, draft-ietf-httpbis-origin-h3-01,
5 October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-httpbis-origin-h3-01>.
[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints",
RFC 8297, DOI 10.17487/RFC8297, December 2017,
<https://www.rfc-editor.org/rfc/rfc8297>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/rfc/rfc8336>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
Acknowledgments
This document is based on one of the options described by Barry
Pollard's "Even earlier connection hints"
(https://docs.google.com/document/
d/1ApILvaFpZPGx6NkqhPvlqni6kTaWfcY6xSEuXg8XdiA/
edit#heading=h.fxvrme9c9xpm) proposal presented to the Web Perf WG at
TPAC 2022.
Ben Schwartz suggested the name preconnectHint.
Pardue Expires 27 April 2023 [Page 6]
Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
Thanks to Chris Wood for a providing insight into the privacy
implications of this design.
Author's Address
Lucas Pardue
Email: lucaspardue.24.7@gmail.com
Pardue Expires 27 April 2023 [Page 7]
