Internet DRAFT - draft-goto-httpbis-preload-frame

draft-goto-httpbis-preload-frame







Network Working Group                                            H. Goto
Internet-Draft                                                 GREE, inc
Expires: July 12, 2019                                  January 08, 2019


                      The PRELOAD Frame Extension
                  draft-goto-httpbis-preload-frame-01

Abstract

   A server can send application data before a client sends data if they
   are using HTTP/2 with TLS1.3 or HTTP/3.  Indicating loading of
   necessary resources without waiting for the first request from the
   client may improve page loading performance.  This document defines
   the PRELOAD frame, which is a new extension frame that allows the
   server to notify of preload information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 July 12, 2019.

Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Goto                      Expires July 12, 2019                 [Page 1]

Internet-Draft                PRELOAD Frame                 January 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  PRELOAD Frame Overview  . . . . . . . . . . . . . . . . .   2
   2.  PRELOAD Frame Extension . . . . . . . . . . . . . . . . . . .   3
     2.1.  Using Link Header . . . . . . . . . . . . . . . . . . . .   4
     2.2.  HTTP/2  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2.1.  Frame Format  . . . . . . . . . . . . . . . . . . . .   4
     2.3.  HTTP/3  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Padding . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Error Code  . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   A server can send application data before a client sends application
   data if they are using HTTP/2[RFC7540] with TLS1.3[RFC8446] or
   HTTP/3[HTTP3].  But in HTTP/2 [RFC7540] the server only sends a
   SETTINGS frame as the server connection preface.  After that, it can
   send an HTTP response (including a 103 status code [RFC8297]) or
   server push only after receiving a request from the client.

   Indicating loading of necessary resources without waiting for the
   first request from the client may improve page loading performance.
   In order to make effective use of opportunities for the server to
   transmit application data for the first time, this document defines a
   PRELOAD frame; a new extension frame which enables the server to
   notify preload [Preload] information from the server.

1.1.  PRELOAD Frame Overview

   A PRELOAD frame can be sent with the application data that the server
   first transmits after the TLS 1.3 handshake.  The motivation of the
   PRELOAD frame is to make effective use of that transmission
   opportunity.

   The flow is as follows:








Goto                      Expires July 12, 2019                 [Page 2]

Internet-Draft                PRELOAD Frame                 January 2019


      Client                                               Server

      ClientHello             -------->
                                                    ServerHello
                                          {EncryptedExtensions}
                                          {CertificateRequest*}
                                                 {Certificate*}
                                           {CertificateVerify*}
                                                     {Finished}
                              <--------     [Application Data*]
                                              - SETTINGS
                                                (as Connection Preface)
                                              - PRELOAD
      {Finished}              -------->
      [Application Data]      -------->
        -  Connection Preface
        -  SETTINGS
        -  SETTINGS(ACK)
        -  HEADERS

                 '-'  Indicates HTTP/2 messages in Application Data.

                 Figure 1: OverView in HTTP/2 with TLS1.3

   After sending ServerHello of the TLS 1.3 handshake, the server sends
   a SETTINGS frame which is the server connection preface as TLS
   Application Data.  Subsequently, The server uses the SNI to identify
   the domain which the client wants to send an HTTP request.  The
   server can indicate preload in the PRELOAD frame for resources
   commonly used in that domain.  The client parses the PRELOAD frame
   and fetches the resource if it does not have cache for that resource.
   The semantics are the same as those defined in Preload[Preload].  If
   the client does not support a PRELOAD frame, it is simply ignored.

2.  PRELOAD Frame Extension

   Preload Frame Extension does not define a new format to convey
   preload information.  It uses the already defined Link HTTP header.
   However, it is not an HTTP response carried in this frame, and it is
   not associated with an HTTP request to an authority.  Therefore, the
   server MUST store only information about Preload[Preload] in this
   frame to avoid confusion in the implementation.

   Open Question: In the above, the PRELOAD frame is allowed to carry
   only information about Preload[Preload].  However, adapting security
   policies such as HSTS more quickly improves security.  But it is not
   associated with any specific request.  It is possible to indicate the
   domain to which the policy applies by specifying the target domain



Goto                      Expires July 12, 2019                 [Page 3]

Internet-Draft                PRELOAD Frame                 January 2019


   (matching with SNI's HostName) in the PRELOAD frame.  Does this
   introduce any semantics or security issues?

   Since this frame does not represent an HTTP response, it does not
   have a context for header compression, is not possible to use a
   dynamic table for encoding or decoding HTTP responses.  Since the
   Preload[Preload] frame may be ignored by the received endpoint the
   dynamic header table MUST NOT be updated.

   Open Question: Would it benefit if PRELOAD frames could use separate
   dynamic header tables?

   This document defines extensions for HTTP/2 and HTTP/3 separately.

2.1.  Using Link Header

   In preload using Link header [RFC8288], resources can be specified by
   relative path.  However, the PRELOAD frame is not associated with an
   HTTP request to a particular authority.  Therefore, the server SHOULD
   specify a complete URI for the specification of resources within the
   Preload.

   Link: <https://example.com/app/script.js>; rel=preload; as=script

                    Figure 2: Link preload type example

2.2.  HTTP/2

2.2.1.  Frame Format

   A PRELOAD frame (type=TBD) carries a Header Block containing Preload
   information.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Block (*)                      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: PRELOAD frame payload

   The payload of the PRELOAD frame contains the following fields:

   o  Header Block: HTTP header represented by HPACK [RFC7541]

   The PRELOAD frame does not define any flags.





Goto                      Expires July 12, 2019                 [Page 4]

Internet-Draft                PRELOAD Frame                 January 2019


   Endpoints that do not support this extension simply ignore reception
   of this PRELOAD frame.

   This PRELOAD frame can be sent only from the server on stream ID 0.
   This frame MUST be ignored if the server receives this frame or if
   the client receives this frame with a different stream ID.  If a
   client receives a PRELOAD frame that is too long, it SHOULD ignore
   that.

   A parse error of the Header Block in the PRELOAD frame MAY be treated
   as COMPRESSION_ERROR, or MAY simply ignore this frame.

   The server can send a PRELOAD frame before receiving
   SETTINGS_MAX_HEADER_LIST_SIZE from the client.  PRELOAD frames that
   are too long should not be sent.

2.3.  HTTP/3

   The PRELOAD frames (type=TBD) can be used with HTTP/3.  The format is
   the same as described for Section 2.2.1, but the payload Header Block
   uses QPACK [QPACK] instead of HPACK.  This frame MUST NOT update the
   dynamic header table.

   The PRELOAD frame can only be sent from the server on the control
   stream.  This frame MUST be ignored if the server receives this frame
   or if the client receives this frame with a different streams.  If a
   client receives a PRELOAD frame that is too long, it SHOULD ignore
   that.

2.4.  Padding

   If the length of the PRELOAD frame changes depending on the SNI used,
   observation the first application data to make the hostname inferable
   on the path.  This should be considered when encrypting SNI with
   ENSI[TLS-ESNI].

   (TBD) Use Padding

2.5.  Error Code

   (TBD)

   Note: Should a new Error Code be defined?








Goto                      Expires July 12, 2019                 [Page 5]

Internet-Draft                PRELOAD Frame                 January 2019


3.  Security Considerations

   The server can consume client resources by sending a large PRELOAD
   frame.  Therefore, clients should ignore PRELOAD frames that are too
   large.

4.  IANA Considerations

   This specification adds an entry to the "HTTP/2 Frame Type" registry.

   o  Frame Type: PRELOAD

   o  Code: TBD

   o  Specification: This draft

5.  References

5.1.  Normative References

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
              <https://www.rfc-editor.org/info/rfc7541>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/info/rfc8288>.

   [RFC8297]  Oku, K., "An HTTP Status Code for Indicating Hints",
              RFC 8297, DOI 10.17487/RFC8297, December 2017,
              <https://www.rfc-editor.org/info/rfc8297>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

5.2.  Informative References

   [HTTP3]    Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
              (HTTP/3)", draft-ietf-quic-http-latest (work in progress).

   [Preload]  Grigorik, I., "Preload", n.d.,
              <https://w3c.github.io/preload/>.



Goto                      Expires July 12, 2019                 [Page 6]

Internet-Draft                PRELOAD Frame                 January 2019


   [QPACK]    Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
              Header Compression for HTTP/3", draft-ietf-quic-qpack-
              latest (work in progress).

   [TLS-ESNI]
              Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
              "Encrypted Server Name Indication for TLS 1.3", draft-
              ietf-tls-esni-latest (work in progress), n.d..

Acknowledgements

   I appreciate Masaki Fujimoto and Oku Kazuho for valuable feedbacks.

Author's Address

   Hiroyuki Goto
   GREE, inc

   Email: hiroyuki.goto@gree.net
































Goto                      Expires July 12, 2019                 [Page 7]