idnits 2.17.1 draft-goto-httpbis-preload-frame-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 134: '... server MUST store only information about Preload[Preload] in this...' RFC 2119 keyword, line 149: '...amic header table MUST NOT be updated....' RFC 2119 keyword, line 160: '...thority. Therefore, the server SHOULD...' RFC 2119 keyword, line 193: '... This frame MUST be ignored if the s...' RFC 2119 keyword, line 195: '...ame that is too long, it SHOULD ignore...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 08, 2019) is 1932 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) ** Downref: Normative reference to an Experimental RFC: RFC 8297 -- No information found for draft-ietf-quic-http-latest - is the name correct? -- No information found for draft-ietf-quic-qpack-latest - is the name correct? -- No information found for draft-ietf-tls-esni-latest - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Goto 3 Internet-Draft GREE, inc 4 Expires: July 12, 2019 January 08, 2019 6 The PRELOAD Frame Extension 7 draft-goto-httpbis-preload-frame-01 9 Abstract 11 A server can send application data before a client sends data if they 12 are using HTTP/2 with TLS1.3 or HTTP/3. Indicating loading of 13 necessary resources without waiting for the first request from the 14 client may improve page loading performance. This document defines 15 the PRELOAD frame, which is a new extension frame that allows the 16 server to notify of preload information. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. PRELOAD Frame Overview . . . . . . . . . . . . . . . . . 2 54 2. PRELOAD Frame Extension . . . . . . . . . . . . . . . . . . . 3 55 2.1. Using Link Header . . . . . . . . . . . . . . . . . . . . 4 56 2.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2.1. Frame Format . . . . . . . . . . . . . . . . . . . . 4 58 2.3. HTTP/3 . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.5. Error Code . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 5.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 A server can send application data before a client sends application 72 data if they are using HTTP/2[RFC7540] with TLS1.3[RFC8446] or 73 HTTP/3[HTTP3]. But in HTTP/2 [RFC7540] the server only sends a 74 SETTINGS frame as the server connection preface. After that, it can 75 send an HTTP response (including a 103 status code [RFC8297]) or 76 server push only after receiving a request from the client. 78 Indicating loading of necessary resources without waiting for the 79 first request from the client may improve page loading performance. 80 In order to make effective use of opportunities for the server to 81 transmit application data for the first time, this document defines a 82 PRELOAD frame; a new extension frame which enables the server to 83 notify preload [Preload] information from the server. 85 1.1. PRELOAD Frame Overview 87 A PRELOAD frame can be sent with the application data that the server 88 first transmits after the TLS 1.3 handshake. The motivation of the 89 PRELOAD frame is to make effective use of that transmission 90 opportunity. 92 The flow is as follows: 94 Client Server 96 ClientHello --------> 97 ServerHello 98 {EncryptedExtensions} 99 {CertificateRequest*} 100 {Certificate*} 101 {CertificateVerify*} 102 {Finished} 103 <-------- [Application Data*] 104 - SETTINGS 105 (as Connection Preface) 106 - PRELOAD 107 {Finished} --------> 108 [Application Data] --------> 109 - Connection Preface 110 - SETTINGS 111 - SETTINGS(ACK) 112 - HEADERS 114 '-' Indicates HTTP/2 messages in Application Data. 116 Figure 1: OverView in HTTP/2 with TLS1.3 118 After sending ServerHello of the TLS 1.3 handshake, the server sends 119 a SETTINGS frame which is the server connection preface as TLS 120 Application Data. Subsequently, The server uses the SNI to identify 121 the domain which the client wants to send an HTTP request. The 122 server can indicate preload in the PRELOAD frame for resources 123 commonly used in that domain. The client parses the PRELOAD frame 124 and fetches the resource if it does not have cache for that resource. 125 The semantics are the same as those defined in Preload[Preload]. If 126 the client does not support a PRELOAD frame, it is simply ignored. 128 2. PRELOAD Frame Extension 130 Preload Frame Extension does not define a new format to convey 131 preload information. It uses the already defined Link HTTP header. 132 However, it is not an HTTP response carried in this frame, and it is 133 not associated with an HTTP request to an authority. Therefore, the 134 server MUST store only information about Preload[Preload] in this 135 frame to avoid confusion in the implementation. 137 Open Question: In the above, the PRELOAD frame is allowed to carry 138 only information about Preload[Preload]. However, adapting security 139 policies such as HSTS more quickly improves security. But it is not 140 associated with any specific request. It is possible to indicate the 141 domain to which the policy applies by specifying the target domain 142 (matching with SNI's HostName) in the PRELOAD frame. Does this 143 introduce any semantics or security issues? 145 Since this frame does not represent an HTTP response, it does not 146 have a context for header compression, is not possible to use a 147 dynamic table for encoding or decoding HTTP responses. Since the 148 Preload[Preload] frame may be ignored by the received endpoint the 149 dynamic header table MUST NOT be updated. 151 Open Question: Would it benefit if PRELOAD frames could use separate 152 dynamic header tables? 154 This document defines extensions for HTTP/2 and HTTP/3 separately. 156 2.1. Using Link Header 158 In preload using Link header [RFC8288], resources can be specified by 159 relative path. However, the PRELOAD frame is not associated with an 160 HTTP request to a particular authority. Therefore, the server SHOULD 161 specify a complete URI for the specification of resources within the 162 Preload. 164 Link: ; rel=preload; as=script 166 Figure 2: Link preload type example 168 2.2. HTTP/2 170 2.2.1. Frame Format 172 A PRELOAD frame (type=TBD) carries a Header Block containing Preload 173 information. 175 0 1 2 3 176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Header Block (*) ... 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 3: PRELOAD frame payload 183 The payload of the PRELOAD frame contains the following fields: 185 o Header Block: HTTP header represented by HPACK [RFC7541] 187 The PRELOAD frame does not define any flags. 189 Endpoints that do not support this extension simply ignore reception 190 of this PRELOAD frame. 192 This PRELOAD frame can be sent only from the server on stream ID 0. 193 This frame MUST be ignored if the server receives this frame or if 194 the client receives this frame with a different stream ID. If a 195 client receives a PRELOAD frame that is too long, it SHOULD ignore 196 that. 198 A parse error of the Header Block in the PRELOAD frame MAY be treated 199 as COMPRESSION_ERROR, or MAY simply ignore this frame. 201 The server can send a PRELOAD frame before receiving 202 SETTINGS_MAX_HEADER_LIST_SIZE from the client. PRELOAD frames that 203 are too long should not be sent. 205 2.3. HTTP/3 207 The PRELOAD frames (type=TBD) can be used with HTTP/3. The format is 208 the same as described for Section 2.2.1, but the payload Header Block 209 uses QPACK [QPACK] instead of HPACK. This frame MUST NOT update the 210 dynamic header table. 212 The PRELOAD frame can only be sent from the server on the control 213 stream. This frame MUST be ignored if the server receives this frame 214 or if the client receives this frame with a different streams. If a 215 client receives a PRELOAD frame that is too long, it SHOULD ignore 216 that. 218 2.4. Padding 220 If the length of the PRELOAD frame changes depending on the SNI used, 221 observation the first application data to make the hostname inferable 222 on the path. This should be considered when encrypting SNI with 223 ENSI[TLS-ESNI]. 225 (TBD) Use Padding 227 2.5. Error Code 229 (TBD) 231 Note: Should a new Error Code be defined? 233 3. Security Considerations 235 The server can consume client resources by sending a large PRELOAD 236 frame. Therefore, clients should ignore PRELOAD frames that are too 237 large. 239 4. IANA Considerations 241 This specification adds an entry to the "HTTP/2 Frame Type" registry. 243 o Frame Type: PRELOAD 245 o Code: TBD 247 o Specification: This draft 249 5. References 251 5.1. Normative References 253 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 254 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 255 DOI 10.17487/RFC7540, May 2015, 256 . 258 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 259 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 260 . 262 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 263 DOI 10.17487/RFC8288, October 2017, 264 . 266 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 267 RFC 8297, DOI 10.17487/RFC8297, December 2017, 268 . 270 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 271 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 272 . 274 5.2. Informative References 276 [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 277 (HTTP/3)", draft-ietf-quic-http-latest (work in progress). 279 [Preload] Grigorik, I., "Preload", n.d., 280 . 282 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 283 Header Compression for HTTP/3", draft-ietf-quic-qpack- 284 latest (work in progress). 286 [TLS-ESNI] 287 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 288 "Encrypted Server Name Indication for TLS 1.3", draft- 289 ietf-tls-esni-latest (work in progress), n.d.. 291 Acknowledgements 293 I appreciate Masaki Fujimoto and Oku Kazuho for valuable feedbacks. 295 Author's Address 297 Hiroyuki Goto 298 GREE, inc 300 Email: hiroyuki.goto@gree.net