[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

QUIC                                                              K. Oku
Internet-Draft                                                    Fastly
Intended status: Experimental                                 C. Huitema
Expires: June 17, 2019                              Private Octopus Inc.
                                                       December 14, 2018


                    Authenticated Handshake for QUIC
              draft-kazuho-quic-authenticated-handshake-00

Abstract

   This document explains a variant of QUIC protocol version 1 that uses
   the ESNI Keys to authenticate the Initial packets thereby making the
   entire handshake tamper-proof.

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 http://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 June 17, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (http://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.




Oku & Huitema             Expires June 17, 2019                 [Page 1]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   2
   2.  Differences from QUIC version 1 . . . . . . . . . . . . . . .   3
     2.1.  Protocol Version Number . . . . . . . . . . . . . . . . .   3
     2.2.  The "QUIC-ESNI" TLS Extension . . . . . . . . . . . . . .   3
     2.3.  Initial Packet Protection . . . . . . . . . . . . . . . .   3
     2.4.  Version Negotiation Packet  . . . . . . . . . . . . . . .   4
     2.5.  Connection Close Packet . . . . . . . . . . . . . . . . .   4
     2.6.  Retry Packet  . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Using GCM to Authenticate Initial Packets . . . . . . . .   5
     3.2.  Use of Different QUIC Version Number  . . . . . . . . . .   6
       3.2.1.  Trial Decryption  . . . . . . . . . . . . . . . . . .   6
       3.2.2.  Rekeying at the Server's First Flight . . . . . . . .   6
     3.3.  No Support for Split Mode . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As defined in Secure Using TLS to Secure QUIC [QUIC-TLS], QUIC
   version 1 [QUIC-TRANSPORT] protects the payload of every QUIC packet
   using AEAD making the protocol injection- and tamper-proof, with the
   exception being the Initial packets.  Initial packets are merely
   obfuscated because there is no shared secret between the endpoints
   when they start sending the Initial packets against each other.

   However, when Encrypted Server Name Indication for TLS 1.3 [TLS-ESNI]
   is used, a shared secret between the endpoints can be used for
   authentication from the very first packet of the connection.

   This document defines a Packet Protection method for Initial packets
   that incorporates the ESNI shared secret, so that spoofed Initial
   packets will be detected and droped.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].






Oku & Huitema             Expires June 17, 2019                 [Page 2]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


2.  Differences from QUIC version 1

   The document describes the changes from QUIC version 1.

   Implementations MUST conform to the specifications of QUIC version 1
   unless a different behavior is defined in this document.

2.1.  Protocol Version Number

   The long header packets exchanged using this specification carry the
   QUIC version number of 0xXXXXXXXX (TBD).

2.2.  The "QUIC-ESNI" TLS Extension

   The QUIC-ESNI TLS Extension indicates the versions of the QUIC
   protocol that the server supports.  The values in the extension
   SHOULD be identical to what would be included in the Version
   Negotiation packet.

      struct {
          uint32 supported_versions<4..2^16-4>;
      } QUIC_ESNI;

   A server willing to accept QUIC connections using this specification
   MUST publish ESNI Resource Records that contain the QUIC_ESNI
   extension including the QUIC version number 0xXXXXXXXX.

   A client MUST NOT initiate a connection establishment attempt
   specified in this document unless it sees a compatible version number
   in the QUIC_ESNI extension of the ESNI Resource Record advertised by
   the server.

2.3.  Initial Packet Protection

   Initial packets are encrypted and authenticated differently from QUIC
   version 1.

   AES [AES] in counter (CTR) mode is used for encrypting the payload.
   The key and iv being used are identical to that of QUIC version 1.

   HMAC [RFC2104] is used for authenticating the header.  The message
   being authenticated is the concatenation of the packet header without
   Header Protection and the payload in cleartext.  The underlying hash
   function being used is the one selected for encrypting the Encrypted
   SNI extension.  The HMAC key is calculated using the following
   formula:





Oku & Huitema             Expires June 17, 2019                 [Page 3]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


   hmac_key = HKDF-Expand-Label(Zx, "quic initial auth", Hash(ESNIContents),
                                digest_size)

   The first sixteen (16) octets of the HMAC output replaces the
   authentication tag of QUIC version 1.

   Other types of packets are protected using the Packet Protection
   method defined in QUIC version 1.

2.4.  Version Negotiation Packet

   A client MUST ignore Version Negotiation packets.  When the client
   gives up of establishing a connection, it MAY report the failure
   differently based on the receipt of (or lack of) Version Negotiation
   packets.

2.5.  Connection Close Packet

   A Connection Close packet shares a long packet header with a type
   value of 0x3 with the Retry packet.  The two types of packets are
   identified by the lower 4-bits of the first octet.  The packet is a
   Connection Close packet if all the bits are set to zero.  Otherwise,
   the packet is a Retry packet.

    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
   +-+-+-+-+-+-+-+-+
   |1|1| 3 |   0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Version (32)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |DCIL(4)|SCIL(4)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Destination Connection ID (0/32..144)         ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Connection ID (0/32..144)            ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Error Code (16)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (: #connection-close-format title="Connection Close Packet")

   A Connection Close packet is sent by a server when a connection error
   occurs prior to deriving the HMAC key.  In all other conditions,
   connection close MUST be signalled using the CONNECTION_CLOSE frame.

   A client that receives a Connection Close packet before an Initial
   packet SHOULD retain the error code, and continue the connection



Oku & Huitema             Expires June 17, 2019                 [Page 4]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


   establishment attempt as if it did not see the packet.  When the
   attempt times out, it MAY assume that the error code was a legitimate
   value sent by the server.  A client MAY ignore Connection Close
   packets.

2.6.  Retry Packet

   A client SHOULD send an Initial packet in response to each Retry
   packet it receives.  Payload of the CRYPTO frame contained in the
   resent Initial packets MUST be identical to that of the Initial
   packet that triggered the retry.  When the client does not receive a
   valid Initial packet after a handshake timeout, it SHOULD send at
   least one Initial packet containing one of the tokens that it has
   received.  Unless the packet gets lost, the retransmission would
   trigger the server to send either a valid Initial packet or a Retry
   packet.

   To a server, the behavior of a client under attack would look like it
   is aggressively retransmitting Initial packets, some of them
   containing invalid tokens.

   Therefore, a server MUST NOT terminate the connection when it
   receives an Initial packet that contains an invalid token.  Instead,
   it SHOULD either process the packet as if it did not contain a token,
   or send a Retry.

   A client MUST ignore Retry packets received anterior to an Initial
   packet that successfully authenticates.

3.  Considerations

3.1.  Using GCM to Authenticate Initial Packets

   An alternative approach to using the combination of AES-CTR and HMAC
   is to continue using AES-GCM.  In such approach, the additional
   authenticated data (AAD) will incorporate the ESNI shared secret to
   detect spoofed or broken packets.

   A server that receives an Initial packet for a new connection will at
   first decrypt the payload using AES-CTR, derive ESNI shared secret
   from the Hello message being contained, then use that to verify the
   GCM tag.

   The benefit of the approach is that we will have less divergence from
   QUIC version 1.  The downside is that the authentication algorithm
   would be hard-coded to GCM, and that some AEAD APIs might not provide
   an interface to handle input in this particular way.




Oku & Huitema             Expires June 17, 2019                 [Page 5]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


   We can also consider adding a small checksum to the Initial packets
   so that the server can determine if the packet is corrupt.  The
   downside is that the endpoints would be required to calculate the
   checksum for Initial packets that carry server's messages and ACKs as
   well, even though the correctness of the packet can be verified using
   the ordinary procedure of AEAD.

3.2.  Use of Different QUIC Version Number

   For this specification, use of a different QUIC version number is not
   expected to have negative impact on user-experience by raising the
   chance of version negotiation, because version negotiation finishes
   before the client sends it's first packet.

   Use of Encrypted SNI will stick out more, because it can be
   identified by observing a different version number in the long header
   packet rather than by decrypting the Initial packet to see if the
   Encrypted SNI extension is in use.

   The subsections below discuss alternative approaches that do not
   change the version number of QUIC.

3.2.1.  Trial Decryption

   It is possible to use the proposed Packet Protection method without
   changing the version number.  The difference from the recommended
   method is that the server would be required to do "trial decryption."

   However, it is not as bad as it sounds, because authentication
   failure in AES-GCM decryption is typically reported after the
   ciphertext is decrypted.

   When accepting a new connection, a QUIC server can at first decrypt
   the Initial packet using AES-GCM.  The packet is a ordinary QUIC
   version 1 packet if it is successfully authenticated.  Otherwise, the
   server will feed the decrypted payload (which would be available
   anyways) assuming that it contains a ClientHello message, and if the
   TLS stack successfully processes the message returning the handshake
   keys and the ESNI shared key, verify the HMAC to see if the packet
   authenticates.  If it does, the server creates a new connection
   context and responds with an Initial packet.

3.2.2.  Rekeying at the Server's First Flight

   Another approach is to use the Packet Protection method of QUIC
   version 1 for client's first flight, while using the proposed method
   for all other Initial packets.




Oku & Huitema             Expires June 17, 2019                 [Page 6]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


   The benefit of this approach is that trial decryption can be avoided.

   The downside is that a man-on-the-side attacker can stitch the
   Encrypted SNI extension that the client has sent with anything it
   wants to construct a spoofed packet, then race it to the server.

   The server would be required to consider Initial packets containing
   non-identical ClientHello messages as belonging to different
   connection establishment attempts.

   The design will also have negative performance impact on connections
   with high latency.  This is because QUIC expects clients to
   retransmit the Initial packets when the latency is above 250
   milliseconds.  However, the requirement that the server rekeys the
   Initial secret when receiving the first Initial packet means that the
   retransmitted Initial packets would become undecryptable and
   therefore be deemed lost by the client, reducing the client's
   congestion window size.

3.3.  No Support for Split Mode

   Under the design discussed in this document, it is impossible to use
   an unmodified QUIC server as a backend server in "Split Mode"
   ([TLS-ESNI]; section 3) due to the following two reasons:

   o  Access to initial_auth_secret is required for generating and
      validating Initial packets.  However, the backend server, not
      knowing the ESNI private key, cannot calculate the secret.

   o  The client-facing server cannot continue forwarding packets to the
      correct destination when there is a change in Connection ID mid-
      connection.

   To address the issues, we might consider specifying a protocol that
   will be used between the client-facing server and the backend server
   for communicating the initial_auth_secret and the spare Connection
   IDs.  Note that such protocol can be lightweight, assuming the
   communication between the two servers will be over a virtual private
   network.  Such assumption can be made because the backend server
   cannot operate QUIC without access to the source address-port tuple
   of the packets that the client has sent.

4.  Security Considerations

   TBD






Oku & Huitema             Expires June 17, 2019                 [Page 7]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


5.  IANA Considerations

   TBD

6.  Acknowledgements

   TBD

7.  Normative References

   [AES]      "Advanced encryption standard (AES)", National Institute
              of Standards and Technology report,
              DOI 10.6028/nist.fips.197, November 2001.

   [QUIC-TLS]
              Thomson, M., Ed. and S. Turner, Ed., "Using Transport
              Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
              tls-16 (work in progress), October 2018.

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", draft-ietf-quic-
              transport-16 (work in progress), October 2018.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
              editor.org/info/rfc2104>.

   [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/info/rfc2119>.

   [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>.

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

Authors' Addresses







Oku & Huitema             Expires June 17, 2019                 [Page 8]


Internet-Draft      Authenticated Handshake for QUIC       December 2018


   Kazuho Oku
   Fastly

   Email: kazuhooku@gmail.com


   Christian Huitema
   Private Octopus Inc.

   Email: huitema@huitema.net









































Oku & Huitema             Expires June 17, 2019                 [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/