[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
quic                                                             M. Duke
Internet-Draft                                         F5 Networks, Inc.
Intended status: Standards Track                              4 May 2021
Expires: 5 November 2021


                     Protected QUIC Initial Packets
                  draft-duke-quic-protected-initial-00

Abstract

   QUIC encrypts its Initial Packets using keys derived from well-known
   constants, meaning that observers can inspect the contents of these
   packets and successfully spoof them.  This document proposes a new
   version of QUIC that encrypts Initial Packets more securely by
   leveraging a Public Key distributed via the Domain Name System (DNS)
   or other out-of-band system.

   Discussion of this work is encouraged to happen on the QUIC IETF
   mailing list quic@ietf.org or on the GitHub repository which contains
   the draft: https://github.com/martinduke/quic-version-aliasing.

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 5 November 2021.

Copyright Notice

   Copyright (c) 2021 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



Duke                     Expires 5 November 2021                [Page 1]


Internet-Draft              protected-initial                   May 2021


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Key Configuration . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Version Number  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Key Derivation Labels . . . . . . . . . . . . . . . . . . . .   4
   6.  Initial Packet Header . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Encryption Context  . . . . . . . . . . . . . . . . . . .   5
   7.  Client Packet Protection Procedure  . . . . . . . . . . . . .   5
   8.  Server Packet Protection Procedure  . . . . . . . . . . . . .   6
   9.  Retry Integrity Tag . . . . . . . . . . . . . . . . . . . . .   6
   10. Version Negotiation . . . . . . . . . . . . . . . . . . . . .   7
   11. Intermediaries  . . . . . . . . . . . . . . . . . . . . . . .   7
   12. Applicability . . . . . . . . . . . . . . . . . . . . . . . .   7
   13. Security and Privacy Considerations . . . . . . . . . . . . .   7
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     15.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     15.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   DISCLAIMER: This draft is a preliminary proposal with insufficient
   security analysis.  It should not be used in production systems.

   The QUIC Initial Packet [QUIC-TRANSPORT] is encrypted using a key
   derived from the Destination Connection ID in the packet cleartext
   and a well-known salt (see Section 5.2 of [QUIC-TLS]).  Section 7 of
   that draft describes security vulnerabilities resulting from the
   resulting lack of authentication.

   This also has privacy implications, as observers can decrypt the
   packet and inspect the contents, which contain the TLS Client Hello
   and Server Hello Messages ([RFC8446]).  The former contains QUIC
   Transport Parameters, which reveal even more information about the
   traffic.








Duke                     Expires 5 November 2021                [Page 2]


Internet-Draft              protected-initial                   May 2021


   Furthermore, packets vulnerable to deep inspection create an
   ossification vector.  Intermediaries that expect the contents of
   these messages to match a certain format and template might drop
   packets that do not, preventing the use of new protocol extensions or
   improved security protocols.

   This document proposes a new version of QUIC where the client obtains
   a public key generated by the server and uses it to encrypt a shared
   secret, sent in the Initial packet header, that both endpoints can
   then use to protect Initial packets.

   This mechanism leverages the public key that would be distributed via
   DNS (or other out-of-band mechanism) to support Encrypted Client
   Hello [ECHO].  That design uses Hybrid Public Key Exchange (HPKE)
   ([HPKE] to authenticate some HPKE configuration information and the
   "outer client hello" that is in plaintext, while encrypting the
   "inner client hello" that contains privacy-sensitive information.
   This document uses the widespread configuration that will exist if
   ECHO is widely deployed, but only sends the subset of information
   necessary to seed the QUIC key generation process.

   This design is meant to be complimentary with QUIC Version Aliasing
   [VERSION-ALIASING].  Version Aliasing does not require coordination
   with DNS or costly asymmetric encryption, and also hinders
   ossification of the QUIC version field.  However, it does not protect
   the first connection between the client and server, and can be
   difficult to coordinate with intermediaries like client-facing load
   balancers.  This document addresses those use cases.

   Unlike [ECHO], Protected Initial Packets protect the entire packet
   payloads that contain the Client Hello and Server Hello, instead of
   just part of the Client Hello.

   The version of QUIC described in this specification is identical to
   QUIC version 1 [QUIC-TRANSPORT] except where described in this
   document.

2.  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 RFC 2119 [RFC2119].









Duke                     Expires 5 November 2021                [Page 3]


Internet-Draft              protected-initial                   May 2021


3.  Key Configuration

   The client obtains the Encrypted ClientHello Configuration
   (ECHConfig) described in Section 4 of [ECHO], which provides the
   context that allows protection of Initial packets.  The ECHConfig is
   available via a DNS record or other out-of- band system.

4.  Version Number

   The version field in long headers is TBD.  Note: for interoperability
   exercises, use the provisional value 0xff454900.

5.  Key Derivation Labels

   The labels used to derive keying material in [QUIC-TLS] change from
   "quic key", "quic iv", "quic hp", and "quic ku" to "quicpi key",
   "quicpi iv", "quicpi hp", and "quicpi ku", respectively.

6.  Initial Packet Header

   The figure below is presented in the format from [QUIC-TRANSPORT],
   and adds a variable-length Encryption Context preceded by a length
   field:

   Initial Packet {
      Header From (1) = 1,
      Fixed Big (1) = 1,
      Long Packet Type (2) = 0,
      Reserved Bits (2),
      Packet Number Length (2),
      Version (32),
      Destination Connection ID Length (8),
      Destination Connection ID (0..160),
      Source Connection ID Length (8),
      Source Connection ID (0..160),
      Encryption Context Length (8),
      Encryption Context (..),
      Token Length (i),
      Token (..),
      Length (i),
      Packet Number (8..32),
   }

   Encryption Context Length: A variable-length integer specifying the
   length of the encryption context, in bytes.  Servers MUST set this
   field to zero; a client that receives a non-zero length MUST either
   discard the packet or generate a connection error of type
   PROTOCOL_VIOLATION.



Duke                     Expires 5 November 2021                [Page 4]


Internet-Draft              protected-initial                   May 2021


   If a client has received a valid Server Initial packet, it SHOULD set
   this field to zero.  Until then, clients MUST use a nonzero value.
   If a client Initial packet has a zero Encryption Context Length, and
   the server has not sent an Initial Packet, the server MUST either
   discard the packet or generate a connection error of type
   PROTOCOL_VIOLATION.

6.1.  Encryption Context

   The encryption context, if nonzero length, has the following format:

   Encryption Context {
       Config ID (8),
       Encapsulated Secret (..),
   }

   The client obtains the Config ID (an 8-bit unsigned integer) from the
   ECHConfig.  It corresponds to a public key and Key Encapsulation
   Mechanism (KEM) that are not sent over the wire.

   The Encapsulated Secret is HPKE encapsulated.  Its length is inferred
   from the Encryption Context Length field.

7.  Client Packet Protection Procedure

   An client extracts the public key pkR and uses it to generate a
   shared_secret:

   pkR = Deserialize(ECHConfig.contents.public_key)
   shared_secret, enc = Encap(pkR)
   initial_secret = HKDF-Extract(shared_secret,
           client_dst_connection_id || ECHConfig)

   enc is the Encapsulated Secret, and is written into that subfield of
   the Encryption Context Field.

   The initial_secret above is used to generate client_initial_secret
   and server_initial_secret as described in Section 5.2 of [QUIC-TLS].

   When applying header protection, the Context Length and Encryption
   Context are not Protected.

   Additionally, the client bitwise-XORs the first eight octets of the
   Destination Connection ID with the first eight octets of the public
   key to form a 64 bit unsigned integer.  This integer is added to the
   packet length, modulo 2^62, and written into the packet length field
   instead of the actual packet length.




Duke                     Expires 5 November 2021                [Page 5]


Internet-Draft              protected-initial                   May 2021


   This derivation is performed once per connection.  Subsequent Initial
   Packets use the same keys and the same offset to the packet number,
   regardless of additional Encryption Context fields or changed
   connection IDs.

8.  Server Packet Protection Procedure

   The server reads the Config ID and Encapsulated Secret (enc) from the
   Initial Packet.  It looks up its private key (skR) associated with
   the Config ID.

   Prior to any other operations, including sending any Retry packet,
   the server bitwise-XORs the first eight octets of its public key and
   the destination connection ID and subtracts this from the value in
   the packet length field, modulo 2^62, to find the true packet length.

   Any result that exceeds the size of the received datagram indicates
   with high assurance that the client's received ECHConfig does not
   match the server's state, possibly due to a misconfiguration.  The
   probability this test results in a false negative, when an incorrect
   key generates a result less than the datagram size, is typically less
   than 1 in 2^51.  The server MUST discard the packet and SHOULD send a
   Version Negotiation packet that does not advertise the current QUIC
   version, as the endpoints do not have the necessary shared state to
   use QUIC Protected Initials.

   Otherwise, the server generates the Initial secrets:

   shared_secret = Decap(enc, skR)
   initial_secret = HKDF-Extract(shared_secret,
           client_dst_connection_id || ECHConfig)

   The server now has sufficient context to send a Retry packet and MAY
   choose to do so at this point (see Section 9).  If not, it decrypts
   the Initial packet.

   The remainder is identical to the client procedure.

9.  Retry Integrity Tag

   The Retry packet is identical to QUIC version 1, except that the
   secret key K and nonce N (see Sec 5.8 of [QUIC-TLS]) are derived from
   the shared_secret instead of the secret provided there.  Also, the
   labels are as described in Section 5.







Duke                     Expires 5 November 2021                [Page 6]


Internet-Draft              protected-initial                   May 2021


10.  Version Negotiation

   Endpoints that support QUIC Protected Initials MUST support at least
   one other version of QUIC (in case the endpoints cannot agree on the
   ECHConfig), and therefore MUST also support
   [I-D.ietf-quic-version-negotiation].

   In contrast to Section 5 of that document, clients MUST be prepared
   to receive a version negotiation packet that contains QUIC Protected
   Initial, and then receive a second version negotiation packet that
   does not, should the attempt to identify a common ECHConfig fail.

   Servers MAY continue to advertise QUIC Protected Initials in its
   Server Handshake Version Information, even if shared secret
   extraction failed, to avoid tracking state as to which clients have
   failed such extraction.  This does not effect the Version Downgrade
   mechanism, which is executed by servers.

   Note that QUIC version 1 is not compatible with QUIC Protected
   Initials, as it does not contain the information necessary to
   generate subsequent Initial packets correctly.  Conversely, QUIC
   Protected Initials are compatible with QUIC version 1.  However,
   since the versions have identical properties after the Initial packet
   exchange, there is little value in such a trasition.

11.  Intermediaries

   Intermediaries that rely on the contents of the Client Hello (e.g., a
   load balancer that routes between servers with the same IP address
   based on the SNI field in the Client Hello) MUST have access to the
   ECHConfig and the corresponding Private Keys, as described in
   Section 3.1 of [ECHO], to function properly.

12.  Applicability

   This version of QUIC provides no change from QUIC version 1 relating
   to the capabilities available to applications.  Therefore, all
   Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints
   specified to operate over QUICv1 can also operate over this version
   of QUIC.

13.  Security and Privacy Considerations

   Sections 10.2, 10.3, 10.4, and 10.6 of [ECHO] apply to QUIC Protected
   Initials as well.

   Sections 7.2, 7.3, 7.7, and 7.8 of [VERSION-ALIASING] are also
   applicable.



Duke                     Expires 5 November 2021                [Page 7]


Internet-Draft              protected-initial                   May 2021


14.  IANA Considerations

   This document request that IANA add the following entry to the QUIC
   version registry:

   Value: TBD

   Status: permanent

   Specification: This document

   Change Controller: IETF

   Contact: QUIC WG

15.  References

15.1.  Normative References

   [ECHO]     Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-10, 8 March 2021,
              <https://www.ietf.org/archive/id/draft-ietf-tls-esni-
              10.txt>.

   [HPKE]     Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
              "Hybrid Public Key Encryption", Work in Progress,
              Internet-Draft, draft-irtf-cfrg-hpke-08, 15 February 2021,
              <https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-
              08.txt>.

   [I-D.ietf-quic-version-negotiation]
              Schinazi, D. and E. Rescorla, "Compatible Version
              Negotiation for QUIC", Work in Progress, Internet-Draft,
              draft-ietf-quic-version-negotiation-03, 4 February 2021,
              <https://www.ietf.org/archive/id/draft-ietf-quic-version-
              negotiation-03.txt>.

   [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
              Work in Progress, Internet-Draft, draft-ietf-quic-tls-34,
              14 January 2021, <https://www.ietf.org/archive/id/draft-
              ietf-quic-tls-34.txt>.









Duke                     Expires 5 November 2021                [Page 8]


Internet-Draft              protected-initial                   May 2021


   [QUIC-TRANSPORT]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Work in Progress, Internet-Draft,
              draft-ietf-quic-transport-34, 14 January 2021,
              <https://www.ietf.org/archive/id/draft-ietf-quic-
              transport-34.txt>.

15.2.  Informative References

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

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/info/rfc7301>.

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

   [VERSION-ALIASING]
              Duke, M., "QUIC Version Aliasing", Work in Progress,
              Internet-Draft, draft-duke-quic-version-aliasing-04, 30
              October 2020, <https://www.ietf.org/archive/id/draft-duke-
              quic-version-aliasing-04.txt>.

Author's Address

   Martin Duke
   F5 Networks, Inc.

   Email: martin.h.duke@gmail.com
















Duke                     Expires 5 November 2021                [Page 9]