RFC 9369 - QUIC Version 2

• Status: Proposed Standard
• Veröffentlicht: May 2023
• Stream: IETF
• Errata: Keine Errata

---

Abstract

This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.

Dieses Dokument spezifiziert QUIC Version 2, die bis auf einige triviale Details mit QUIC Version 1 identisch ist. Ihr Zweck ist es, verschiedene Ossifikationsvektoren zu bekämpfen und das Versionsaushandlungs-Framework zu testen. Es dient auch als Vorlage für die minimalen Änderungen in jeder zukünftigen Version von QUIC.

Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.

Beachten Sie, dass "Version 2" ein informeller Name für diesen Vorschlag ist, der darauf hinweist, dass es sich um die zweite Version von QUIC handelt, die als Standards Track-Dokument veröffentlicht wird. Das hier spezifizierte Protokoll verwendet eine andere Versionsnummer als 2 im Wire Image, um das Risiko einer Ossifikation zu minimieren.

Status of This Memo

This is an Internet Standards Track document.

Dies ist ein Internet Standards Track-Dokument.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Gemeinschaft. Es wurde öffentlich überprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung genehmigt. Weitere Informationen zu Internet-Standards finden Sie in Abschnitt 2 von RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9369.

Informationen zum aktuellen Status dieses Dokuments, etwaige Errata und Hinweise, wie Sie Feedback dazu geben können, erhalten Sie unter https://www.rfc-editor.org/info/rfc9369.

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2023 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (https://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments gelten. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Code-Komponenten, die aus diesem Dokument extrahiert wurden, müssen den Text der überarbeiteten BSD-Lizenz enthalten, wie in Abschnitt 4.e der rechtlichen Bestimmungen des Trust beschrieben, und werden ohne Gewährleistung bereitgestellt, wie in der überarbeiteten BSD-Lizenz beschrieben.

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. Differences with QUIC Version 1
• 4. Version Negotiation Considerations
• 5. TLS Resumption and NEW_TOKEN Tokens
• 6. Ossification Considerations
• 7. Applicability
• 8. Security Considerations
• 9. IANA Considerations
• 10. References
• Appendix A. Sample Packet Protection
• Acknowledgments
• Author's Address

1. Introduction

QUIC version 1 [QUIC] has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see [QUIC-INVARIANTS]). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes that are usually 0x00000001.

QUIC Version 1 [QUIC] verfügt über zahlreiche Erweiterungspunkte, einschließlich der Versionsnummer, die das zweite bis fünfte Byte jedes langen Headers belegt (siehe [QUIC-INVARIANTS]). Wenn experimentelle Versionen selten sind und QUIC Version 1 die überwiegende Mehrheit des QUIC-Verkehrs ausmacht, besteht die Möglichkeit, dass Middleboxen auf den Versionsbytes ossifizieren, die normalerweise 0x00000001 sind.

In QUIC version 1, Initial packets are encrypted with the version-specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats.

In QUIC Version 1 werden Initial-Pakete mit dem versionsspezifischen Salt verschlüsselt, wie in Abschnitt 5.2 von [QUIC-TLS] beschrieben. Der Schutz von Initial-Paketen auf diese Weise ermöglicht es Beobachtern, ihren Inhalt zu inspizieren, der die TLS Client Hello- oder Server Hello-Nachrichten enthält. Auch hier besteht die Möglichkeit, dass Middleboxen auf der Schlüsselableitung und den Paketformaten der Version 1 ossifizieren.

Finally, [QUIC-VN] describes two mechanisms endpoints can use to negotiate which QUIC version to select. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically.

Schließlich beschreibt [QUIC-VN] zwei Mechanismen, mit denen Endpunkte aushandeln können, welche QUIC-Version ausgewählt werden soll. Die "inkompatible" Versionsaushandlungsmethode kann den Wechsel von jeder QUIC-Version zu jeder anderen Version mit voller Allgemeinheit unterstützen, auf Kosten eines zusätzlichen Roundtrips zu Beginn der Verbindung. Die "kompatible" Versionsaushandlung eliminiert die Roundtrip-Strafe, erlegt jedoch einige Einschränkungen auf, wie stark sich die beiden Versionen semantisch unterscheiden können.

QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify each Long Header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version.

QUIC Version 2 soll Bedenken hinsichtlich der Ossifikation mildern und die Versionsaushandlungsmechanismen testen. Die Änderungen liefern ein Beispiel für den minimalen Satz von Änderungen, die erforderlich sind, um eine neue QUIC-Version zu spezifizieren. Beachten Sie jedoch, dass die Wahl der Versionsnummer auf dem Draht zufällig anstelle von "2" gewählt wird und die zwei Bits, die jeden Long Header-Pakettyp identifizieren, sich von Version 1 unterscheiden; beide Eigenschaften sollen der Ossifikation entgegenwirken und sind für eine neue QUIC-Version nicht unbedingt erforderlich.

Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks.

Jeder Endpunkt, der zwei Versionen unterstützt, muss eine Versionsaushandlung implementieren, um sich gegen Downgrade-Angriffe zu schützen.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

3. Differences with QUIC Version 1

Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY]. The remainder of this section lists the differences.

Mit Ausnahme einiger weniger Unterschiede MÜSSEN QUIC Version 2-Endpunkte die QUIC Version 1-Spezifikation implementieren, wie in [QUIC], [QUIC-TLS] und [QUIC-RECOVERY] beschrieben. Der Rest dieses Abschnitts listet die Unterschiede auf.

3.1. Version Field

The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number".

Das Version-Feld der langen Header ist 0x6b3343cf. Dies wurde generiert, indem die ersten vier Bytes der sha256sum von "QUICv2 version number" genommen wurden.

3.2. Long Header Packet Types

All version 2 Long Header packet types are different. The Type field values are:

Alle Version 2 Long Header-Pakettypen sind unterschiedlich. Die Type-Feldwerte sind:

• Initial: 0b01
• 0-RTT: 0b10
• Handshake: 0b11
• Retry: 0b00

3.3. Cryptography Changes

3.3.1. Initial Salt

The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to:

Das Salt, das zur Ableitung von Initial-Schlüsseln in Abschnitt 5.2 von [QUIC-TLS] verwendet wird, ändert sich zu:

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

This is the first 20 bytes of the sha256sum of "QUICv2 salt".

Dies sind die ersten 20 Bytes der sha256sum von "QUICv2 salt".

3.3.2. HMAC-based Key Derivation Function (HKDF) Labels

The labels used in [QUIC-TLS] to derive packet protection keys (Section 5.1), header protection keys (Section 5.4), Retry Integrity Tag keys (Section 5.8), and key updates (Section 6.1) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku" to meet the guidance for new versions in Section 9.6 of that document.

Die in [QUIC-TLS] verwendeten Labels zur Ableitung von Paketschutzschlüsseln (Abschnitt 5.1), Headerschutzschlüsseln (Abschnitt 5.4), Retry Integrity Tag-Schlüsseln (Abschnitt 5.8) und Schlüsselaktualisierungen (Abschnitt 6.1) ändern sich von "quic key" zu "quicv2 key", von "quic iv" zu "quicv2 iv", von "quic hp" zu "quicv2 hp" und von "quic ku" zu "quicv2 ku", um den Richtlinien für neue Versionen in Abschnitt 9.6 dieses Dokuments zu entsprechen.

3.3.3. Retry Integrity Tag

The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to:

Der Schlüssel und die Nonce, die für das Retry Integrity Tag (Abschnitt 5.8 von [QUIC-TLS]) verwendet werden, ändern sich zu:

secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 nonce = 0xd86969bc2d7c6d9990efb04a

The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively.

Das Secret ist die sha256sum von "QUICv2 retry secret". Der Schlüssel und die Nonce werden mit den Labels "quicv2 key" bzw. "quicv2 iv" von diesem Secret abgeleitet.

4. Version Negotiation Considerations

QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc [RFC7838] to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers SHOULD support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1, as it was the original QUIC version used by HTTP/3; therefore, some clients will only support that version.

QUIC Version 2 ist nicht dazu gedacht, Version 1 abzulehnen. Endpunkte, die Version 2 unterstützen, können Version 1 weiterhin unterstützen, um die Kompatibilität mit anderen Endpunkten zu maximieren. Insbesondere verwenden HTTP-Clients häufig Alt-Svc [RFC7838], um QUIC-Unterstützung zu entdecken. Da dieser Mechanismus derzeit nicht zwischen QUIC-Versionen unterscheidet, SOLLTEN HTTP-Server mehrere Versionen unterstützen, um die Wahrscheinlichkeit einer Inkompatibilität und die mit der QUIC-Versionsaushandlung oder dem TCP-Fallback verbundenen Kosten zu verringern. Beispielsweise sollte ein Ursprung, der Unterstützung für "h3" in Alt-Svc ankündigt, QUIC Version 1 unterstützen, da dies die ursprüngliche QUIC-Version war, die von HTTP/3 verwendet wurde; daher werden einige Clients nur diese Version unterstützen.

Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.

Jeder QUIC-Endpunkt, der QUIC Version 2 unterstützt, MUSS den in [QUIC-VN] spezifizierten version_information-Transportparameter senden, verarbeiten und validieren, um Versions-Downgrade-Angriffe zu verhindern.

Note that version 2 meets the definition in [QUIC-VN] of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip.

Beachten Sie, dass Version 2 die Definition in [QUIC-VN] einer kompatiblen Version mit Version 1 erfüllt und Version 1 mit Version 2 kompatibel ist. Daher können Server die kompatible Aushandlung verwenden, um eine Verbindung zwischen den beiden Versionen umzuschalten. Endpunkte, die beide Versionen unterstützen, SOLLTEN die kompatible Versionsaushandlung unterstützen, um einen Roundtrip zu vermeiden.

4.1. Compatible Negotiation Requirements

Compatible version negotiation between versions 1 and 2 follows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from [QUIC-VN].

Die kompatible Versionsaushandlung zwischen den Versionen 1 und 2 folgt in beiden Richtungen denselben Anforderungen. Dieser Abschnitt verwendet die Begriffe "Originalversion" und "ausgehandelte Version" aus [QUIC-VN].

If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance.

Wenn der Server ein Retry-Paket sendet, MUSS er die Originalversion verwenden. Der Client ignoriert Retry-Pakete, die andere Versionen verwenden. Der Client DARF KEINE andere Version im nachfolgenden Initial-Paket verwenden, das das Retry-Token enthält. Der Server KANN die QUIC-Version in seinem Retry-Token codieren, um zu validieren, dass der Client die Version nicht gewechselt hat, und das Paket verwerfen, wenn er gewechselt hat, um die Compliance des Clients durchzusetzen.

QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of [QUIC].

QUIC Version 2 verwendet dieselben Transportparameter zur Authentifizierung des Retry wie QUIC Version 1. Nach dem Wechsel zu einer ausgehandelten Version nach einem Retry MUSS der Server die relevanten Transportparameter einschließen, um zu validieren, dass der Server das Retry gesendet hat, sowie die im Austausch verwendeten Verbindungs-IDs, wie in Abschnitt 7.3 von [QUIC] beschrieben.

The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version.

Der Server kann keine CRYPTO-Frames senden, bis er die Transportparameter des Clients verarbeitet hat. Der Server MUSS alle CRYPTO-Frames unter Verwendung der ausgehandelten Version senden.

The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, it indicates that the negotiated version is equal to the original version.

Der Client lernt die ausgehandelte Version, indem er das erste Version-Feld des langen Headers beobachtet, das sich von der Originalversion unterscheidet. Wenn der Client einen CRYPTO-Frame vom Server in der Originalversion empfängt, zeigt dies an, dass die ausgehandelte Version gleich der Originalversion ist.

Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version.

Bevor der Server Transportparameter vom Client verarbeiten kann, muss er möglicherweise auf Initial-Pakete vom Client antworten. Für diese Pakete verwendet der Server die Originalversion.

Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version.

Sobald der Client die ausgehandelte Version gelernt hat, SOLLTE er nachfolgende Initial-Pakete unter Verwendung dieser Version senden. Der Server DARF seine Initial-Empfangsschlüssel der Originalversion NICHT verwerfen, bis er ein Handshake-Paket mit der ausgehandelten Version erfolgreich verarbeitet hat.

Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets.

Beide Endpunkte MÜSSEN Handshake- und 1-RTT-Pakete unter Verwendung der ausgehandelten Version senden. Ein Endpunkt MUSS Pakete verwerfen, die eine andere Version verwenden. Endpunkte müssen kein Schlüsselmaterial generieren, das es ihnen ermöglichen würde, solche Pakete zu entschlüsseln oder zu authentifizieren.

The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version.

Der Client DARF KEINE 0-RTT-Pakete unter Verwendung der ausgehandelten Version senden, auch nicht nach der Verarbeitung eines Pakets dieser Version vom Server. Server können 0-RTT akzeptieren und dann 0-RTT-Pakete der Originalversion verarbeiten.

5. TLS Resumption and NEW_TOKEN Tokens

TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, and vice versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one.

TLS-Sitzungstickets und NEW_TOKEN-Token sind spezifisch für die QUIC-Version der Verbindung, die sie bereitgestellt hat. Clients DÜRFEN KEIN Sitzungsticket oder Token aus einer QUIC Version 1-Verbindung verwenden, um eine QUIC Version 2-Verbindung zu initiieren, und umgekehrt. Wenn eine Verbindung eine kompatible Versionsaushandlung umfasst, gelten alle ausgestellten Server-Token als von der ausgehandelten Version stammend, nicht von der ursprünglichen.

Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send.

Server MÜSSEN die Ursprungsversion jedes Sitzungstickets oder Tokens validieren und dürfen keines akzeptieren, das von einer anderen Version ausgestellt wurde. Ein abgelehntes Ticket führt zu einem Fallback auf einen vollständigen TLS-Handshake ohne 0-RTT. Ein abgelehntes Token führt dazu, dass die Client-Adresse unverifiziert bleibt, was die Datenmenge begrenzt, die der Server senden kann.

After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one.

Nach einer kompatiblen Versionsaushandlung wird jedes resultierende Sitzungsticket der ausgehandelten Version zugeordnet und nicht der ursprünglichen.

6. Ossification Considerations

QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets.

QUIC Version 2 bietet Schutz gegen einige Formen der Ossifikation. Geräte, die annehmen, dass alle langen Header Version 1 codieren, oder dass die Version 1 Initial-Schlüsselableitungsformel versionsinvariant bleibt, werden Version 2-Pakete nicht korrekt verarbeiten.

However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above.

Viele Middleboxen, wie z. B. Firewalls, konzentrieren sich jedoch auf das erste Paket einer Verbindung, das aufgrund der oben genannten Überlegungen oft im Version 1-Format verbleiben wird.

Clients interested in combating middlebox ossification can initiate a connection using version 2 if they are reasonably certain the server supports it and if they are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed.

Clients, die daran interessiert sind, die Ossifikation von Middleboxen zu bekämpfen, können eine Verbindung unter Verwendung von Version 2 initiieren, wenn sie einigermaßen sicher sind, dass der Server dies unterstützt, und wenn sie bereit sind, eine Roundtrip-Strafe zu erleiden, wenn sie falsch liegen. Insbesondere zeigt ein Server, der ein Sitzungsticket für Version 2 ausstellt, die Absicht an, die Unterstützung für Version 2 aufrechtzuerhalten, solange das Ticket gültig bleibt, auch wenn die Unterstützung nicht garantiert werden kann.

7. Applicability

QUIC version 2 provides no change from QUIC version 1 for the capabilities available to applications. Therefore, all Application-Layer Protocol Negotiation (ALPN) [RFC7301] codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" [HTTP/3] and "doq" [RFC9250] ALPNs can operate over QUIC version 2.

QUIC Version 2 bietet keine Änderung gegenüber QUIC Version 1 für die Funktionen, die Anwendungen zur Verfügung stehen. Daher können alle Application-Layer Protocol Negotiation (ALPN) [RFC7301]-Codepoints, die für den Betrieb über QUIC Version 1 spezifiziert sind, auch über diese Version von QUIC betrieben werden. Insbesondere können sowohl die "h3" [HTTP/3]- als auch die "doq" [RFC9250]-ALPNs über QUIC Version 2 betrieben werden.

Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2.

Sofern nicht anders angegeben, funktionieren alle QUIC-Erweiterungen, die für die Zusammenarbeit mit Version 1 definiert sind, auch mit Version 2.

8. Security Considerations

QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.

QUIC Version 2 führt keine Änderungen an den Sicherheits- oder Datenschutzeigenschaften von QUIC Version 1 ein.

The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical.

Der obligatorische Versionsaushandlungsmechanismus schützt vor Downgrade-Angriffen, aber Downgrades haben keine Sicherheitsauswirkungen, da die Versionseigenschaften identisch sind.

Support for QUIC version 2 can help an observer to fingerprint both client and server devices.

Die Unterstützung für QUIC Version 2 kann einem Beobachter helfen, sowohl Client- als auch Servergeräte per Fingerprinting zu identifizieren.

9. IANA Considerations

IANA has added the following entries to the "QUIC Versions" registry maintained at https://www.iana.org/assignments/quic.

Die IANA hat die folgenden Einträge zum Register "QUIC Versions" hinzugefügt, das unter https://www.iana.org/assignments/quic geführt wird.

Value: 0x6b3343cf Status: permanent Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG

Value: 0x709a50c4 Status: provisional Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG Notes: QUIC v2 draft codepoint

10. References

10.1. Normative References

[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, https://www.rfc-editor.org/info/rfc9002.

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, https://www.rfc-editor.org/info/rfc9001.

[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May 2023, https://www.rfc-editor.org/info/rfc9368.

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

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

10.2. Informative References

[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, https://www.rfc-editor.org/info/rfc9114.

[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, https://www.rfc-editor.org/info/rfc8999.

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

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, https://www.rfc-editor.org/info/rfc7838.

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, https://www.rfc-editor.org/info/rfc9250.

Appendix A. Sample Packet Protection

This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both the client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal.

Dieser Abschnitt zeigt Beispiele für den Paketschutz, damit Implementierungen schrittweise verifiziert werden können. Beispiele für Initial-Pakete sowohl vom Client als auch vom Server sowie ein Retry-Paket werden definiert. Diese Pakete verwenden eine 8-Byte-Client-gewählte Zielverbindungs-ID von 0x8394c8f03e515708. Einige Zwischenwerte sind enthalten. Alle Werte werden hexadezimal angezeigt.

(See RFC text for details on A.1 - A.5, code blocks are untranslated)

Acknowledgments

The author would like to thank Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their helpful suggestions.

Der Autor möchte Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa und Martin Thomson für ihre hilfreichen Vorschläge danken.

Author's Address

Martin Duke Google LLC Email: [email protected]