idnits 2.17.1 draft-goto-httpbis-preload-frame-00.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 133: '... server MUST store only information about Preload[Preload] in this...' RFC 2119 keyword, line 148: '...amic header table MUST NOT be updated....' RFC 2119 keyword, line 159: '...thority. Therefore, the server SHOULD...' RFC 2119 keyword, line 192: '... This frame MUST be ignored if the s...' RFC 2119 keyword, line 194: '...ame that is too long, it SHOULD ignore...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2018) is 1956 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: June 21, 2019 December 18, 2018 6 The PRELOAD Frame Extension 7 draft-goto-httpbis-preload-frame-00 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 June 21, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . 5 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, 75 it can send an HTTP response (including a 103 status code [RFC8297]) 76 or 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 - HEADERS 113 '-' Indicates HTTP/2 messages in Application Data. 115 Figure 1: OverView in HTTP/2 with TLS1.3 117 After sending ServerHello of the TLS 1.3 handshake, the server sends 118 a SETTINGS frame which is the server connection preface as TLS 119 Application Data. Subsequently, The server uses the SNI to identify 120 the domain which the client wants to send an HTTP request. The 121 server can indicate preload in the PRELOAD frame for resources 122 commonly used in that domain. The client parses the PRELOAD frame 123 and fetches the resource if it does not have cache for that resource. 124 The semantics are the same as those defined in Preload[Preload]. If 125 the client does not support a PRELOAD frame, it is simply ignored. 127 2. PRELOAD Frame Extension 129 Preload Frame Extension does not define a new format to convey 130 preload information. It uses the already defined Link HTTP header. 131 However, it is not an HTTP response carried in this frame, and it is 132 not associated with an HTTP request to an authority. Therefore, the 133 server MUST store only information about Preload[Preload] in this 134 frame to avoid confusion in the implementation. 136 Open Question: In the above, the PRELOAD frame is allowed to carry 137 only information about Preload[Preload]. However, adapting security 138 policies such as HSTS more quickly improves security. But it is not 139 associated with any specific request. It is possible to indicate the 140 domain to which the policy applies by specifying the target domain 141 (matching with SNI's HostName) in the PRELOAD frame. Does this 142 introduce any security issues? 144 Since this frame does not represent an HTTP response, it does not 145 have a context for header compression, is not possible to use a 146 dynamic table for encoding or decoding HTTP responses. Since the 147 Preload[Preload] frame may be ignored by the received endpoint the 148 dynamic header table MUST NOT be updated. 150 Open Question: Would it benefit if PRELOAD frames could use separate 151 dynamic header tables? 153 This document defines extensions for HTTP/2 and HTTP/3 separately. 155 2.1. Using Link Header 157 In preload using Link header [RFC8288], resources can be specified by 158 relative path. However, the PRELOAD frame is not associated with an 159 HTTP request to a particular authority. Therefore, the server SHOULD 160 specify a complete URI for the specification of resources within the 161 Preload. 163 Link: ; rel=preload; as=script 165 Figure 2: Link preload type example 167 2.2. HTTP/2 169 2.2.1. Frame Format 171 A PRELOAD frame (type=TBD) carries a Header Block containing Preload 172 information. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Header Block (*) ... 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 3: PRELOAD frame payload 182 The payload of the PRELOAD frame contains the following fields: 184 o Header Block: HTTP header represented by HPACK [RFC7541] 186 The PRELOAD frame does not define any flags. 188 Endpoints that do not support this extension simply ignore reception 189 of this PRELOAD frame. 191 This PRELOAD frame can be sent only from the server on stream ID 0. 192 This frame MUST be ignored if the server receives this frame or if 193 the client receives this frame with a different stream ID. If a 194 client receives a PRELOAD frame that is too long, it SHOULD ignore 195 that. 197 A parse error of the Header Block in the PRELOAD frame MAY be treated 198 as COMPRESSION_ERROR, or MAY simply ignore this frame. 200 The server can send a PRELOAD frame before receiving 201 SETTINGS_MAX_HEADER_LIST_SIZE from the client. PRELOAD frames that 202 are too long should not be sent. 204 2.3. HTTP/3 206 The PRELOAD frames (type=TBD) can be used with HTTP/3. The format is 207 the same as described for Section 2.2.1, but the payload Header Block 208 uses QPACK [QPACK] instead of HPACK. This frame MUST NOT update the 209 dynamic header table. 211 The PRELOAD frame can only be sent from the server on the control 212 stream. A server that has received this frame or received on a 213 different stream MUST be treated as a connection error. 215 2.4. Padding 217 If the length of the PRELOAD frame changes depending on the SNI used, 218 observation the first application data to make the hostname inferable 219 on the path. This should be considered when encrypting SNI with 220 ENSI[TLS-ESNI]. 222 (TBD) Use Padding 224 2.5. Error Code 226 (TBD) 228 Note: Should a new Error Code be defined? 230 3. Security Considerations 232 The server can consume client resources by sending a large PRELOAD 233 frame. Therefore, clients should ignore PRELOAD frames that are too 234 large. 236 4. IANA Considerations 238 This specification adds an entry to the "HTTP/2 Frame Type" registry. 240 o Frame Type: PRELOAD 242 o Code: TBD 244 o Specification: This draft 246 5. References 248 5.1. Normative References 250 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 251 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 252 DOI 10.17487/RFC7540, May 2015, 253 . 255 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 256 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 257 . 259 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 260 DOI 10.17487/RFC8288, October 2017, 261 . 263 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 264 RFC 8297, DOI 10.17487/RFC8297, December 2017, 265 . 267 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 268 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 269 . 271 5.2. Informative References 273 [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 274 (HTTP/3)", draft-ietf-quic-http-latest (work in progress). 276 [Preload] Grigorik, I., "Preload", n.d., 277 . 279 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 280 Header Compression for HTTP/3", draft-ietf-quic-qpack- 281 latest (work in progress). 283 [TLS-ESNI] 284 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 285 "Encrypted Server Name Indication for TLS 1.3", draft- 286 ietf-tls-esni-latest (work in progress), n.d.. 288 Acknowledgements 290 I appreciate Masaki Fujimoto and Oku Kazuho for valuable feedbacks. 292 Author's Address 294 Hiroyuki Goto 295 GREE, inc 297 Email: hiroyuki.goto@gree.net