| < draft-duke-quic-version-aliasing-07.txt | draft-duke-quic-version-aliasing-08.txt > | |||
|---|---|---|---|---|
| QUIC M. Duke | QUIC M. Duke | |||
| Internet-Draft F5 Networks, Inc. | Internet-Draft Google | |||
| Intended status: Experimental 25 October 2021 | Intended status: Experimental 28 April 2022 | |||
| Expires: 28 April 2022 | Expires: 30 October 2022 | |||
| QUIC Version Aliasing | QUIC Version Aliasing | |||
| draft-duke-quic-version-aliasing-07 | draft-duke-quic-version-aliasing-08 | |||
| Abstract | Abstract | |||
| The QUIC transport protocol preserves its future extensibility partly | The QUIC transport protocol preserves its future extensibility partly | |||
| by specifying its version number. There will be a relatively small | by specifying its version number. There will be a relatively small | |||
| number of published version numbers for the foreseeable future. This | number of published version numbers for the foreseeable future. This | |||
| document provides a method for clients and servers to negotiate the | document provides a method for clients and servers to negotiate the | |||
| use of other version numbers in subsequent connections and encrypts | use of other version numbers in subsequent connections and encrypts | |||
| Initial Packets using secret keys instead of standard ones. If a | Initial Packets using secret keys instead of standard ones. If a | |||
| sizeable subset of QUIC connections use this mechanism, this should | sizeable subset of QUIC connections use this mechanism, this should | |||
| skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 28 April 2022. | This Internet-Draft will expire on 30 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1. Relationship to ECH and QUIC Protected Initials . . . . . 5 | 2.1. Relationship to ECH and QUIC Protected Initials . . . . . 6 | |||
| 3. The Version Alias Transport Parameter . . . . . . . . . . . . 6 | 3. The Version Alias Transport Parameter . . . . . . . . . . . . 7 | |||
| 3.1. Version Number Generation . . . . . . . . . . . . . . . . 7 | 3.1. Aliased Version Number Generation . . . . . . . . . . . . 7 | |||
| 3.2. Initial Token Extension (ITE) Generation . . . . . . . . 7 | 3.2. Initial Token Extension (ITE) Generation . . . . . . . . 7 | |||
| 3.3. Salt and Packet Length Offset Generation . . . . . . . . 8 | 3.3. Salt and Packet Length Offset Generation . . . . . . . . 8 | |||
| 3.4. Expiration Time . . . . . . . . . . . . . . . . . . . . . 8 | 3.4. Packet Type Generation . . . . . . . . . . . . . . . . . 8 | |||
| 3.5. Format . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.5. Standard Version Number . . . . . . . . . . . . . . . . . 9 | |||
| 3.6. Multiple Servers for One Domain . . . . . . . . . . . . . 10 | 3.6. Expiration Time . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.7. Multiple Entities With One Load Balancer . . . . . . . . 10 | 3.7. Format . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 | 3.8. Multiple Servers for One Domain . . . . . . . . . . . . . 11 | |||
| 4.1. The aliasing_parameters Transport Parameter . . . . . . . 12 | 3.9. Multiple Entities With One Load Balancer . . . . . . . . 11 | |||
| 5. Server Actions on Aliased Version Numbers . . . . . . . . . . 12 | 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 4.1. The aliasing_parameters Transport Parameter . . . . . . . 13 | |||
| 6.1. Bad Salt Packets . . . . . . . . . . . . . . . . . . . . 14 | 5. Server Actions on Aliased Version Numbers . . . . . . . . . . 14 | |||
| 6.2. Client Response to Bad Salt . . . . . . . . . . . . . . . 15 | 6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 6.3. Server Response to version_aliasing Transport | 6.1. Bad Salt Packets . . . . . . . . . . . . . . . . . . . . 15 | |||
| Parameter . . . . . . . . . . . . . . . . . . . . . . . . 16 | 6.2. Client Response to Bad Salt . . . . . . . . . . . . . . . 17 | |||
| 7. Considerations for Retry Packets . . . . . . . . . . . . . . 16 | 6.3. version_aliasing_fallback Transport Parameter . . . . . . 17 | |||
| 8. Security and Privacy Considerations . . . . . . . . . . . . . 17 | 6.4. Server Response to version_aliasing_fallback Transport | |||
| 8.1. Endpoint Impersonation . . . . . . . . . . . . . . . . . 17 | Parameter . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 8.2. First-Connection Privacy . . . . . . . . . . . . . . . . 17 | 7. Considerations for Retry Packets . . . . . . . . . . . . . . 19 | |||
| 8.3. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 18 | 8. Security and Privacy Considerations . . . . . . . . . . . . . 19 | |||
| 8.4. Initial Packet Injection . . . . . . . . . . . . . . . . 18 | 8.1. Endpoint Impersonation . . . . . . . . . . . . . . . . . 19 | |||
| 8.5. Retry Injection . . . . . . . . . . . . . . . . . . . . . 18 | 8.2. First-Connection Privacy . . . . . . . . . . . . . . . . 20 | |||
| 8.6. Increased Linkability . . . . . . . . . . . . . . . . . . 19 | 8.3. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 20 | |||
| 8.7. Salt Polling . . . . . . . . . . . . . . . . . . . . . . 19 | 8.4. Initial Packet Injection . . . . . . . . . . . . . . . . 21 | |||
| 8.8. Server Fingerprinting . . . . . . . . . . . . . . . . . . 20 | 8.5. Retry Injection . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 8.9. Increased Processing of Garbage UDP Packets . . . . . . . 20 | 8.6. Increased Linkability . . . . . . . . . . . . . . . . . . 22 | |||
| 8.10. Increased Retry Overhead . . . . . . . . . . . . . . . . 21 | 8.7. Salt Polling . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8.11. Request Forgery . . . . . . . . . . . . . . . . . . . . . 21 | 8.8. Server Fingerprinting . . . . . . . . . . . . . . . . . . 22 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 8.9. Increased Processing of Garbage UDP Packets . . . . . . . 23 | |||
| 9.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 21 | 8.10. Increased Retry Overhead . . . . . . . . . . . . . . . . 23 | |||
| 9.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 21 | 8.11. Request Forgery . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 9.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 22 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 9.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 23 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 9.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 24 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 22 | 9.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 24 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 | |||
| B.1. since draft-duke-quic-version-aliasing-05 . . . . . . . . 23 | 10.2. Informative References . . . . . . . . . . . . . . . . . 25 | |||
| B.2. since draft-duke-quic-version-aliasing-04 . . . . . . . . 23 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 | |||
| B.3. since draft-duke-quic-version-aliasing-03 . . . . . . . . 23 | Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 | |||
| B.4. since draft-duke-quic-version-aliasing-02 . . . . . . . . 23 | B.1. since draft-duke-quic-version-aliasing-07 . . . . . . . . 25 | |||
| B.5. since draft-duke-quic-version-aliasing-01 . . . . . . . . 23 | B.2. since draft-duke-quic-version-aliasing-05 . . . . . . . . 26 | |||
| B.6. since draft-duke-quic-version-aliasing-00 . . . . . . . . 23 | B.3. since draft-duke-quic-version-aliasing-04 . . . . . . . . 26 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 | B.4. since draft-duke-quic-version-aliasing-03 . . . . . . . . 26 | |||
| B.5. since draft-duke-quic-version-aliasing-02 . . . . . . . . 26 | ||||
| B.6. since draft-duke-quic-version-aliasing-01 . . . . . . . . 26 | ||||
| B.7. since draft-duke-quic-version-aliasing-00 . . . . . . . . 26 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 | ||||
| 1. Introduction | 1. Introduction | |||
| The QUIC version number is critical to future extensibility of the | The QUIC version number is critical to future extensibility of the | |||
| protocol ([RFC9000]). Past experience with other protocols, such as | protocol ([RFC9000]). Past experience with other protocols, such as | |||
| TLS1.3 [RFC8446], shows that middleboxes might attempt to enforce | TLS1.3 [RFC8446], shows that middleboxes might attempt to enforce | |||
| that QUIC packets use versions known at the time the middlebox was | that QUIC packets use versions known at the time the middlebox was | |||
| implemented. This deters deployment of experimental and standard | implemented. This deters deployment of experimental and standard | |||
| versions on the internet. | versions on the internet. | |||
| skipping to change at page 4, line 25 ¶ | skipping to change at page 4, line 25 ¶ | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| In this document, these words will appear with that interpretation | In this document, these words will appear with that interpretation | |||
| only when in ALL CAPS. Lower case uses of these words are not to be | only when in ALL CAPS. Lower case uses of these words are not to be | |||
| interpreted as carrying significance described in RFC 2119. | interpreted as carrying significance described in RFC 2119. | |||
| A "standard version" is a QUIC version that would be advertised in a | A "standard version" is a QUIC version that would be advertised in a | |||
| QUIC version negotiation and conforms to a specification. Any | QUIC version negotiation and conforms to a specification. Any | |||
| aliased version corresponds to a standard version in all its formats | aliased version corresponds to a standard version in all its formats | |||
| and behaviors, except for the version number field in long headers. | and behaviors, except for the version number field in long headers. | |||
| To be compatible with version aliasing, the first client packet in a | To be compatible with version aliasing, there MUST be no more than | |||
| standard version MUST encode the packet type and token as if it were | four long header packet types, and the first client packet in a | |||
| a QUIC version 1 initial packet. That is: | standard version MUST encode the token as if it were a QUIC version 1 | |||
| initial packet. That is: | ||||
| * The most significant bit MUST be 1. | * The most significant bit MUST be 1. | |||
| * The third and fourth most significant bits MUST be zero. | ||||
| * The first field after the Source Connection ID MUST be a variable- | * The first field after the Source Connection ID MUST be a variable- | |||
| length integer including the length of a token. | length integer including the length of a token. | |||
| * The second field after the Destination Connection ID MUST be a | * The second field after the Destination Connection ID MUST be a | |||
| field, with length indicated by the previous field, that contains | field, with length indicated by the previous field, that contains | |||
| opaque data generated by the server. | opaque data generated by the server. | |||
| * There must be a variable-length integer that encodes the packet | * There must be a variable-length integer that encodes the packet | |||
| length, unprotected in the header. | length, unprotected in the header. | |||
| An "aliased version" is a version with a number generated in | An "aliased version" is a version with a number generated in | |||
| accordance with this document. Except for the version field in long | accordance with this document. Except for the version field in long | |||
| headers, it conforms entirely to the specification of the standard | headers, it conforms entirely to the specification of the standard | |||
| version. | version. | |||
| 2. Protocol Overview | 2. Protocol Overview | |||
| When they instantiate a connection, servers select an alternate | When they instantiate a connection, servers select an alternate | |||
| 32-bit version number, and optionally an initial token extension, for | 32-bit version number, and optionally an initial token extension, for | |||
| the next connection at random and securely derive a salt and Packet | the next connection at random and securely derive a salt, packet | |||
| Length Offset from those values using a repeatable process. They | Length Offset, and long header packet type codepoints from those | |||
| communicate this using a transport parameter extension including the | values using a repeatable process. They communicate this using a | |||
| version, initial token extension, salt, Packet Length Offset, and an | transport parameter extension including the version, initial token | |||
| expiration time for that value. | extension, Initial salt, Packet Length Offset, packet type | |||
| codepoints, and an expiration time for that value. | ||||
| If a client next connects to that server within the indicated | If a client next connects to that server within the indicated | |||
| expiration time, it MAY use the provided version number and encrypt | expiration time, it MAY use the provided version number and encrypt | |||
| its Initial Packets using a key derived from the provided salt. It | its Initial Packets using a key derived from the provided salt. It | |||
| adds the Packet Length Offset to the true packet length when encoding | uses the provided Initial packet codepoint. It adds the Packet | |||
| it in the long header. If the server provided an Initial Token | Length Offset to the true packet length when encoding it in the long | |||
| Extension, the client puts it in the Initial Packet token field. If | header. If the server provided an Initial Token Extension, the | |||
| there is another token the client wishes to include, it appends the | client puts it in the Initial Packet token field. If there is | |||
| Initial Token Extension to that token. The server can reconstruct | another token the client wishes to include, it appends the Initial | |||
| the salt and Packet Length Offset from the requested version and | Token Extension to that token. The server can reconstruct the salt | |||
| token, and proceed with the connection normally. | and Packet Length Offset from the requested version and token, and | |||
| proceed with the connection normally. | ||||
| The Packet Length Offset provides a low-cost way for the server to | The Packet Length Offset provides a low-cost way for the server to | |||
| verify it can derive a valid salt from the inputs without trial | verify it can derive a valid salt from the inputs without trial | |||
| decryption. This has important security implications, as described | decryption. This has important security implications, as described | |||
| in Section 8.5. | in Section 8.5. | |||
| When generating a salt and Packet Length Offset, servers can choose | When generating a salt and Packet Length Offset, servers can choose | |||
| between doing so randomly and storing the mapping, or using a | between doing so randomly and storing the mapping, or using a | |||
| cryptographic process to transform the aliased version number and | cryptographic process to transform the aliased version number and | |||
| token extension into the salt. The two options provide a simple | token extension into the salt. The two options provide a simple | |||
| tradeoff between computational complexity and storage requirements. | tradeoff between computational complexity and storage requirements. | |||
| Long header packets are composed identically to their standard | ||||
| version, except that they use the provided packet type codepoint, | ||||
| version number, and packet length offset. Initial packets | ||||
| additionally use any provided token extension and are encrypted as | ||||
| described below. | ||||
| Short header packets are unchanged when using this extension. | ||||
| 2.1. Relationship to ECH and QUIC Protected Initials | 2.1. Relationship to ECH and QUIC Protected Initials | |||
| The TLS Encrypted Client Hello [ECHO] shares some goals with this | The TLS Encrypted Client Hello [ECHO] shares some goals with this | |||
| document. It encodes an "inner" encrypted Client Hello in a TLS | document. It encodes an "inner" encrypted Client Hello in a TLS | |||
| extension in an "outer" Client Hello. The encryption uses asymmetric | extension in an "outer" Client Hello. The encryption uses asymmetric | |||
| keys with the server's public key distributed via an out-of-band | keys with the server's public key distributed via an out-of-band | |||
| mechanism like DNS. The inner Client Hello contains any privacy- | mechanism like DNS. The inner Client Hello contains any privacy- | |||
| sensitive information and is only readable with the server's private | sensitive information and is only readable with the server's private | |||
| key. | key. | |||
| skipping to change at page 7, line 4 ¶ | skipping to change at page 7, line 20 ¶ | |||
| not greasing the version field. | not greasing the version field. | |||
| A maximally privacy-protecting client might use Protected Initials | A maximally privacy-protecting client might use Protected Initials | |||
| for any connection attempts for which it does not have an unexpired | for any connection attempts for which it does not have an unexpired | |||
| aliased version, and QUIC version aliasing otherwise. | aliased version, and QUIC version aliasing otherwise. | |||
| See also section 1.1 of [QUIC-PI] for further discussion of | See also section 1.1 of [QUIC-PI] for further discussion of | |||
| tradeoffs. | tradeoffs. | |||
| 3. The Version Alias Transport Parameter | 3. The Version Alias Transport Parameter | |||
| 3.1. Version Number Generation | ||||
| 3.1. Aliased Version Number Generation | ||||
| Servers MUST use a random process to generate version numbers. This | Servers MUST use a random process to generate version numbers. This | |||
| version number MUST NOT correspond to a QUIC version the server | version number MUST NOT correspond to a QUIC version the server | |||
| advertises in QUIC Version Negotiation packets or transport | advertises in QUIC Version Negotiation packets or transport | |||
| parameters. Servers SHOULD also exclude version numbers used in | parameters. Servers SHOULD also exclude version numbers used in | |||
| known specifications or experiments to avoid confusion at clients, | known specifications or experiments to avoid confusion at clients, | |||
| whether or not they have plans to support those specifications. | whether or not they have plans to support those specifications. | |||
| Servers MAY use version numbers reserved for grease in Section 15.1 | Servers MAY use version numbers reserved for grease in Section 15.1 | |||
| of [RFC9000], even though they might be advertised in Version | of [RFC9000], even though they might be advertised in Version | |||
| skipping to change at page 7, line 35 ¶ | skipping to change at page 8, line 5 ¶ | |||
| Servers SHOULD generate an Initial Token Extension (ITE) to provide | Servers SHOULD generate an Initial Token Extension (ITE) to provide | |||
| additional entropy in salt generation. Two clients that receive the | additional entropy in salt generation. Two clients that receive the | |||
| same version number but different extensions will not be able to | same version number but different extensions will not be able to | |||
| decode each other's Initial Packets. | decode each other's Initial Packets. | |||
| Servers MAY choose any length that will allow client Initial Packets | Servers MAY choose any length that will allow client Initial Packets | |||
| to fit within the minimum QUIC packet size of 1200 octets. A four- | to fit within the minimum QUIC packet size of 1200 octets. A four- | |||
| octet extension is RECOMMENDED. The ITE MUST appear to be random to | octet extension is RECOMMENDED. The ITE MUST appear to be random to | |||
| observers. | observers. | |||
| If a server supports multiple standard versions, it MUST either | ||||
| encode the standard version of the current connection in the ITE or | ||||
| store it in a lookup table. | ||||
| If the server chooses to encode the standard version, it MUST be | ||||
| cryptographically protected. | ||||
| Encoded standard versions MUST be robust to false positives. That | ||||
| is, if decoded with a new key, the version encoding must return as | ||||
| invalid, rather than an incorrect value. | ||||
| Alternatively, servers MAY store a mapping of unexpired aliased | ||||
| versions and ITEs to standard versions. This mapping SHOULD NOT | ||||
| create observable patterns, e.g. one plaintext bit indicates if the | ||||
| standard version is 1 or 2. | ||||
| The server MUST be able to distinguish ITEs from Resumption and Retry | The server MUST be able to distinguish ITEs from Resumption and Retry | |||
| tokens in incoming Initial Packets that contain an aliased version | tokens in incoming Initial Packets that contain an aliased version | |||
| number. As the server controls the lengths and encoding of each, | number. As the server controls the lengths and encoding of each, | |||
| there are many ways to guarantee this. | there are many ways to guarantee this. | |||
| 3.3. Salt and Packet Length Offset Generation | 3.3. Salt and Packet Length Offset Generation | |||
| The salt is an opaque 20-octet field. It is used to generate Initial | The salt is an opaque 20-octet field. It is used to generate Initial | |||
| connection keys using the process described in [RFC9001]. | connection keys using the process described in [RFC9001]. | |||
| The Packet Length Offset is a 64-bit unsigned integer with a maximum | The Packet Length Offset is a 64-bit unsigned integer with a maximum | |||
| value of 2^62 - 1. Clients MUST ignore a transport parameter with a | value of 2^62 - 1. | |||
| value that exceeds this limit. | ||||
| To reduce header overhead, servers MAY consistently use a Packet | To reduce header overhead, servers MAY consistently use a Packet | |||
| Length Offset of zero if and only if it either (1) never sends Retry | Length Offset of zero if and only if it either (1) never sends Retry | |||
| packets, or (2) can guarantee, through the use of persistent storage | packets, or (2) can guarantee, through the use of persistent storage | |||
| or other means, that it will never lose the cryptographic state | or other means, that it will never lose the cryptographic state | |||
| required to generate the salt before the promised expiration time. | required to generate the salt before the promised expiration time. | |||
| Section 8.5 describes the implications if it uses zero without | Section 8.5 describes the implications if it uses zero without | |||
| meeting these conditions. | meeting these conditions. | |||
| Servers MUST either generate a random salt and Packet Length Offset | Servers MUST either generate a random salt and Packet Length Offset | |||
| skipping to change at page 8, line 39 ¶ | skipping to change at page 8, line 38 ¶ | |||
| generate the salt and offset using a cryptographic method that uses | generate the salt and offset using a cryptographic method that uses | |||
| the version number, ITE, and only server state that is persistent | the version number, ITE, and only server state that is persistent | |||
| across connections. | across connections. | |||
| If the latter, servers MUST implement a method that it can repeat | If the latter, servers MUST implement a method that it can repeat | |||
| deterministically at a later time to derive the salt and offset from | deterministically at a later time to derive the salt and offset from | |||
| the incoming version number and ITE. It MUST NOT use client | the incoming version number and ITE. It MUST NOT use client | |||
| controlled information other than the version number and ITE; for | controlled information other than the version number and ITE; for | |||
| example, the client's IP address and port. | example, the client's IP address and port. | |||
| 3.4. Expiration Time | 3.4. Packet Type Generation | |||
| The server generates the packet type codepoint for each of the four | ||||
| long header packet types (Initial, 0RTT, Handshake, and Retry). Each | ||||
| of these codepoints is two bits. | ||||
| Future versions of QUIC with 4 or fewer long header packet types can | ||||
| specify a mapping of these fields to their types. | ||||
| Note that the server needs to derive the type codepoints solely from | ||||
| the version number. It cannot extract the token, and the token | ||||
| extension, until the packet is identified as an Initial packet. | ||||
| A straightforward implementation might take arbitrary bits from a | ||||
| hash of the version number. The first two bits it reads are the | ||||
| codepoint for Initial packets. The next pair of bits that is not a | ||||
| duplicate of the first is the codepoint for 0RTT packets. The next | ||||
| pair that does not duplicate the first two is the codepoint for | ||||
| Handshake packets, and the remaining codepoint is the Retry packet. | ||||
| 3.5. Standard Version Number | ||||
| Servers also specify the Standard version that the client should use | ||||
| to guide the wire formats and behaviors of the aliased version. This | ||||
| version MUST meet the criteria to support version aliasing, and MUST | ||||
| either be included as a supported version in the client's | ||||
| version_information transport parameter (see | ||||
| [I-D.ietf-quic-version-negotiation]) or be the standard version of | ||||
| the current connection. | ||||
| Note that servers MUST NOT accept resumption tickets or NEW_TOKEN | ||||
| tokens from different standard versions. Therefore, the choice of | ||||
| standard version might impact the performance of the connection that | ||||
| uses an aliased version. The standard version that generated tickets | ||||
| and/or tokens is typically encoded in those tickets or tokens. | ||||
| There are several possible techniques for the server securely | ||||
| recovering the standard version in use for an aliased connection: | ||||
| * the server could store a mapping of aliased versions to standard | ||||
| version; | ||||
| * the server could encrypt the standard version in use in the | ||||
| aliased version number (note that the ITE cannot be extracted | ||||
| until the standard version in use is known); | ||||
| * the server only accepts one standard version for aliased versions; | ||||
| or | ||||
| * the standard version is included as an input to the parameter | ||||
| generation algorithm, and the server tries all supported standard | ||||
| versions and tests each resulting Packet Length Offset for | ||||
| validity. | ||||
| 3.6. Expiration Time | ||||
| Servers should select an expiration time in seconds, measured from | Servers should select an expiration time in seconds, measured from | |||
| the instant the transport parameter is first sent. This time SHOULD | the instant the transport parameter is first sent. This time SHOULD | |||
| be less than the time until the server expects to support new QUIC | be less than the time until the server expects to support new QUIC | |||
| versions, rotate the keys used to encode information in the version | versions, rotate the keys used to encode information in the version | |||
| number, or rotate the keys used in salt generation. | number, or rotate the keys used in salt generation. | |||
| Furthermore, the expiration time SHOULD be short enough to frustrate | Furthermore, the expiration time SHOULD be short enough to frustrate | |||
| a salt polling attack (Section 8.7) | a salt polling attack (Section 8.7) | |||
| Conversely, an extremely short expiration time will often force the | Conversely, an extremely short expiration time will often force the | |||
| client to use standard QUIC version numbers and salts. | client to use standard QUIC version numbers and salts. | |||
| 3.5. Format | 3.7. Format | |||
| This document defines a new transport parameter extension for QUIC | This document defines a new transport parameter extension for QUIC | |||
| with provisional identifier 0x5641. The contents of the value field | with provisional identifier 0x5641. The contents of the value field | |||
| are indicated below. | are indicated below. | |||
| 0 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Version (32) | | | Aliased Version (32) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Standard Version (32) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| + + | + + | |||
| | | | | | | |||
| + + | + + | |||
| | Salt (160) | | | Salt (160) | | |||
| + + | + + | |||
| | | | | | | |||
| + + | + + | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Packet Length Offset (i) | | | Packet Length Offset (i) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Expiration (i) | | | Expiration (i) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Initial Token Extension (variable) | | |INI|0RT|HAN|RET| Initial Token Extension (variable) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: Version Alias Transport Parameter value | Figure 1: Version Alias Transport Parameter value | |||
| The definition of the fields is described above. Note that the | The definition of the fields is described above. Note that the | |||
| "Expiration" field is in seconds, and its length is encoded using the | "Expiration" field is in seconds, and its length is encoded using the | |||
| Variable Length Integer encoding from Section 16 of [RFC9000]. | Variable Length Integer encoding from Section 16 of [RFC9000]. | |||
| The Packet Length Offset is also encoded as a Variable Length | The Packet Length Offset is also encoded as a Variable Length | |||
| Integer. | Integer. | |||
| INI, 0RT, HAN, and RET are the codepoints for each long header packet | ||||
| type. If any two packet types have the same codepoint, the transport | ||||
| parameter is invalid. | ||||
| Clients can compute the length of the Initial Token Extension by | Clients can compute the length of the Initial Token Extension by | |||
| subtracting known and encoded field lengths from the overall | subtracting known and encoded field lengths from the overall | |||
| transport parameter length. | transport parameter length. | |||
| Note that servers that support version aliasing need not send the | Note that servers that support version aliasing need not send the | |||
| transport parameter on every connection. Therefore, a client MAY | transport parameter on every connection. Therefore, a client MAY | |||
| attempt to connect with an unexpired aliased version, even if in its | attempt to connect with an unexpired aliased version, even if in its | |||
| most recent connection it did not receive the transport parameter. | most recent connection it did not receive the transport parameter. | |||
| Clients MAY remember the value in this transport parameter for future | Clients MAY remember the values in this transport parameter for | |||
| connections. Servers MUST either store the contents of the transport | future connections. Servers MUST either store the contents of the | |||
| parameter, or preserve the state to compute the full contents based | transport parameter, or preserve the state to compute the full | |||
| on what the client provides. | contents based on what the client provides. | |||
| 3.6. Multiple Servers for One Domain | A server that receives this transport parameter MUST close the | |||
| connection with a TRANSPORT_PARAMETER_ERROR. | ||||
| 3.8. Multiple Servers for One Domain | ||||
| If multiple servers serve the same entity behind a load balancer, all | If multiple servers serve the same entity behind a load balancer, all | |||
| such servers SHOULD either have a common configuration for encoding | such servers SHOULD either have a common configuration for encoding | |||
| standard versions and computing salts, or share a common database of | standard versions and computing salts, or share a common database of | |||
| mappings. They MUST NOT generate version numbers that any of them | mappings. They MUST NOT generate version numbers that any of them | |||
| would advertise in a Version Negotiation Packet or Transport | would advertise in a Version Negotiation Packet or Transport | |||
| Parameter. | Parameter. | |||
| 3.7. Multiple Entities With One Load Balancer | 3.9. Multiple Entities With One Load Balancer | |||
| If mutually mistrustful entities share the same IP address and port, | If mutually mistrustful entities share the same IP address and port, | |||
| incoming packets are usually routed by examining the SNI at a load | incoming packets are usually routed by examining the SNI at a load | |||
| balancer server that routes the traffic. This use case makes | balancer server that routes the traffic. This use case makes | |||
| concealing the contents of the Client Initial especially attractive, | concealing the contents of the Client Initial especially attractive, | |||
| as the IP address reveals less information. There are several | as the IP address reveals less information. There are several | |||
| solutions to solve this problem. | solutions to solve this problem. | |||
| * All entities have a common crytographic context for deriving salts | * All entities have a common crytographic context for deriving salts | |||
| and Packet Length Offsets from the version number and ITE. This | and Packet Length Offsets from the version number and ITE. This | |||
| skipping to change at page 11, line 12 ¶ | skipping to change at page 12, line 22 ¶ | |||
| all available version numbers to maximize the entropy of the | all available version numbers to maximize the entropy of the | |||
| encoding. | encoding. | |||
| Note that [ECHO] and [QUIC-PI] solve this problem elegantly by only | Note that [ECHO] and [QUIC-PI] solve this problem elegantly by only | |||
| holding the private key at the load balancer, which decodes the | holding the private key at the load balancer, which decodes the | |||
| sensitive information on behalf of the back-end server. | sensitive information on behalf of the back-end server. | |||
| 4. Client Behavior | 4. Client Behavior | |||
| When a client receives the Version Alias Transport Parameter, it MAY | When a client receives the Version Alias Transport Parameter, it MAY | |||
| cache the version number, ITE, salt, Packet Length Offset, and the | cache the version number, ITE, salt, Packet Length Offset, packet | |||
| expiration of these values. It MAY use the version number and ITE in | type codepoints, and the expiration of these values. It MAY use the | |||
| a subsequent connection and compute the initial keys using the | version number and ITE in a subsequent connection and compute the | |||
| provided salt. | initial keys using the provided salt. | |||
| The Client MUST NOT use the contents of a Version Alias transport | The Client MUST NOT use the contents of a Version Alias transport | |||
| parameter if the handshake does not (1) later authenticate the server | parameter if the handshake does not (1) later authenticate the server | |||
| name or (2) result in both endpoints computing the same 1-RTT keys. | name or (2) result in both endpoints computing the same 1-RTT keys. | |||
| See Section 8.1. The authenticated server name MAY be a "public | See Section 8.1. The authenticated server name MAY be a "public | |||
| name" distributed as described in [ECHO] rather than the true target | name" distributed as described in [ECHO] rather than the true target | |||
| domain. | domain. | |||
| Clients MUST NOT advertise aliased versions in the Version | Clients MUST NOT advertise aliased versions in the Version | |||
| Negotiation Transport Parameter unless they support a standard | Negotiation Transport Parameter unless they support a standard | |||
| skipping to change at page 11, line 41 ¶ | skipping to change at page 12, line 51 ¶ | |||
| Clients MAY decline to use the provided version number or salt in | Clients MAY decline to use the provided version number or salt in | |||
| more than one connection. It SHOULD do so if its IP address has | more than one connection. It SHOULD do so if its IP address has | |||
| changed between two connection attempts. Using a consistent version | changed between two connection attempts. Using a consistent version | |||
| number can link the client across connection attempts. | number can link the client across connection attempts. | |||
| Clients MUST use the same standard version to format the Initial | Clients MUST use the same standard version to format the Initial | |||
| Packet as the standard version used in the connection that provided | Packet as the standard version used in the connection that provided | |||
| the aliased version. | the aliased version. | |||
| Clients MUST use the provided codepoints to encode the packet type. | ||||
| If the server provided an ITE, the client MUST append it to any | If the server provided an ITE, the client MUST append it to any | |||
| Initial Packet token it is including from a Retry packet or NEW_TOKEN | Initial Packet token it is including from a Retry packet or NEW_TOKEN | |||
| frame, if it is using the associated aliased version. If there is no | frame, if it is using the associated aliased version. If there is no | |||
| such token, it simply includes the ITE as the entire token. | such token, it simply includes the ITE as the entire token. | |||
| When using an aliased version, the client MUST include a | When using an aliased version, the client MUST include a | |||
| aliasing_parameters transport parameter in its Client Hello. | aliasing_parameters transport parameter in its Client Hello. | |||
| The QUIC Token Length field MUST include the length of both any Retry | The QUIC Token Length field MUST include the length of both any Retry | |||
| or NEW_TOKEN token and the ITE. | or NEW_TOKEN token and the ITE. | |||
| skipping to change at page 12, line 47 ¶ | skipping to change at page 14, line 13 ¶ | |||
| The Version field matches the one in the packet header. | The Version field matches the one in the packet header. | |||
| The Initial Token field matches the Initial Token in the packet | The Initial Token field matches the Initial Token in the packet | |||
| header, including any Retry token, NEW_TOKEN token, and Initial Token | header, including any Retry token, NEW_TOKEN token, and Initial Token | |||
| Extension. Its length is inferred from the specified length of the | Extension. Its length is inferred from the specified length of the | |||
| parameter. | parameter. | |||
| The purpose of this parameter is to validate the contents of these | The purpose of this parameter is to validate the contents of these | |||
| header fields by including it in the TLS handshake transcript. | header fields by including it in the TLS handshake transcript. | |||
| A client that receives this transport parameter MUST close the | ||||
| connection with a TRANSPORT_PARAMETER_ERROR. | ||||
| 5. Server Actions on Aliased Version Numbers | 5. Server Actions on Aliased Version Numbers | |||
| When a server receives an Initial packet with an unsupported version | When a server receives a packet with an unsupported version number, | |||
| number, it SHOULD send a Version Negotiation Packet if it is | it SHOULD send a Version Negotiation Packet if it is configured not | |||
| configured not to generate that version number at random. | to generate that version number at random. | |||
| Otherwise, it extracts the ITE, if any, and either looks up the | Otherwise, when a server receives the first long header packet with | |||
| corresponding salt in its database or computes it using the technique | an unsupported version number, it hashes that version number to | |||
| originally used to derive the salt from the version number and ITE. | obtain the packet type mapping. If the packet is Handshake or Retry, | |||
| there may have been a loss of relevant server state; the server | ||||
| discards the packet and SHOULD follow the procedure in Section 6. If | ||||
| 0RTT, the server MAY either buffer it in anticipation of a later | ||||
| Initial, or immediately follow the procedure in Section 6. If | ||||
| buffering, and an Initial packet never arrives, the server SHOULD | ||||
| follow the procedure in Section 6 when discarding any 0RTT packets. | ||||
| For an Initial packet, it extracts the ITE, if any, and either looks | ||||
| up the corresponding salt in its database or computes it using the | ||||
| technique originally used to derive the salt from the version number | ||||
| and ITE. | ||||
| The server similarly obtains the Packet Length Offset and subtracts | The server similarly obtains the Packet Length Offset and subtracts | |||
| it from the provided Length field, modulo 2^62. If the resulting | it from the provided Length field, modulo 2^62. If the resulting | |||
| value is larger than the entire UDP datagram, the server discards the | value is larger than the entire UDP datagram, the server discards the | |||
| packet and SHOULD follow the procedure in Section 6. The server MAY | packet and SHOULD follow the procedure in Section 6. The server MAY | |||
| apply further checks (e.g. against the minimum QUIC packet length) to | apply further checks (e.g. against the minimum QUIC packet length) to | |||
| further reduce the very small probability of a false positive. | further reduce the very small probability of a false positive. | |||
| If the server supports multiple standard versions, it uses the | If the server supports multiple standard versions, it uses the | |||
| standard version extracted by the ITE or stored in the mapping to | standard version extracted by the ITE or stored in the mapping to | |||
| skipping to change at page 15, line 49 ¶ | skipping to change at page 17, line 21 ¶ | |||
| Timeout (PTO) to check if the Bad Salt packet was injected by an | Timeout (PTO) to check if the Bad Salt packet was injected by an | |||
| attacker, and a valid response arrives from the actual server. | attacker, and a valid response arrives from the actual server. | |||
| After waiting, the client checks the Integrity Tag using its record | After waiting, the client checks the Integrity Tag using its record | |||
| of the Initial it sent. If this fails, the client SHOULD assume | of the Initial it sent. If this fails, the client SHOULD assume | |||
| packet corruption and resend the Initial packet. | packet corruption and resend the Initial packet. | |||
| If the verification succeeds, the client SHOULD attempt to connect | If the verification succeeds, the client SHOULD attempt to connect | |||
| with one of the listed standard versions. It SHOULD observe the | with one of the listed standard versions. It SHOULD observe the | |||
| privacy considerations in Section 8.2. It MUST include a | privacy considerations in Section 8.2. It MUST include a | |||
| version_aliaising Transport Parameter in the Client Hello, that | version_aliasing_fallback Transport Parameter in the Client Hello. | |||
| enumerates the aliased version and parameters it just tried to | ||||
| connect with. | ||||
| Once it sends this transport parameter, the client MUST NOT attempt | Once it sends this transport parameter, the client MUST NOT attempt | |||
| to connect with that aliased version again. | to connect with that aliased version again. | |||
| The original Client Initial is not part of the new connection. | The original Client Initial is not part of the new connection. | |||
| Therefore, the Connection IDs can change, and the original client | Therefore, the Connection IDs can change, and the original client | |||
| hello is not part of the transcript for TLS key derivation. | hello is not part of the transcript for TLS key derivation. | |||
| Note that the client never sends this transport parameter with an | 6.3. version_aliasing_fallback Transport Parameter | |||
| aliased version. A server that receives such a packet MUST terminate | ||||
| the connection with a TRANSPORT_PARAMETER_ERROR. | ||||
| 6.3. Server Response to version_aliasing Transport Parameter | The client sends this transport parameter in a TLS Client Hello | |||
| generated in response to a Bad Salt packet: | ||||
| A client version_aliasing transport parameter tells the server that | 0 1 2 3 | |||
| the client received a Bad Salt packet. The server checks if could | 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 | |||
| have generated that version aliasing transport parameter given its | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| current configuration; i.e. if using the version and ITE as inputs | | Aliased Version (32) | | |||
| results in the same salt and Packet Length Offset. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | ||||
| + + | ||||
| | | | ||||
| + + | ||||
| | Salt (160) | | ||||
| + + | ||||
| | | | ||||
| + + | ||||
| | | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | | ||||
| + + | ||||
| | | | ||||
| + Bad Salt Integrity Tag (128) + | ||||
| | | | ||||
| + + | ||||
| | | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Initial Token (variable) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| If the salt or Packet Length Offset are invalid, the server SHOULD | The Aliased Version, Salt, and Initial Token fields are taken from | |||
| continue with the connection and SHOULD issue a new version_aliasing | the connection attempt that triggered this fallback. The length of | |||
| transport parameter. | the Initial Token is inferred from the Transport Parameter's overall | |||
| length. | ||||
| The Bad Salt Integrity Tag comes from is taken from the Bad Salt | ||||
| packet that triggered this fallback. Its purpose is to include the | ||||
| Bad Salt packet contents in the TLS handshake hash. | ||||
| 6.4. Server Response to version_aliasing_fallback Transport Parameter | ||||
| A client version_aliasing_fallback transport parameter tells the | ||||
| server that the client received a Bad Salt packet. The server checks | ||||
| if using the version and ITE as inputs results in the same salt. | ||||
| If the salt does not match, the server SHOULD continue with the | ||||
| connection and SHOULD issue a new version_aliasing transport | ||||
| parameter. | ||||
| If the salt and Packet Length Offset are valid, the server MUST | If the salt and Packet Length Offset are valid, the server MUST | |||
| terminate the connection with the error code INVALID_BAD_SALT. | terminate the connection with the error code INVALID_BAD_SALT. | |||
| Note that the client never sends this transport parameter with an | ||||
| aliased version. A server that receives such a packet MUST terminate | ||||
| the connection with a TRANSPORT_PARAMETER_ERROR. | ||||
| 7. Considerations for Retry Packets | 7. Considerations for Retry Packets | |||
| QUIC Retry packets reduce the load on servers during periods of | QUIC Retry packets reduce the load on servers during periods of | |||
| stress by forcing the client to prove it possesses the IP address | stress by forcing the client to prove it possesses the IP address | |||
| before the server decrypts any Initial Packets or establishes any | before the server decrypts any Initial Packets or establishes any | |||
| connection state. Version aliasing substantially complicates the | connection state. Version aliasing substantially complicates the | |||
| process. | process. | |||
| If a server has to send a Retry packet, the required format is | If a server has to send a Retry packet, the required format is | |||
| ambiguous without understanding which standard version to use. If | ambiguous without understanding which standard version to use. If | |||
| skipping to change at page 21, line 29 ¶ | skipping to change at page 24, line 4 ¶ | |||
| the client, potentially increasing the potency of this attack. | the client, potentially increasing the potency of this attack. | |||
| 9. IANA Considerations | 9. IANA Considerations | |||
| 9.1. QUIC Version Registry | 9.1. QUIC Version Registry | |||
| This document request that IANA add the following entry to the QUIC | This document request that IANA add the following entry to the QUIC | |||
| version registry: | version registry: | |||
| Value: TBD | Value: TBD | |||
| Status: permanent | Status: permanent | |||
| Specification: This document | Specification: This document | |||
| Change Controller: IETF | Change Controller: IETF | |||
| Contact: QUIC WG | Contact: QUIC WG | |||
| 9.2. QUIC Transport Parameter Registry | 9.2. QUIC Transport Parameter Registry | |||
| This document requests that IANA add the following entries to the | This document requests that IANA add the following entries to the | |||
| QUIC Transport Parameters Registry: | QUIC Transport Parameters Registry: | |||
| +=======+=====================+===============+ | +=======+===========================+===============+ | |||
| | Value | Parameter Name | Specification | | | Value | Parameter Name | Specification | | |||
| +=======+=====================+===============+ | +=======+===========================+===============+ | |||
| | TBD | Version Aliasing | This Document | | | TBD | version_aliasing | This Document | | |||
| +-------+---------------------+---------------+ | +-------+---------------------------+---------------+ | |||
| | TBD | aliasing_parameters | This Document | | | TBD | aliasing_parameters | This Document | | |||
| +-------+---------------------+---------------+ | +-------+---------------------------+---------------+ | |||
| | TBD | version_aliasing_fallback | This Document | | ||||
| +-------+---------------------------+---------------+ | ||||
| Table 1 | Table 1 | |||
| 9.3. QUIC Transport Error Codes Registry | 9.3. QUIC Transport Error Codes Registry | |||
| This document requests that IANA add the following entry to the QUIC | This document requests that IANA add the following entry to the QUIC | |||
| Transport Error Codes registry: | Transport Error Codes registry: | |||
| Value: TBD (provisional: 0x4942) | Value: TBD (provisional: 0x4942) | |||
| Code: INVALID_BAD_SALT | Code: INVALID_BAD_SALT | |||
| 10. References | 10. References | |||
| 10.1. Normative References | 10.1. Normative References | |||
| [I-D.ietf-quic-version-negotiation] | [I-D.ietf-quic-version-negotiation] | |||
| Schinazi, D. and E. Rescorla, "Compatible Version | Schinazi, D. and E. Rescorla, "Compatible Version | |||
| Negotiation for QUIC", Work in Progress, Internet-Draft, | Negotiation for QUIC", Work in Progress, Internet-Draft, | |||
| draft-ietf-quic-version-negotiation-04, 26 May 2021, | draft-ietf-quic-version-negotiation-07, 5 April 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| version-negotiation-04>. | version-negotiation-07>. | |||
| [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| Multiplexed and Secure Transport", RFC 9000, | Multiplexed and Secure Transport", RFC 9000, | |||
| DOI 10.17487/RFC9000, May 2021, | DOI 10.17487/RFC9000, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc9000>. | <https://www.rfc-editor.org/rfc/rfc9000>. | |||
| [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | |||
| QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, | QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc9001>. | <https://www.rfc-editor.org/rfc/rfc9001>. | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | |||
| Encrypted Client Hello", Work in Progress, Internet-Draft, | Encrypted Client Hello", Work in Progress, Internet-Draft, | |||
| draft-ietf-tls-esni-13, 12 August 2021, | draft-ietf-tls-esni-14, 13 February 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | |||
| esni-13>. | esni-14>. | |||
| [QUIC-PI] Duke, M. and D. Schinazi, "Protected QUIC Initial | [QUIC-PI] Duke, M. and D. Schinazi, "Protected QUIC Initial | |||
| Packets", Work in Progress, Internet-Draft, draft-duke- | Packets", Work in Progress, Internet-Draft, draft-duke- | |||
| quic-protected-initial-02, 13 May 2021, | quic-protected-initial-04, 27 April 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-duke-quic- | <https://datatracker.ietf.org/doc/html/draft-duke-quic- | |||
| protected-initial-02>. | protected-initial-04>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/rfc/rfc2119>. | |||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
| <https://www.rfc-editor.org/rfc/rfc8446>. | <https://www.rfc-editor.org/rfc/rfc8446>. | |||
| Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
| Marten Seemann was the original creator of the version aliasing | Marten Seemann was the original creator of the version aliasing | |||
| approach. | approach. | |||
| Appendix B. Change Log | Appendix B. Change Log | |||
| *RFC Editor's Note:* Please remove this section prior to | *RFC Editor's Note:* Please remove this section prior to | |||
| publication of a final version of this document. | publication of a final version of this document. | |||
| B.1. since draft-duke-quic-version-aliasing-05 | B.1. since draft-duke-quic-version-aliasing-07 | |||
| * Added the Bad Salt Integrity Tag to the transport parameter | ||||
| * Greased packet types | ||||
| * Allowed the server to specify the standard version to connect with | ||||
| B.2. since draft-duke-quic-version-aliasing-05 | ||||
| * Revised security considerations | * Revised security considerations | |||
| * Discussed multiple SNIs behind one load balancer | * Discussed multiple SNIs behind one load balancer | |||
| * Removed VN from the fallback mechanism | * Removed VN from the fallback mechanism | |||
| B.2. since draft-duke-quic-version-aliasing-04 | B.3. since draft-duke-quic-version-aliasing-04 | |||
| * Relationship with Encrypted Client Hello (ECH) and QUIC Protected | * Relationship with Encrypted Client Hello (ECH) and QUIC Protected | |||
| Initials | Initials | |||
| * Corrected statement about version negotiation | * Corrected statement about version negotiation | |||
| B.3. since draft-duke-quic-version-aliasing-03 | B.4. since draft-duke-quic-version-aliasing-03 | |||
| * Discussed request forgery attacks | * Discussed request forgery attacks | |||
| B.4. since draft-duke-quic-version-aliasing-02 | B.5. since draft-duke-quic-version-aliasing-02 | |||
| * Specified 0RTT status of the transport parameter | * Specified 0RTT status of the transport parameter | |||
| B.5. since draft-duke-quic-version-aliasing-01 | B.6. since draft-duke-quic-version-aliasing-01 | |||
| * Fixed all references to "seed" where I meant "salt." | * Fixed all references to "seed" where I meant "salt." | |||
| * Added the Packet Length Offset, which eliminates Retry Injection | * Added the Packet Length Offset, which eliminates Retry Injection | |||
| Attacks | Attacks | |||
| B.6. since draft-duke-quic-version-aliasing-00 | B.7. since draft-duke-quic-version-aliasing-00 | |||
| * Added "Initial Token Extensions" to increase salt entropy and make | * Added "Initial Token Extensions" to increase salt entropy and make | |||
| salt polling attacks impractical. | salt polling attacks impractical. | |||
| * Allowed servers to store a mapping of version number and ITE to | * Allowed servers to store a mapping of version number and ITE to | |||
| salt instead. | salt instead. | |||
| * Made standard version encoding mandatory. This dramatically | * Made standard version encoding mandatory. This dramatically | |||
| simplifies the new Retry logic and changes the security model. | simplifies the new Retry logic and changes the security model. | |||
| * Added references to Version Negotiation Transport Parameters. | * Added references to Version Negotiation Transport Parameters. | |||
| * Extensive readability edit. | * Extensive readability edit. | |||
| Author's Address | Author's Address | |||
| Martin Duke | Martin Duke | |||
| F5 Networks, Inc. | ||||
| Email: martin.h.duke@gmail.com | Email: martin.h.duke@gmail.com | |||
| End of changes. 49 change blocks. | ||||
| 146 lines changed or deleted | 265 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||