Okay, here is the abstract, summary, and glossary for the provided RFC text on QUIC Version 2, following your example format.
Abstract:
This document, RFC 9369, specifies QUIC version 2 (informally named), a Standards Track document identical to QUIC version 1 except for minimal, specifically chosen details. Its primary purpose is to serve as a test for the QUIC version negotiation framework and to proactively combat potential network ossification where middleboxes might become fixed on the specifics of QUIC version 1. The changes include a different wire version number (not the numerical value '2'), altered long header packet type bit patterns, and modified cryptographic parameters such as the Initial Salt and HKDF labels. While functionally equivalent to version 1 for applications, these "trivial details" provide distinct wire images and cryptographic derivations to exercise network paths and implementations against ossification. The document also outlines considerations for version negotiation and TLS resumption/tokens, emphasizing the compatibility between versions 1 and 2.
Summarizing QUIC Version 2 (RFC 9369)
Introduction / Purpose: QUIC Version 2 is specified with minimal differences from Version 1 to combat network ossification (devices fixing on V1 specifics) and test the version negotiation framework.
[Section 3.1] Wire Version Number: The actual value used in the Version field of long headers is 0x6b3343cf, explicitly not the simple numeral '2', to further resist ossification.
[Section 3.2] Long Header Packet Types: The bit patterns identifying different Long Header packet types (Initial, 0-RTT, Handshake, Retry) are changed from Version 1.
[Section 3.3] Cryptography Changes: Version 2 uses a different Initial Salt (0x0dede3def700a6db819381be6e269dcbf9bd2ed9), different HMAC-based Key Derivation Function (HKDF) labels (e.g., "quicv2 key" instead of "quic key"), and a different key/nonce for the Retry Integrity Tag.
[Section 4] Version Negotiation: Endpoints supporting Version 2 MUST implement the version_information transport parameter. Version 2 is defined as compatible with Version 1, and compatible negotiation is recommended to avoid extra round trips.
[Section 4.1] Compatible Negotiation Details: Specific rules for negotiating between v1 and v2 are defined, including which version to use for Retry, Initial (after negotiation), Handshake, and 1-RTT packets.
[Section 5] TLS Resumption and Tokens: TLS session tickets and NEW_TOKEN tokens are version-specific and cannot be used between Version 1 and Version 2 connections.
[Section 7] Applicability: Version 2 provides no new capabilities for applications. Application protocols (like HTTP/3) and extensions designed for Version 1 can operate over Version 2.
[Section 8] Security Considerations: Version 2 introduces no changes to the security or privacy properties of Version 1. Version negotiation prevents theoretical downgrade attacks, but since v1 and v2 are functionally identical, this has no practical security impact.
Glossary
Ossification: In the context of network protocols, this refers to middleboxes or other network devices becoming fixed on specific byte patterns or behaviors of an older protocol version, potentially interfering with newer versions that deviate from those specifics.
Version Negotiation: The process by which two endpoints communicating over QUIC determine and agree upon which version of the QUIC protocol they will use for the connection.
Initial Salt: A fixed value specified per QUIC version, used in the derivation of cryptographic keys for the initial packets of a connection.
HKDF (HMAC-based Key Derivation Function): A cryptographic function used to derive multiple secret keys from a single master secret. Different labels are used in the function to ensure the derived keys are distinct.
Retry Integrity Tag: A cryptographic authentication tag included in QUIC Retry packets, used by the client to verify that the packet was sent by a legitimate server and has not been tampered with.
Compatible Version Negotiation: A specific method of QUIC version negotiation (defined in RFC 9368) that allows endpoints to switch to a preferred version without adding a round trip, provided the original and negotiated versions meet certain compatibility requirements.
TLS Resumption / Session Ticket: Mechanisms used in TLS (and by QUIC) to quickly re-establish a connection with a server that the client has recently connected to, often skipping the full TLS handshake process by using previously shared state.
NEW_TOKEN Token: A QUIC token sent by the server that allows a client to prove ownership of an address after a connection migration, enabling the server to send more data before the client's address is fully validated.