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

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


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

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 8 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 8 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
     1.1.  Relationship to ECH and Version Aliasing  . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Key Configuration . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Version Number  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Key Derivation Labels . . . . . . . . . . . . . . . . . . . .   5
   6.  Initial Packet Header . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Encryption Context  . . . . . . . . . . . . . . . . . . .   6
   7.  Client Packet Protection Procedure  . . . . . . . . . . . . .   6
   8.  Server Packet Protection Procedure  . . . . . . . . . . . . .   7
   9.  Retry Integrity Tag . . . . . . . . . . . . . . . . . . . . .   8
   10. Fallback  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   11. New Transport Parameters  . . . . . . . . . . . . . . . . . .   9
     11.1.  public_key_failed  . . . . . . . . . . . . . . . . . . .   9
     11.2.  ECHConfig  . . . . . . . . . . . . . . . . . . . . . . .  10
   12. Intermediaries  . . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Client-Facing Server . . . . . . . . . . . . . . . . . .  10
     12.2.  Back-End Server  . . . . . . . . . . . . . . . . . . . .  11
   13. Applicability . . . . . . . . . . . . . . . . . . . . . . . .  11
   14. Security and Privacy Considerations . . . . . . . . . . . . .  11
     14.1.  Key Loss and Version Downgrade . . . . . . . . . . . . .  11
     14.2.  Initial Packet Injection . . . . . . . . . . . . . . . .  13
     14.3.  Retry Injection  . . . . . . . . . . . . . . . . . . . .  13
     14.4.  Less Trial Decryption  . . . . . . . . . . . . . . . . .  14
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     15.1.  QUIC Version Registry  . . . . . . . . . . . . . . . . .  14
     15.2.  QUIC Transport Parameter Registry  . . . . . . . . . . .  14
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     16.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  16
     A.1.  since draft-duke-quic-protected-initials-00 . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

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






Duke                     Expires 8 November 2021                [Page 2]


Internet-Draft              protected-initial                   May 2021


   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.

   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.

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

1.1.  Relationship to ECH and Version Aliasing

   Encrypted Client Hello [ECHO] and QUIC Version Aliasing
   [VERSION-ALIASING] also exist in the solution space of concealing
   parts of the Initial packet exchange from observers.  The following
   table summarizes the advantages and disadvantages of each.








Duke                     Expires 8 November 2021                [Page 3]


Internet-Draft              protected-initial                   May 2021


     +===================+==============+=============+=============+
     | Property          |     ECH      |  Protected  |   Version   |
     |                   |              |   Initials  |   Aliasing  |
     +===================+==============+=============+=============+
     | Fields Protected  |   Some of    | All Initial | All Initial |
     |                   | Client Hello |   Payloads  |   Payloads  |
     +-------------------+--------------+-------------+-------------+
     | Delay when server |    1 RTT     |    2 RTT    |    2 RTT    |
     | loses its keys    |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | Works with TLS    |     Yes      |      No     |      No     |
     | over TCP          |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | First-connection  |     Yes      |     Yes     |      No     |
     | protection        |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | No trial          |      No      |     Yes     |     Yes     |
     | decryption        |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | Prevents Initial  |      No      |     Yes     |     Yes     |
     | packet injection  |              |             |             |
     | attacks           |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | Symmetric         |      No      |      No     |     Yes     |
     | Encryption Only   |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | Greases the       |      No      |      No     |     Yes     |
     | Version Field     |              |             |             |
     +-------------------+--------------+-------------+-------------+
     | Prevents Retry    |      No      |      No     |     Yes     |
     | injection attacks |              |             |             |
     +-------------------+--------------+-------------+-------------+

                                 Table 1

   The more complex properties in the table are discussed in Section 14.

   Both ECH and Protected Initials are complimentary with Version
   Aliasing: they provide a computationally expensive way to protect
   parts of the Initial packet during the first connection between
   client and server, after which Version Aliasing can protect future
   exchanges with several additional desirable properties.

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 8 November 2021                [Page 4]


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 8 November 2021                [Page 5]


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),
       SCKDF (16),
       SCAEADID (16),
       Encapsulated Secret (..),
   }

   Config ID: An 8-bit integer identifying the configuration parameters,
   obtained from the ECHConfig.  This ID implicitly identifies the
   public key, Key Encapsulation Mechanism, and the set of symmetric
   suites from which the following fields are selected.

   SCKDF: Symmetric Cipher Key Derivation Function.  The client selects
   this from the cipher suites listed in the ECHConfig.  This is the
   cipher used to encrypt the Initial Packet.  The values are listed in
   Section 7.2 of [HPKE].  All endpoints MUST support HKDF-SHA256
   (0x0001), which is used for QUIC Version 1 Initial packets.

   SCAEADID: Symmetric Cipher Key Derivation Function.  The client
   selects this from the cipher suites listed in the ECHConfig.  This is
   the cipher used to encrypt the Initial Packet.  The values are listed
   in Section 7.3 of [HPKE]. all endpoints MUST support AES-128-GCM
   (0x0001), which is used for QUIC Version 1 Initial packets.

   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)




Duke                     Expires 8 November 2021                [Page 6]


Internet-Draft              protected-initial                   May 2021


   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.

   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 (see Section 10).

   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.



Duke                     Expires 8 November 2021                [Page 7]


Internet-Draft              protected-initial                   May 2021


   The remainder is identical to the client procedure.  All server-
   generated Initial packets use the keys generated in this process.

9.  Retry Integrity Tag

   The Retry packet is identical to QUIC version 1, except that the key
   and nonce used for the Retry Integrity Tag (Sec 5.8 of
   [I-D.ietf-quic-tls] change to:

secret = 0xe453a2e22377289f08a4458ee1c9a90a4e39696e026372ffc33190b8de5a0123
key = 0xbe0c690b9f66575a1d766b54e368c84e
nonce = 0x461599d35d632bf2239825bb

10.  Fallback

   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 [QUIC-VN].

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

   When decoding a client Initial packet length, the server may conclude
   that the client does not have the server's correct configuration (see
   Section 8).  In this case, it SHOULD send a Version Negotiation
   packet and that packet MUST include the version the client attempted
   to connect with.  This contradicts the usual semantics in Section 5
   of [QUIC-VN], and clients that support Protected Initials MUST accept
   these packets, as well as further transport parameters that advertise
   support for Protected Initials.

   Because of the vulnerabilities described in Section 14.1, additional
   measures are required to protect against an attacker forcing version
   downgrade.  If the client chooses to attempt a reconnection, it MUST
   choose a version listed in the Version Negotiation packet that does
   not include Protected Initials.

   When connecting with that version, the client MUST include the
   public_key_failed transport parameter with the Config ID and public
   key it attempted to use.







Duke                     Expires 8 November 2021                [Page 8]


Internet-Draft              protected-initial                   May 2021


   The server checks the Config ID and public key to see if it should
   successfully process a Protected Initial with these parameters.  If
   it would have, it MUST terminate the connection with a
   VERSION_NEGOTIATION_ERROR to indicate that there has been a downgrade
   attack.

   If the server would not have successfully decoded the packet with
   those parameters, it MUST send its own public_key_failed transport
   parameter to acknowledge the parameter was successfully processed.
   It MAY also send a ECHConfig transport parameter to allow use of
   Protected Initials in subsequent connections, a Version Aliasing
   transport parameter (see [VERSION-ALIASING]) to enable a different
   means of Initial Protection, both, or neither.

   If the client does not receive a public_key_failed transport
   parameter in response to sending a public_key_failed transport
   parameter, it MUST terminate the connection with a
   TRANSPORT_PARAMETER_ERROR.

11.  New Transport Parameters

11.1.  public_key_failed

   The system to detect version downgrade in [QUIC-VN] is insufficient
   to do so for Protection Initials (see Section 14.1).  The
   public_key_failed transport parameter solves this problem.  For
   details on use, see Section 10.

   Its provisional type is 0x706b66.

   When sent by a client, the content of the transport parameter is as
   follows:

   {
       Config ID (8),
       Public Key (..),
   }

   These fields are populated using the ECHConfig that the client
   attempted to use.  The length of the Public Key is inferred from the
   length field of the transport parameter.

   When sent by a server, the transport parameter has no value field.

   Endpoints MUST respond to a malformed transport parameter by closing
   the connection with a TRANSPORT_PARAMETER_ERROR.





Duke                     Expires 8 November 2021                [Page 9]


Internet-Draft              protected-initial                   May 2021


   Note that this transport parameter is always sent as a result of a
   fallback from a Protected Initial, and therefore in a connection of a
   different version.  Therefore, if received in a Protected Initial
   connection, the receiving endpoint MUST terminate the connection with
   a TRANSPORT_PARAMETER_ERROR.

11.2.  ECHConfig

   The ECHConfig transport parameter allows servers to directly provide
   clients a valid configuration.

   Its provisional type is 0x454348.

   Its format is equivalent to ECHConfigList, as defined in Section 4 of
   [ECHO].

   Note that, like public_key_failed, this transport parameter is sent
   in response to a failed attempt to use Protected Initials, and
   therefore only occurs in other versions of QUIC.

   If this transport parameter does not match this format, is received
   by a server, or is received in a connection that uses Protected
   Initials, the receiver MUST terminate the connection with a
   TRANSPORT_PARAMETER_ERROR.

12.  Intermediaries

   In the topology proposed in Section 3.1 of [ECHO], where a client-
   facing server has its own public name and potentially fronts a number
   of independent domains, only the client-facing server has the private
   keys.  Thus, it modifies incoming Initial Packets before forwarding
   to the back-end server.  The back-end server uses a modified
   technique for decrypting Initial packets.

   A common use case of this topology is a load balancer fronting
   multiple domains using the same IP address, which makes routing
   decisions based on the SNI in the Client Hello.

12.1.  Client-Facing Server

   If an incoming client Initial has a non-zero length Encryption
   Context field, the client-facing server MUST rewrite the Config ID
   field as zero, replaces the Encapsulated Secret with the shared
   secret in plaintext, and updates the Encryption Context Length
   accordingly.

   To avoid authentication failure, the client-facing server MUST re-
   encrypt the Initial packet with the new header as associated data.



Duke                     Expires 8 November 2021               [Page 10]


Internet-Draft              protected-initial                   May 2021


   Non-Initial packets, as well as Initial packets that have a zero-
   length Encryption Context, pass unmodified through the client-facing
   server.

   Note that client-facing servers cannot inspect any packet payloads
   except for Initial packets.

12.2.  Back-End Server

   Back-end servers use the plaintext shared secret to generate Initial
   keys.

   Back-end servers MUST have an up-to-date copy of the ECHConfigList
   the client- facing server is using, though it need not hold the
   private key, in order to properly process the relevant transport
   parameters.

   In all other respects they operate as Protected Initial servers.

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

14.  Security and Privacy Considerations

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

   Section 7.8 of [VERSION-ALIASING] is also applicable.

14.1.  Key Loss and Version Downgrade

   ECH and Protected Initials both rely on shared cryptographic
   configuration state between client and server, delivered by an out-
   of-band method, usually DNS.

   In the event this synchronization fails in ECH, the client-facing
   server can complete the handshake, authenticate itself against the
   "public name" in the unprotected part of the Client Hello, and
   provide updated configuration state, allowing a resumed attempt after
   1 RTT.






Duke                     Expires 8 November 2021               [Page 11]


Internet-Draft              protected-initial                   May 2021


   With Protected Initials, when decryption fails there is not enough
   context to complete any sort of authentication to update the crypto
   context.  Instead, the server sends a Version Negotiation Packet that
   causes the client to fall back to a version of QUIC with unprotected
   Initials, in which it could connect to the public name and only then
   acquire the updated crypto context.  Note that this incurs an
   additional 1-RTT penalty over ECH, although loss of key
   synchronization is hopefully a rare occurrence.

   Furthermore, Version Negotiation Packets are not authenticated, which
   opens up the possibility of Version Downgrade attacks.

   The weak form of this attack simply observes the Client Initial and
   delivers a Version Negotiation Packet before the client responds.
   Clients SHOULD wait for an interval (roughly the QUIC Probe Timeout,
   see [I-D.ietf-quic-recovery]) before acting on a Version Negotiation
   Packet that indicates a lack of support for Protected Initials when a
   DNS record indicating such support exists, to allow a later valid
   server response to arrive.  If it does, the client MUST ignore the
   Version Negotiation packet.

   The strong form of this attack requires the attacker to drop either
   the Client Initial or the Server Initial.  In this case, the client
   has no recourse but to connect with an unprotected Initial.  As
   described above, the client can obtain an updated context from the
   public name and then assume subsequent Version Negotiation packets
   are invalid with high probability.  Regardless, an attacker with
   these capabilities can always block a secured handshake of any kind,
   and can force the client choose between an insecure handshake and not
   communicating at all.  However, QUIC is designed to fail the
   connection if an attacker forces a downgrade.

   Unfortunately, the existing detection mechanism in [QUIC-VN] is
   insufficient to detect these in the case of Protected Initials.

   Because some clients may have the correct configuration and others
   not, servers might send Version Negotiation to a subset of clients
   that attempt to use Protected Initials.  To validate if it would have
   accepted a "Previously Attempted Version," the server would have to
   track the clients to which it recently sent Version Negotiation
   packets.










Duke                     Expires 8 November 2021               [Page 12]


Internet-Draft              protected-initial                   May 2021


   However, even this is insufficient.  An attacker can simply drop a
   Protected Initial Packet, send Version Negotiation, and then send an
   improperly encrypted Initial Packet to the server using the client's
   IP to trigger a Version Negotiation.  As servers do not authenticate
   client Initials before sending Version Negotiation, the server has to
   actually understand the crypto context the client was attempting to
   use.  This is the reason for the public_key_failed transport
   parameter.

14.2.  Initial Packet Injection

   QUIC version 1 handshakes are vulnerable to DoS from observers for
   the short interval that endpoints keep Initial keys (usually ~1.5
   RTTS), since Initial Packets are not authenticated.  With version
   aliasing, attackers do not have the necessary keys to launch such an
   attack.

   QUIC version 1 can use a fixed symmetric cipher for its Initial
   Packets because the encryption is not providing true security.  As
   this design aspires to stonger guarantees, the Encryption Context
   field of the Initial header provides the codepoints to enable use of
   other symmetric ciphers should AES-128-GCM be compromised in the
   future.  This is to provide cryptographic agility in accordance with
   [RFC7696].

14.3.  Retry Injection

   This version of QUIC does not improve the security of Retry packets
   with respect to QUIC version 1.  The Retry Integrity Tag uses a well-
   known key and relies on data in the Initial that triggered the Retry.
   It therefore protects against transmission errors and injection of
   Retry packets by off-path attackers that cannot observe the Initial.
   To detect Retry packets injected by observers, it relies on the
   subsequent exchange of transport parameters.

   An attacker that consistently injects Retry packets in front of a
   server that also consistently sends Retry can result in a Denial of
   Service, as clients cannot accept two Retries in the same connection.

   An alternate design would use the shared secret derived from the
   Client Initial Packet to generate keys for the Retry Integrity Tag,
   which would allow the client to immediately discard Retries injected
   by other parties.  Unfortunately, this would require servers to
   perform an asymmetric crypto operation to send a Retry packet, when
   in a state where it is likely computationally limited.






Duke                     Expires 8 November 2021               [Page 13]


Internet-Draft              protected-initial                   May 2021


   It is possible to enhance the security of Retry by assuming this
   added computational cost.  Such a design could also eliminate the
   complexity associated with adding an arbitrary value to the Packet
   Length field.  The purpose of this addition is to avoid trial
   decryption to verify the configuration is correct, but this cost is
   negligible compared to extracting the shared secret.

14.4.  Less Trial Decryption

   Unlike ECH, Protected Initials can use the Packet Length Offset
   mechanism to detect key mismatches without trial decryption, saving
   resources in the case of genuine misconfiguration.  However, an
   attacker attempting to force trial decryption can easily force a
   decryption that will ultimately result in the packet being silently
   dropped.

15.  IANA Considerations

15.1.  QUIC Version Registry

   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.2.  QUIC Transport Parameter Registry

   This document request that IANA add the following two entries to the
   QUIC Transport Parameters registry:

               +=======+===================+===============+
               | Value |   Parameter Name  | Specification |
               +=======+===================+===============+
               |  TBD  | public_key_failed | This document |
               +-------+-------------------+---------------+
               |  TBD  |     ECHConfig     | This document |
               +-------+-------------------+---------------+

                                  Table 2




Duke                     Expires 8 November 2021               [Page 14]


Internet-Draft              protected-initial                   May 2021


16.  References

16.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-recovery]
              Iyengar, J. and I. Swett, "QUIC Loss Detection and
              Congestion Control", Work in Progress, Internet-Draft,
              draft-ietf-quic-recovery-34, 14 January 2021,
              <https://www.ietf.org/archive/id/draft-ietf-quic-recovery-
              34.txt>.

   [I-D.ietf-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>.

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

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

   [QUIC-VN]  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>.

16.2.  Informative References



Duke                     Expires 8 November 2021               [Page 15]


Internet-Draft              protected-initial                   May 2021


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

   [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
              Agility and Selecting Mandatory-to-Implement Algorithms",
              BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
              <https://www.rfc-editor.org/info/rfc7696>.

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

Appendix A.  Change Log

      *RFC Editor's Note:* Please remove this section prior to
      publication of a final version of this document.

A.1.  since draft-duke-quic-protected-initials-00

   *  Additional text comparing ECH, Version Aliasing

   *  Adapted to foreground the split-mode use case

   *  Clarified server initials are encrypted

   *  Retry keys are no longer generated from the shared secret

   *  Complete Rewrite of Fallback

   *  New transport parameters

   *  Added crypto agility

Author's Address




Duke                     Expires 8 November 2021               [Page 16]


Internet-Draft              protected-initial                   May 2021


   Martin Duke
   F5 Networks, Inc.

   Email: martin.h.duke@gmail.com















































Duke                     Expires 8 November 2021               [Page 17]