diff --git a/draft-ietf-quic-http.html b/draft-ietf-quic-http.html index dc3eb1f6c2..01b60a3ad5 100644 --- a/draft-ietf-quic-http.html +++ b/draft-ietf-quic-http.html @@ -17,21 +17,21 @@ @@ -844,7 +844,7 @@
- This Internet-Draft will expire on 12 August 2021.¶
1. Introduction¶
2. HTTP/3 Protocol Overview¶
3. Connection Setup and Management¶
3.1. Discovering an HTTP/3 Endpoint¶
3.1.1. HTTP Alternative Services¶
3.1.2. Other Schemes¶
4. HTTP Request Lifecycle¶
4.1. HTTP Message Exchanges¶
4.1.1. Field Formatting and Compression¶
4.1.2. Request Cancellation and Rejection¶
4.1.3. Malformed Requests and Responses¶
5. Connection Closure¶
6. Stream Mapping and Usage¶
6.2. Unidirectional Streams¶
6.2.1. Control Streams¶
6.2.2. Push Streams¶
6.2.3. Reserved Stream Types¶
7. HTTP Framing Layer¶
7.2. Frame Definitions¶
7.2.1. DATA¶
7.2.2. HEADERS¶
7.2.3. CANCEL_PUSH¶
7.2.4. SETTINGS¶
7.2.5. PUSH_PROMISE¶
7.2.6. GOAWAY¶
7.2.7. MAX_PUSH_ID¶
7.2.8. Reserved Frame Types¶
8. Error Handling¶
9. Extensions to HTTP/3¶
10. Security Considerations¶
10.5. Denial-of-Service Considerations¶
10.5.1. Limits on Field Section Size¶
10.5.2. CONNECT Issues¶
11. IANA Considerations¶
11.2. New Registries¶
11.2.1. Frame Types¶
11.2.2. Settings Parameters¶
11.2.3. Error Codes¶
11.2.4. Stream Types¶
12. References¶
Appendix A. Considerations for Transitioning from HTTP/2¶
A.2. HTTP Frame Types¶
A.2.1. Prioritization Differences¶
A.2.2. Field Compression Differences¶
A.2.3. Flow Control Differences¶
A.2.4. Guidance for New Frame Type Definitions¶
A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types¶
A.4. HTTP/2 Error Codes¶
A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors¶
Appendix B. Change Log¶
Acknowledgments¶
Author's Address¶
Contains the scheme portion of the target URI (Section 3.1 of [URI])¶
Contains the authority portion of the target URI (Section 3.2 of [URI]). +
Contains the authority portion of the target URI (Section 3.2 of [URI]). The authority MUST NOT include the deprecated "userinfo" subcomponent for URIs of scheme "http" or "https".¶
Contains the path and query parts of the target URI (the "path-absolute" production and optionally a '?' character followed by the "query" -production; see Sections 3.3 and 3.4 of [URI]. A request in +production; see Sections 3.3 and 3.4 of [URI]. A request in asterisk form includes the value '*' for the ":path" pseudo-header field.¶
Each server push is assigned a unique Push ID by the server. The Push ID is used to refer to the push in various contexts throughout the lifetime of the HTTP/3 connection.¶
The security considerations of HTTP/3 should be comparable to those of HTTP/2 -with TLS. However, many of the considerations from Section 10 of [HTTP2] +with TLS. However, many of the considerations from Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in that document.¶
While this registry is separate from the "HTTP/2 Frame Type" registry defined in [HTTP2], it is preferable that the assignments parallel each other where the code spaces overlap. If an entry is present in only one registry, every effort @@ -3812,7 +3812,7 @@
While this registry is separate from the "HTTP/2 Settings" registry defined in [HTTP2], it is preferable that the assignments parallel each other. If an entry is present in only one registry, every effort SHOULD be made to avoid @@ -3909,7 +3909,7 @@
Registrations for error codes are required to include a description of the error code. An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be @@ -4105,7 +4105,7 @@
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following fields:¶
QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 mean that error codes are not directly portable between versions.¶
The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map to +
The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map to the HTTP/3 error codes as follows:¶
1. An Extremely Abstract Description of QUIC¶
2. Fixed Properties of All QUIC Versions¶
3. Conventions and Definitions¶
4. Notational Conventions¶
5. QUIC Packets¶
5.1. Long Header¶
5.2. Short Header¶
5.3. Connection ID¶
5.4. Version¶
6. Version Negotiation¶
7. Security and Privacy Considerations¶
8. IANA Considerations¶
9. References¶
9.1. Normative References¶
9.2. Informative References¶
Appendix A. Incorrect Assumptions¶
1.1. Conventions and Definitions¶
1.2. Notational Conventions¶
2. Compression Process Overview¶
2.1. Encoder¶
2.1.1. Limits on Dynamic Table Insertions¶
2.1.2. Blocked Streams¶
2.1.3. Avoiding Flow Control Deadlocks¶
2.1.4. Known Received Count¶
2.2. Decoder¶
2.2.1. Blocked Decoding¶
2.2.2. State Synchronization¶
2.2.3. Invalid References¶
3. Reference Tables¶
3.1. Static Table¶
3.2. Dynamic Table¶
3.2.1. Dynamic Table Size¶
3.2.2. Dynamic Table Capacity and Eviction¶
3.2.3. Maximum Dynamic Table Capacity¶
3.2.4. Absolute Indexing¶
3.2.5. Relative Indexing¶
3.2.6. Post-Base Indexing¶
4. Wire Format¶
4.1. Primitives¶
4.1.1. Prefixed Integers¶
4.1.2. String Literals¶
4.2. Encoder and Decoder Streams¶
4.3. Encoder Instructions¶
4.3.1. Set Dynamic Table Capacity¶
4.3.2. Insert With Name Reference¶
4.3.3. Insert With Literal Name¶
4.3.4. Duplicate¶
4.4. Decoder Instructions¶
4.4.1. Section Acknowledgment¶
4.4.2. Stream Cancellation¶
4.4.3. Insert Count Increment¶
4.5. Field Line Representations¶
4.5.1. Encoded Field Section Prefix¶
4.5.2. Indexed Field Line¶
4.5.3. Indexed Field Line With Post-Base Index¶
4.5.4. Literal Field Line With Name Reference¶
4.5.5. Literal Field Line With Post-Base Name Reference¶
4.5.6. Literal Field Line With Literal Name¶
5. Configuration¶
6. Error Handling¶
7. Security Considerations¶
7.1. Probing Dynamic Table State¶
7.1.1. Applicability to QPACK and HTTP¶
7.1.2. Mitigation¶
7.1.3. Never-Indexed Literals¶
7.2. Static Huffman Encoding¶
7.3. Memory Consumption¶
7.4. Implementation Limits¶
8.1. Settings Registration¶
8.2. Stream Type Registration¶
8.3. Error Code Registration¶
Appendix A. Static Table¶
Appendix B. Encoding and Decoding Examples¶
B.1. Literal Field Line With Name Reference¶
B.2. Dynamic Table¶
B.3. Speculative Insert¶
B.4. Duplicate Instruction, Stream Cancellation¶
B.5. Dynamic Table Insert, Eviction¶
Appendix C. Sample One Pass Encoding Algorithm¶
Appendix D. Change Log¶
D.1. Since draft-ietf-quic-qpack-19¶
D.2. Since draft-ietf-quic-qpack-18¶
D.3. Since draft-ietf-quic-qpack-17¶
D.4. Since draft-ietf-quic-qpack-16¶
D.5. Since draft-ietf-quic-qpack-15¶
D.6. Since draft-ietf-quic-qpack-14¶
D.7. Since draft-ietf-quic-qpack-13¶
D.8. Since draft-ietf-quic-qpack-12¶
D.9. Since draft-ietf-quic-qpack-11¶
D.10. Since draft-ietf-quic-qpack-10¶
D.11. Since draft-ietf-quic-qpack-09¶
D.12. Since draft-ietf-quic-qpack-08¶
D.13. Since draft-ietf-quic-qpack-06¶
D.14. Since draft-ietf-quic-qpack-05¶
D.15. Since draft-ietf-quic-qpack-04¶
D.16. Since draft-ietf-quic-qpack-03¶
D.17. Since draft-ietf-quic-qpack-02¶
D.18. Since draft-ietf-quic-qpack-01¶
D.19. Since draft-ietf-quic-qpack-00¶
D.20. Since draft-ietf-quic-qcram-00¶
Authors' Addresses¶
Diagrams use the format described in Section 3.1 of [RFC2360], with the +
Diagrams use the format described in Section 3.1 of [RFC2360], with the following additional conventions:¶
The prefixed integer from Section 5.1 of [RFC7541] is used heavily throughout +
The prefixed integer from Section 5.1 of [RFC7541] is used heavily throughout this document. The format from [RFC7541] is used unmodified. Note, however, that QPACK uses some prefix sizes not actually used in HPACK.¶
QPACK implementations MUST be able to decode integers up to and including 62 @@ -1929,13 +1929,13 @@
The string literal defined by Section 5.2 of [RFC7541] is also used +
The string literal defined by Section 5.2 of [RFC7541] is also used throughout. This string format includes optional Huffman encoding.¶
HPACK defines string literals to begin on a byte boundary. They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data. When Huffman encoding is enabled, the Huffman -table from Appendix B of [RFC7541] is used without modification and Length +table from Appendix B of [RFC7541] is used without modification and Length indicates the size of the string after encoding.¶
This document expands the definition of string literals by permitting them to begin other than on a byte boundary. An "N-bit prefix string literal" begins @@ -2732,7 +2732,7 @@
The choice to mark that a field value should never be indexed depends on several factors. Since QPACK does not protect against guessing an entire field value, short or low-entropy values are more readily recovered by an adversary. @@ -2979,11 +2979,11 @@
2. Conventions and Definitions¶
3. Design of the QUIC Transmission Machinery¶
4. Relevant Differences Between QUIC and TCP¶
4.1. Separate Packet Number Spaces¶
4.2. Monotonically Increasing Packet Numbers¶
4.3. Clearer Loss Epoch¶
4.4. No Reneging¶
4.5. More ACK Ranges¶
4.6. Explicit Correction For Delayed Acknowledgments¶
4.7. Probe Timeout Replaces RTO and TLP¶
4.8. The Minimum Congestion Window is Two Packets¶
5. Estimating the Round-Trip Time¶
5.1. Generating RTT samples¶
5.2. Estimating min_rtt¶
5.3. Estimating smoothed_rtt and rttvar¶
6. Loss Detection¶
6.1. Acknowledgment-Based Detection¶
6.1.1. Packet Threshold¶
6.1.2. Time Threshold¶
6.2. Probe Timeout¶
6.2.1. Computing PTO¶
6.2.2. Handshakes and New Paths¶
6.2.3. Speeding Up Handshake Completion¶
6.2.4. Sending Probe Packets¶
6.3. Handling Retry Packets¶
6.4. Discarding Keys and Packet State¶
7. Congestion Control¶
7.1. Explicit Congestion Notification¶
7.2. Initial and Minimum Congestion Window¶
7.3. Congestion Control States¶
7.3.1. Slow Start¶
7.3.2. Recovery¶
7.3.3. Congestion Avoidance¶
7.4. Ignoring Loss of Undecryptable Packets¶
7.5. Probe Timeout¶
7.6. Persistent Congestion¶
7.6.1. Duration¶
7.6.2. Establishing Persistent Congestion¶
7.6.3. Example¶
7.7. Pacing¶
7.8. Under-utilizing the Congestion Window¶
8. Security Considerations¶
8.1. Loss and Congestion Signals¶
8.2. Traffic Analysis¶
8.3. Misreporting ECN Markings¶
9. IANA Considerations¶
10. References¶
10.1. Normative References¶
10.2. Informative References¶
Appendix A. Loss Recovery Pseudocode¶
A.1. Tracking Sent Packets¶
A.1.1. Sent Packet Fields¶
A.2. Constants of Interest¶
A.3. Variables of interest¶
A.4. Initialization¶
A.5. On Sending a Packet¶
A.6. On Receiving a Datagram¶
A.7. On Receiving an Acknowledgment¶
A.8. Setting the Loss Detection Timer¶
A.9. On Timeout¶
A.10. Detecting Lost Packets¶
A.11. Upon Dropping Initial or Handshake Keys¶
Appendix B. Congestion Control Pseudocode¶
B.1. Constants of interest¶
B.2. Variables of interest¶
B.3. Initialization¶
B.4. On Packet Sent¶
B.5. On Packet Acknowledgment¶
B.6. On New Congestion Event¶
B.7. Process ECN Information¶
B.8. On Packets Lost¶
B.9. Removing Discarded Packets From Bytes In Flight¶
Appendix C. Change Log¶
C.1. Since draft-ietf-quic-recovery-32¶
C.2. Since draft-ietf-quic-recovery-31¶
C.3. Since draft-ietf-quic-recovery-30¶
C.4. Since draft-ietf-quic-recovery-29¶
C.5. Since draft-ietf-quic-recovery-28¶
C.6. Since draft-ietf-quic-recovery-27¶
C.7. Since draft-ietf-quic-recovery-26¶
C.8. Since draft-ietf-quic-recovery-25¶
C.9. Since draft-ietf-quic-recovery-24¶
C.10. Since draft-ietf-quic-recovery-23¶
C.11. Since draft-ietf-quic-recovery-22¶
C.12. Since draft-ietf-quic-recovery-21¶
C.13. Since draft-ietf-quic-recovery-20¶
C.14. Since draft-ietf-quic-recovery-19¶
C.15. Since draft-ietf-quic-recovery-18¶
C.16. Since draft-ietf-quic-recovery-17¶
C.17. Since draft-ietf-quic-recovery-16¶
C.18. Since draft-ietf-quic-recovery-14¶
C.19. Since draft-ietf-quic-recovery-13¶
C.20. Since draft-ietf-quic-recovery-12¶
C.21. Since draft-ietf-quic-recovery-11¶
C.22. Since draft-ietf-quic-recovery-10¶
C.23. Since draft-ietf-quic-recovery-09¶
C.24. Since draft-ietf-quic-recovery-08¶
C.25. Since draft-ietf-quic-recovery-07¶
C.26. Since draft-ietf-quic-recovery-06¶
C.27. Since draft-ietf-quic-recovery-05¶
C.28. Since draft-ietf-quic-recovery-04¶
C.29. Since draft-ietf-quic-recovery-03¶
C.30. Since draft-ietf-quic-recovery-02¶
C.31. Since draft-ietf-quic-recovery-01¶
C.32. Since draft-ietf-quic-recovery-00¶
C.33. Since draft-iyengar-quic-loss-recovery-01¶
Appendix D. Contributors¶
A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in Appendix A.2) for a new path, but the delay SHOULD NOT be @@ -2071,7 +2071,7 @@
If a sender uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion control guidelines -specified in Section 3.1 of [RFC8085].¶
Similar to TCP, packets containing only ACK frames do not count towards bytes in flight and are not congestion controlled. Unlike TCP, QUIC can detect the loss of these packets and MAY use that information to adjust the congestion @@ -2191,7 +2191,7 @@
The recovery period aims to limit congestion window reduction to once per round trip. Therefore during a recovery period, the congestion window does not change in response to new losses or increases in the ECN-CE count.¶
In congestion avoidance, implementers that use an integer representation for congestion_window should be careful with division, and can use -the alternative approach suggested in Section 2.1 of [RFC3465].¶
InCongestionRecovery(sent_time): @@ -3512,8 +3512,8 @@ Appendix C. Change Log - - + + RFC Editor's Note: Please remove this section prior to publication of a final version of this document.¶ diff --git a/draft-ietf-quic-recovery.txt b/draft-ietf-quic-recovery.txt index ebb7e523f7..d3c97a7cee 100644 --- a/draft-ietf-quic-recovery.txt +++ b/draft-ietf-quic-recovery.txt @@ -5,8 +5,8 @@ QUIC J. Iyengar, Ed. Internet-Draft Fastly Intended status: Standards Track I. Swett, Ed. -Expires: 12 August 2021 Google - 8 February 2021 +Expires: 21 August 2021 Google + 17 February 2021 QUIC Loss Detection and Congestion Control @@ -43,7 +43,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 12 August 2021. + This Internet-Draft will expire on 21 August 2021. Copyright Notice @@ -1330,15 +1330,16 @@ Table of Contents [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", Work in Progress, Internet-Draft, draft-ietf-quic- - tls, 8 February 2021, - . + tls, 17 February 2021, + . [QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, - Internet-Draft, draft-ietf-quic-transport, 8 February - 2021, - . + Internet-Draft, draft-ietf-quic-transport, 17 February + 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -1371,7 +1372,7 @@ Table of Contents [RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The RACK-TLP loss detection algorithm for TCP", Work in Progress, Internet-Draft, draft-ietf-tcpm-rack-15, 22 - December 2020, . [RETRANSMISSION] diff --git a/draft-ietf-quic-tls.html b/draft-ietf-quic-tls.html index c635a437e2..136917e11a 100644 --- a/draft-ietf-quic-tls.html +++ b/draft-ietf-quic-tls.html @@ -15,21 +15,21 @@ @@ -842,7 +842,7 @@ Thomson & Turner -Expires 12 August 2021 +Expires 21 August 2021 [Page] @@ -855,12 +855,12 @@ draft-ietf-quic-tls Published: -8 February 2021 +17 February 2021 Intended Status: Standards Track Expires: -12 August 2021 +21 August 2021 Authors: @@ -912,7 +912,7 @@ time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶ - This Internet-Draft will expire on 12 August 2021.¶ + This Internet-Draft will expire on 21 August 2021.¶ @@ -940,359 +940,359 @@ ▲ Table of Contents - - + + 1. Introduction¶ - + 2. Notational Conventions¶ - - + + 2.1. TLS Overview¶ - + 3. Protocol Overview¶ - + 4. Carrying TLS Messages¶ - - + + 4.1. Interface to TLS¶ - - + + 4.1.1. Handshake Complete¶ - + 4.1.2. Handshake Confirmed¶ - + 4.1.3. Sending and Receiving Handshake Messages¶ - + 4.1.4. Encryption Level Changes¶ - + 4.1.5. TLS Interface Summary¶ - + 4.2. TLS Version¶ - + 4.3. ClientHello Size¶ - + 4.4. Peer Authentication¶ - + 4.5. Session Resumption¶ - + 4.6. 0-RTT¶ - - + + 4.6.1. Enabling 0-RTT¶ - + 4.6.2. Accepting and Rejecting 0-RTT¶ - + 4.6.3. Validating 0-RTT Configuration¶ - + 4.7. HelloRetryRequest¶ - + 4.8. TLS Errors¶ - + 4.9. Discarding Unused Keys¶ - - + + 4.9.1. Discarding Initial Keys¶ - + 4.9.2. Discarding Handshake Keys¶ - + 4.9.3. Discarding 0-RTT Keys¶ - + 5. Packet Protection¶ - - + + 5.1. Packet Protection Keys¶ - + 5.2. Initial Secrets¶ - + 5.3. AEAD Usage¶ - + 5.4. Header Protection¶ - - + + 5.4.1. Header Protection Application¶ - + 5.4.2. Header Protection Sample¶ - + 5.4.3. AES-Based Header Protection¶ - + 5.4.4. ChaCha20-Based Header Protection¶ - + 5.5. Receiving Protected Packets¶ - + 5.6. Use of 0-RTT Keys¶ - + 5.7. Receiving Out-of-Order Protected Packets¶ - + 5.8. Retry Packet Integrity¶ - + 6. Key Update¶ - - + + 6.1. Initiating a Key Update¶ - + 6.2. Responding to a Key Update¶ - + 6.3. Timing of Receive Key Generation¶ - + 6.4. Sending with Updated Keys¶ - + 6.5. Receiving with Different Keys¶ - + 6.6. Limits on AEAD Usage¶ - + 6.7. Key Update Error Code¶ - + 7. Security of Initial Messages¶ - + 8. QUIC-Specific Adjustments to the TLS Handshake¶ - - + + 8.1. Protocol Negotiation¶ - + 8.2. QUIC Transport Parameters Extension¶ - + 8.3. Removing the EndOfEarlyData Message¶ - + 8.4. Prohibit TLS Middlebox Compatibility Mode¶ - + 9. Security Considerations¶ - - + + 9.1. Session Linkability¶ - + 9.2. Replay Attacks with 0-RTT¶ - + 9.3. Packet Reflection Attack Mitigation¶ - + 9.4. Header Protection Analysis¶ - + 9.5. Header Protection Timing Side-Channels¶ - + 9.6. Key Diversity¶ - + 9.7. Randomness¶ - + 10. IANA Considerations¶ - + 11. References¶ - - + + 11.1. Normative References¶ - + 11.2. Informative References¶ - + Appendix A. Sample Packet Protection¶ - - + + A.1. Keys¶ - + A.2. Client Initial¶ - + A.3. Server Initial¶ - + A.4. Retry¶ - + A.5. ChaCha20-Poly1305 Short Header Packet¶ - + Appendix B. AEAD Algorithm Analysis¶ - - + + B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits¶ - - + + B.1.1. Confidentiality Limit¶ - + B.1.2. Integrity Limit¶ - + B.2. Analysis of AEAD_AES_128_CCM Usage Limits¶ - + Appendix C. Change Log¶ - - + + C.1. Since draft-ietf-quic-tls-32¶ - + C.2. Since draft-ietf-quic-tls-31¶ - + C.3. Since draft-ietf-quic-tls-30¶ - + C.4. Since draft-ietf-quic-tls-29¶ - + C.5. Since draft-ietf-quic-tls-28¶ - + C.6. Since draft-ietf-quic-tls-27¶ - + C.7. Since draft-ietf-quic-tls-26¶ - + C.8. Since draft-ietf-quic-tls-25¶ - + C.9. Since draft-ietf-quic-tls-24¶ - + C.10. Since draft-ietf-quic-tls-23¶ - + C.11. Since draft-ietf-quic-tls-22¶ - + C.12. Since draft-ietf-quic-tls-21¶ - + C.13. Since draft-ietf-quic-tls-20¶ - + C.14. Since draft-ietf-quic-tls-18¶ - + C.15. Since draft-ietf-quic-tls-17¶ - + C.16. Since draft-ietf-quic-tls-14¶ - + C.17. Since draft-ietf-quic-tls-13¶ - + C.18. Since draft-ietf-quic-tls-12¶ - + C.19. Since draft-ietf-quic-tls-11¶ - + C.20. Since draft-ietf-quic-tls-10¶ - + C.21. Since draft-ietf-quic-tls-09¶ - + C.22. Since draft-ietf-quic-tls-08¶ - + C.23. Since draft-ietf-quic-tls-07¶ - + C.24. Since draft-ietf-quic-tls-05¶ - + C.25. Since draft-ietf-quic-tls-04¶ - + C.26. Since draft-ietf-quic-tls-03¶ - + C.27. Since draft-ietf-quic-tls-02¶ - + C.28. Since draft-ietf-quic-tls-01¶ - + C.29. Since draft-ietf-quic-tls-00¶ - + C.30. Since draft-thomson-quic-tls-01¶ - + Contributors¶ - + Authors' Addresses¶ @@ -1933,7 +1933,7 @@ The requirements for client authentication vary based on application protocol and deployment.¶ A server MUST NOT use post-handshake client authentication (as defined in -Section 4.6.2 of [TLS13]), because the multiplexing offered by QUIC prevents +Section 4.6.2 of [TLS13]), because the multiplexing offered by QUIC prevents clients from correlating the certificate request with the application-level event that triggered it (see [HTTP2-TLS13]). More specifically, servers MUST NOT send post-handshake TLS CertificateRequest @@ -1952,7 +1952,7 @@ used when 0-RTT is disabled.¶ Endpoints that use session resumption might need to remember some information about the current connection when creating a resumed connection. TLS requires -that some information be retained; see Section 4.6.1 of [TLS13]. QUIC itself +that some information be retained; see Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state being retained when resuming a connection, unless 0-RTT is also used; see Section 7.4.1 of [QUIC-TRANSPORT] and Section 4.6.1. Application protocols could depend on state that is retained @@ -1963,7 +1963,7 @@ with the resumed connection, which might be a privacy issue for clients. Clients can choose not to enable resumption to avoid creating this correlation. Clients SHOULD NOT reuse tickets as that allows entities other than the server -to correlate connections; see Appendix C.4 of [TLS13].¶ +to correlate connections; see Appendix C.4 of [TLS13].¶ @@ -2007,7 +2007,7 @@ NewSessionTicket that contains an early_data extension with any other value as a connection error of type PROTOCOL_VIOLATION.¶ A client that wishes to send 0-RTT packets uses the early_data extension in the -ClientHello message of a subsequent handshake; see Section 4.2.10 of [TLS13]. +ClientHello message of a subsequent handshake; see Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT packets.¶ A client that attempts 0-RTT might also provide an address validation token if the server has sent a NEW_TOKEN frame; see Section 8.1 of [QUIC-TRANSPORT].¶ @@ -2019,7 +2019,7 @@ 4.6.2. Accepting and Rejecting 0-RTT A server accepts 0-RTT by sending an early_data extension in the -EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then +EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then processes and acknowledges the 0-RTT packets that it receives.¶ A server rejects 0-RTT by sending the EncryptedExtensions without an early_data extension. A server will always reject 0-RTT if it sends a TLS @@ -2043,7 +2043,7 @@ When a server receives a ClientHello with the early_data extension, it has to decide whether to accept or reject early data from the client. Some of this decision is made by the TLS stack (e.g., checking that the cipher suite being -resumed was included in the ClientHello; see Section 4.2.10 of [TLS13]). Even +resumed was included in the ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack has no reason to reject early data, the QUIC stack or the application protocol using QUIC might reject early data because the configuration of the transport or application associated with the resumed @@ -2065,7 +2065,7 @@ 4.7. HelloRetryRequest -The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be used to +The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be used to request that a client provide new information, such as a key share, or to validate some characteristic of the client. From the perspective of QUIC, HelloRetryRequest is not differentiated from other cryptographic handshake @@ -2080,7 +2080,7 @@ 4.8. TLS Errors If TLS experiences an error, it generates an appropriate alert as defined in -Section 6 of [TLS13].¶ +Section 6 of [TLS13].¶ A TLS alert is converted into a QUIC connection error. The AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for @@ -2088,7 +2088,7 @@ type 0x1c.¶ QUIC is only able to convey an alert level of "fatal". In TLS 1.3, the only existing uses for the "warning" level are to signal connection close; see -Section 6.1 of [TLS13]. As QUIC provides alternative mechanisms for +Section 6.1 of [TLS13]. As QUIC provides alternative mechanisms for connection termination and the TLS connection is only closed if an error is encountered, a QUIC endpoint MUST treat any alert from TLS as if it were at the "fatal" level.¶ @@ -2214,13 +2214,13 @@ QUIC derives packet protection keys in the same way that TLS derives record protection keys.¶ Each encryption level has separate secret values for protection of packets sent -in each direction. These traffic secrets are derived by TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all encryption levels except the Initial +in each direction. These traffic secrets are derived by TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all encryption levels except the Initial encryption level. The secrets for the Initial encryption level are computed based on the client's initial Destination Connection ID, as described in Section 5.2.¶ The keys used for packet protection are computed from the TLS secrets using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label function described in -Section 7.1 of [TLS13] is used, using the hash function from the negotiated +Section 7.1 of [TLS13] is used, using the hash function from the negotiated cipher suite. All uses of HKDF-Expand-Label in QUIC use a zero-length Context.¶ Note that labels, which are described using strings, are encoded as bytes using ASCII [ASCII] without quotes or any trailing NUL @@ -2249,7 +2249,7 @@ Initial packets apply the packet protection process, but use a secret derived from the Destination Connection ID field from the client's first Initial packet.¶ -This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) +This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and a IKM of the Destination Connection ID field. This produces an intermediate pseudorandom key (PRK) that is used to derive two separate secrets for sending and receiving.¶ @@ -2551,7 +2551,7 @@ 5.4.4. ChaCha20-Based Header Protection When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw ChaCha20 -function as defined in Section 2.4 of [CHACHA]. This uses a 256-bit key and +function as defined in Section 2.4 of [CHACHA]. This uses a 256-bit key and 16 bytes sampled from the packet protection output.¶ The first 4 bytes of the sampled ciphertext are the block counter. A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in @@ -2658,7 +2658,7 @@ handshake messages from a client, it is missing assurances on the client state:¶ The client is not authenticated, unless the server has chosen to use a -pre-shared key and validated the client's pre-shared key binder; see Section 4.2.11 of [TLS13].¶ +pre-shared key and validated the client's pre-shared key binder; see Section 4.2.11 of [TLS13].¶ The client has not demonstrated liveness, unless the server has validated the client's address with a Retry packet or other means; see @@ -2836,7 +2836,7 @@ Endpoints maintain separate read and write secrets for packet protection. An endpoint initiates a key update by updating its packet protection write secret and using that to protect new packets. The endpoint creates a new write secret -from the existing write secret as performed in Section 7.2 of [TLS13]. This +from the existing write secret as performed in Section 7.2 of [TLS13]. This uses the KDF function provided by TLS with a label of "quic ku". The corresponding key and IV are created from that secret as defined in Section 5.1. The header protection key is not updated.¶ @@ -3223,7 +3223,7 @@ 9.2. Replay Attacks with 0-RTT -As described in Section 8 of [TLS13], use of TLS early data comes with an +As described in Section 8 of [TLS13], use of TLS early data comes with an exposure to replay attack. The use of 0-RTT in QUIC is similarly vulnerable to replay attack.¶ Endpoints MUST implement and use the replay protections described in [TLS13], @@ -3429,11 +3429,11 @@ [QUIC-RECOVERY] -Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", Work in Progress, Internet-Draft, draft-ietf-quic-recovery, 8 February 2021, <https://tools.ietf.org/html/draft-ietf-quic-recovery>. +Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", Work in Progress, Internet-Draft, draft-ietf-quic-recovery, 17 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery.txt>. [QUIC-TRANSPORT] -Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport, 8 February 2021, <https://tools.ietf.org/html/draft-ietf-quic-transport>. +Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport, 17 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport.txt>. [RFC2119] @@ -3480,7 +3480,7 @@ [COMPRESS] -Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", Work in Progress, Internet-Draft, draft-ietf-tls-certificate-compression-10, 6 January 2020, <http://www.ietf.org/internet-drafts/draft-ietf-tls-certificate-compression-10.txt>. +Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", Work in Progress, Internet-Draft, draft-ietf-tls-certificate-compression-10, 6 January 2020, <https://www.ietf.org/archive/id/draft-ietf-tls-certificate-compression-10.txt>. [GCM-MU] @@ -3504,7 +3504,7 @@ [QUIC-HTTP] -Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-quic-http, 8 February 2021, <https://tools.ietf.org/html/draft-ietf-quic-http>. +Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-quic-http, 17 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-http.txt>. [RFC2818] diff --git a/draft-ietf-quic-tls.txt b/draft-ietf-quic-tls.txt index 828343993d..4388526360 100644 --- a/draft-ietf-quic-tls.txt +++ b/draft-ietf-quic-tls.txt @@ -5,8 +5,8 @@ QUIC M. Thomson, Ed. Internet-Draft Mozilla Intended status: Standards Track S. Turner, Ed. -Expires: 12 August 2021 sn3rd - 8 February 2021 +Expires: 21 August 2021 sn3rd + 17 February 2021 Using TLS to Secure QUIC @@ -42,7 +42,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 12 August 2021. + This Internet-Draft will expire on 21 August 2021. Copyright Notice @@ -2241,15 +2241,16 @@ Table of Contents [QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", Work in Progress, Internet-Draft, - draft-ietf-quic-recovery, 8 February 2021, - . + draft-ietf-quic-recovery, 17 February 2021, + . [QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, - Internet-Draft, draft-ietf-quic-transport, 8 February - 2021, - . + Internet-Draft, draft-ietf-quic-transport, 17 February + 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -2298,7 +2299,7 @@ Table of Contents [COMPRESS] Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", Work in Progress, Internet-Draft, draft- ietf-tls-certificate-compression-10, 6 January 2020, - . [GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, "The Multi- @@ -2330,8 +2331,9 @@ Table of Contents [QUIC-HTTP] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- - quic-http, 8 February 2021, - . + quic-http, 17 February 2021, + . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, diff --git a/draft-ietf-quic-transport.html b/draft-ietf-quic-transport.html index 5292c7b1b0..c2041bf07a 100644 --- a/draft-ietf-quic-transport.html +++ b/draft-ietf-quic-transport.html @@ -20,21 +20,21 @@ @@ -847,7 +847,7 @@ Iyengar & Thomson -Expires 12 August 2021 +Expires 21 August 2021 [Page] @@ -860,12 +860,12 @@ draft-ietf-quic-transport Published: -8 February 2021 +17 February 2021 Intended Status: Standards Track Expires: -12 August 2021 +21 August 2021 Authors: @@ -929,7 +929,7 @@ time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶ - This Internet-Draft will expire on 12 August 2021.¶ + This Internet-Draft will expire on 21 August 2021.¶ @@ -957,803 +957,803 @@ ▲ Table of Contents - - + + 1. Overview¶ - - + + 1.1. Document Structure¶ - + 1.2. Terms and Definitions¶ - + 1.3. Notational Conventions¶ - + 2. Streams¶ - - + + 2.1. Stream Types and Identifiers¶ - + 2.2. Sending and Receiving Data¶ - + 2.3. Stream Prioritization¶ - + 2.4. Operations on Streams¶ - + 3. Stream States¶ - - + + 3.1. Sending Stream States¶ - + 3.2. Receiving Stream States¶ - + 3.3. Permitted Frame Types¶ - + 3.4. Bidirectional Stream States¶ - + 3.5. Solicited State Transitions¶ - + 4. Flow Control¶ - - + + 4.1. Data Flow Control¶ - + 4.2. Increasing Flow Control Limits¶ - + 4.3. Flow Control Performance¶ - + 4.4. Handling Stream Cancellation¶ - + 4.5. Stream Final Size¶ - + 4.6. Controlling Concurrency¶ - + 5. Connections¶ - - - 5.1. Connection ID¶ - + + 5.1. Connection ID¶ + + 5.1.1. Issuing Connection IDs¶ - + 5.1.2. Consuming and Retiring Connection IDs¶ - + 5.2. Matching Packets to Connections¶ - - + + 5.2.1. Client Packet Handling¶ - + 5.2.2. Server Packet Handling¶ - + 5.2.3. Considerations for Simple Load Balancers¶ - + 5.3. Operations on Connections¶ - + 6. Version Negotiation¶ - - + + 6.1. Sending Version Negotiation Packets¶ - + 6.2. Handling Version Negotiation Packets¶ - - + + 6.2.1. Version Negotiation Between Draft Versions¶ - + 6.3. Using Reserved Versions¶ - + 7. Cryptographic and Transport Handshake¶ - - + + 7.1. Example Handshake Flows¶ - + 7.2. Negotiating Connection IDs¶ - + 7.3. Authenticating Connection IDs¶ - + 7.4. Transport Parameters¶ - - + + 7.4.1. Values of Transport Parameters for 0-RTT¶ - + 7.4.2. New Transport Parameters¶ - + 7.5. Cryptographic Message Buffering¶ - + 8. Address Validation¶ - - - 8.1. Address Validation During Connection Establishment¶ - + + 8.1. Address Validation During Connection Establishment¶ + + 8.1.1. Token Construction¶ - + 8.1.2. Address Validation using Retry Packets¶ - + 8.1.3. Address Validation for Future Connections¶ - + 8.1.4. Address Validation Token Integrity¶ - + 8.2. Path Validation¶ - - + + 8.2.1. Initiating Path Validation¶ - + 8.2.2. Path Validation Responses¶ - + 8.2.3. Successful Path Validation¶ - + 8.2.4. Failed Path Validation¶ - + 9. Connection Migration¶ - - + + 9.1. Probing a New Path¶ - + 9.2. Initiating Connection Migration¶ - + 9.3. Responding to Connection Migration¶ - - + + 9.3.1. Peer Address Spoofing¶ - + 9.3.2. On-Path Address Spoofing¶ - + 9.3.3. Off-Path Packet Forwarding¶ - + 9.4. Loss Detection and Congestion Control¶ - + 9.5. Privacy Implications of Connection Migration¶ - + 9.6. Server's Preferred Address¶ - - + + 9.6.1. Communicating a Preferred Address¶ - + 9.6.2. Migration to a Preferred Address¶ - + 9.6.3. Interaction of Client Migration and Preferred Address¶ - + 9.7. Use of IPv6 Flow-Label and Migration¶ - + 10. Connection Termination¶ - - - 10.1. Idle Timeout¶ - + + 10.1. Idle Timeout¶ + + 10.1.1. Liveness Testing¶ - + 10.1.2. Deferring Idle Timeout¶ - + 10.2. Immediate Close¶ - - + + 10.2.1. Closing Connection State¶ - + 10.2.2. Draining Connection State¶ - + 10.2.3. Immediate Close During the Handshake¶ - + 10.3. Stateless Reset¶ - - + + 10.3.1. Detecting a Stateless Reset¶ - + 10.3.2. Calculating a Stateless Reset Token¶ - + 10.3.3. Looping¶ - + 11. Error Handling¶ - - + + 11.1. Connection Errors¶ - + 11.2. Stream Errors¶ - + 12. Packets and Frames¶ - - + + 12.1. Protected Packets¶ - + 12.2. Coalescing Packets¶ - + 12.3. Packet Numbers¶ - + 12.4. Frames and Frame Types¶ - + 12.5. Frames and Number Spaces¶ - + 13. Packetization and Reliability¶ - - + + 13.1. Packet Processing¶ - + 13.2. Generating Acknowledgments¶ - - + + 13.2.1. Sending ACK Frames¶ - + 13.2.2. Acknowledgment Frequency¶ - + 13.2.3. Managing ACK Ranges¶ - + 13.2.4. Limiting Ranges by Tracking ACK Frames¶ - + 13.2.5. Measuring and Reporting Host Delay¶ - + 13.2.6. ACK Frames and Packet Protection¶ - + 13.2.7. PADDING Frames Consume Congestion Window¶ - + 13.3. Retransmission of Information¶ - + 13.4. Explicit Congestion Notification¶ - - + + 13.4.1. Reporting ECN Counts¶ - + 13.4.2. ECN Validation¶ - + 14. Datagram Size¶ - - + + 14.1. Initial Datagram Size¶ - + 14.2. Path Maximum Transmission Unit¶ - - + + 14.2.1. Handling of ICMP Messages by PMTUD¶ - + 14.3. Datagram Packetization Layer PMTU Discovery¶ - - + + 14.3.1. DPLPMTUD and Initial Connectivity¶ - + 14.3.2. Validating the Network Path with DPLPMTUD¶ - + 14.3.3. Handling of ICMP Messages by DPLPMTUD¶ - + 14.4. Sending QUIC PMTU Probes¶ - - + + 14.4.1. PMTU Probes Containing Source Connection ID¶ - + 15. Versions¶ - + 16. Variable-Length Integer Encoding¶ - + 17. Packet Formats¶ - - + + 17.1. Packet Number Encoding and Decoding¶ - + 17.2. Long Header Packets¶ - - + + 17.2.1. Version Negotiation Packet¶ - + 17.2.2. Initial Packet¶ - + 17.2.3. 0-RTT¶ - + 17.2.4. Handshake Packet¶ - + 17.2.5. Retry Packet¶ - + 17.3. Short Header Packets¶ - - + + 17.3.1. 1-RTT Packet¶ - + 17.4. Latency Spin Bit¶ - + 18. Transport Parameter Encoding¶ - - + + 18.1. Reserved Transport Parameters¶ - + 18.2. Transport Parameter Definitions¶ - + 19. Frame Types and Formats¶ - - + + 19.1. PADDING Frames¶ - + 19.2. PING Frames¶ - + 19.3. ACK Frames¶ - - + +
2. Notational Conventions¶
2.1. TLS Overview¶
3. Protocol Overview¶
4. Carrying TLS Messages¶
4.1. Interface to TLS¶
4.1.1. Handshake Complete¶
4.1.2. Handshake Confirmed¶
4.1.3. Sending and Receiving Handshake Messages¶
4.1.4. Encryption Level Changes¶
4.1.5. TLS Interface Summary¶
4.2. TLS Version¶
4.3. ClientHello Size¶
4.4. Peer Authentication¶
4.5. Session Resumption¶
4.6. 0-RTT¶
4.6.1. Enabling 0-RTT¶
4.6.2. Accepting and Rejecting 0-RTT¶
4.6.3. Validating 0-RTT Configuration¶
4.7. HelloRetryRequest¶
4.8. TLS Errors¶
4.9. Discarding Unused Keys¶
4.9.1. Discarding Initial Keys¶
4.9.2. Discarding Handshake Keys¶
4.9.3. Discarding 0-RTT Keys¶
5. Packet Protection¶
5.1. Packet Protection Keys¶
5.2. Initial Secrets¶
5.3. AEAD Usage¶
5.4. Header Protection¶
5.4.1. Header Protection Application¶
5.4.2. Header Protection Sample¶
5.4.3. AES-Based Header Protection¶
5.4.4. ChaCha20-Based Header Protection¶
5.5. Receiving Protected Packets¶
5.6. Use of 0-RTT Keys¶
5.7. Receiving Out-of-Order Protected Packets¶
5.8. Retry Packet Integrity¶
6. Key Update¶
6.1. Initiating a Key Update¶
6.2. Responding to a Key Update¶
6.3. Timing of Receive Key Generation¶
6.4. Sending with Updated Keys¶
6.5. Receiving with Different Keys¶
6.6. Limits on AEAD Usage¶
6.7. Key Update Error Code¶
7. Security of Initial Messages¶
8. QUIC-Specific Adjustments to the TLS Handshake¶
8.1. Protocol Negotiation¶
8.2. QUIC Transport Parameters Extension¶
8.3. Removing the EndOfEarlyData Message¶
8.4. Prohibit TLS Middlebox Compatibility Mode¶
9. Security Considerations¶
9.1. Session Linkability¶
9.2. Replay Attacks with 0-RTT¶
9.3. Packet Reflection Attack Mitigation¶
9.4. Header Protection Analysis¶
9.5. Header Protection Timing Side-Channels¶
9.6. Key Diversity¶
9.7. Randomness¶
10. IANA Considerations¶
11. References¶
11.1. Normative References¶
11.2. Informative References¶
Appendix A. Sample Packet Protection¶
A.1. Keys¶
A.2. Client Initial¶
A.3. Server Initial¶
A.4. Retry¶
A.5. ChaCha20-Poly1305 Short Header Packet¶
Appendix B. AEAD Algorithm Analysis¶
B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits¶
B.1.1. Confidentiality Limit¶
B.1.2. Integrity Limit¶
B.2. Analysis of AEAD_AES_128_CCM Usage Limits¶
C.1. Since draft-ietf-quic-tls-32¶
C.2. Since draft-ietf-quic-tls-31¶
C.3. Since draft-ietf-quic-tls-30¶
C.4. Since draft-ietf-quic-tls-29¶
C.5. Since draft-ietf-quic-tls-28¶
C.6. Since draft-ietf-quic-tls-27¶
C.7. Since draft-ietf-quic-tls-26¶
C.8. Since draft-ietf-quic-tls-25¶
C.9. Since draft-ietf-quic-tls-24¶
C.10. Since draft-ietf-quic-tls-23¶
C.11. Since draft-ietf-quic-tls-22¶
C.12. Since draft-ietf-quic-tls-21¶
C.13. Since draft-ietf-quic-tls-20¶
C.14. Since draft-ietf-quic-tls-18¶
C.15. Since draft-ietf-quic-tls-17¶
C.16. Since draft-ietf-quic-tls-14¶
C.17. Since draft-ietf-quic-tls-13¶
C.18. Since draft-ietf-quic-tls-12¶
C.19. Since draft-ietf-quic-tls-11¶
C.20. Since draft-ietf-quic-tls-10¶
C.21. Since draft-ietf-quic-tls-09¶
C.22. Since draft-ietf-quic-tls-08¶
C.23. Since draft-ietf-quic-tls-07¶
C.24. Since draft-ietf-quic-tls-05¶
C.25. Since draft-ietf-quic-tls-04¶
C.26. Since draft-ietf-quic-tls-03¶
C.27. Since draft-ietf-quic-tls-02¶
C.28. Since draft-ietf-quic-tls-01¶
C.29. Since draft-ietf-quic-tls-00¶
C.30. Since draft-thomson-quic-tls-01¶
Contributors¶
A server MUST NOT use post-handshake client authentication (as defined in -Section 4.6.2 of [TLS13]), because the multiplexing offered by QUIC prevents +Section 4.6.2 of [TLS13]), because the multiplexing offered by QUIC prevents clients from correlating the certificate request with the application-level event that triggered it (see [HTTP2-TLS13]). More specifically, servers MUST NOT send post-handshake TLS CertificateRequest @@ -1952,7 +1952,7 @@
Endpoints that use session resumption might need to remember some information about the current connection when creating a resumed connection. TLS requires -that some information be retained; see Section 4.6.1 of [TLS13]. QUIC itself +that some information be retained; see Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state being retained when resuming a connection, unless 0-RTT is also used; see Section 7.4.1 of [QUIC-TRANSPORT] and Section 4.6.1. Application protocols could depend on state that is retained @@ -1963,7 +1963,7 @@
A client that wishes to send 0-RTT packets uses the early_data extension in the -ClientHello message of a subsequent handshake; see Section 4.2.10 of [TLS13]. +ClientHello message of a subsequent handshake; see Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT packets.¶
A client that attempts 0-RTT might also provide an address validation token if the server has sent a NEW_TOKEN frame; see Section 8.1 of [QUIC-TRANSPORT].¶
A server accepts 0-RTT by sending an early_data extension in the -EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then +EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then processes and acknowledges the 0-RTT packets that it receives.¶
A server rejects 0-RTT by sending the EncryptedExtensions without an early_data extension. A server will always reject 0-RTT if it sends a TLS @@ -2043,7 +2043,7 @@
When a server receives a ClientHello with the early_data extension, it has to decide whether to accept or reject early data from the client. Some of this decision is made by the TLS stack (e.g., checking that the cipher suite being -resumed was included in the ClientHello; see Section 4.2.10 of [TLS13]). Even +resumed was included in the ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack has no reason to reject early data, the QUIC stack or the application protocol using QUIC might reject early data because the configuration of the transport or application associated with the resumed @@ -2065,7 +2065,7 @@
The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be used to +
The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be used to request that a client provide new information, such as a key share, or to validate some characteristic of the client. From the perspective of QUIC, HelloRetryRequest is not differentiated from other cryptographic handshake @@ -2080,7 +2080,7 @@
If TLS experiences an error, it generates an appropriate alert as defined in -Section 6 of [TLS13].¶
A TLS alert is converted into a QUIC connection error. The AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for @@ -2088,7 +2088,7 @@
QUIC is only able to convey an alert level of "fatal". In TLS 1.3, the only existing uses for the "warning" level are to signal connection close; see -Section 6.1 of [TLS13]. As QUIC provides alternative mechanisms for +Section 6.1 of [TLS13]. As QUIC provides alternative mechanisms for connection termination and the TLS connection is only closed if an error is encountered, a QUIC endpoint MUST treat any alert from TLS as if it were at the "fatal" level.¶
QUIC derives packet protection keys in the same way that TLS derives record protection keys.¶
Each encryption level has separate secret values for protection of packets sent -in each direction. These traffic secrets are derived by TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all encryption levels except the Initial +in each direction. These traffic secrets are derived by TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all encryption levels except the Initial encryption level. The secrets for the Initial encryption level are computed based on the client's initial Destination Connection ID, as described in Section 5.2.¶
The keys used for packet protection are computed from the TLS secrets using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label function described in -Section 7.1 of [TLS13] is used, using the hash function from the negotiated +Section 7.1 of [TLS13] is used, using the hash function from the negotiated cipher suite. All uses of HKDF-Expand-Label in QUIC use a zero-length Context.¶
Note that labels, which are described using strings, are encoded as bytes using ASCII [ASCII] without quotes or any trailing NUL @@ -2249,7 +2249,7 @@
Initial packets apply the packet protection process, but use a secret derived from the Destination Connection ID field from the client's first Initial packet.¶
This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) +
This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and a IKM of the Destination Connection ID field. This produces an intermediate pseudorandom key (PRK) that is used to derive two separate secrets for sending and receiving.¶
When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw ChaCha20 -function as defined in Section 2.4 of [CHACHA]. This uses a 256-bit key and +function as defined in Section 2.4 of [CHACHA]. This uses a 256-bit key and 16 bytes sampled from the packet protection output.¶
The first 4 bytes of the sampled ciphertext are the block counter. A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in @@ -2658,7 +2658,7 @@
Endpoints maintain separate read and write secrets for packet protection. An endpoint initiates a key update by updating its packet protection write secret and using that to protect new packets. The endpoint creates a new write secret -from the existing write secret as performed in Section 7.2 of [TLS13]. This +from the existing write secret as performed in Section 7.2 of [TLS13]. This uses the KDF function provided by TLS with a label of "quic ku". The corresponding key and IV are created from that secret as defined in Section 5.1. The header protection key is not updated.¶
As described in Section 8 of [TLS13], use of TLS early data comes with an +
As described in Section 8 of [TLS13], use of TLS early data comes with an exposure to replay attack. The use of 0-RTT in QUIC is similarly vulnerable to replay attack.¶
Endpoints MUST implement and use the replay protections described in [TLS13], @@ -3429,11 +3429,11 @@
1. Overview¶
1.1. Document Structure¶
1.2. Terms and Definitions¶
1.3. Notational Conventions¶
2. Streams¶
2.1. Stream Types and Identifiers¶
2.2. Sending and Receiving Data¶
2.3. Stream Prioritization¶
2.4. Operations on Streams¶
3. Stream States¶
3.1. Sending Stream States¶
3.2. Receiving Stream States¶
3.3. Permitted Frame Types¶
3.4. Bidirectional Stream States¶
3.5. Solicited State Transitions¶
4. Flow Control¶
4.1. Data Flow Control¶
4.2. Increasing Flow Control Limits¶
4.3. Flow Control Performance¶
4.4. Handling Stream Cancellation¶
4.5. Stream Final Size¶
4.6. Controlling Concurrency¶
5. Connections¶
5.1. Connection ID¶
5.1.1. Issuing Connection IDs¶
5.1.2. Consuming and Retiring Connection IDs¶
5.2. Matching Packets to Connections¶
5.2.1. Client Packet Handling¶
5.2.2. Server Packet Handling¶
5.2.3. Considerations for Simple Load Balancers¶
5.3. Operations on Connections¶
6.1. Sending Version Negotiation Packets¶
6.2. Handling Version Negotiation Packets¶
6.2.1. Version Negotiation Between Draft Versions¶
6.3. Using Reserved Versions¶
7. Cryptographic and Transport Handshake¶
7.1. Example Handshake Flows¶
7.2. Negotiating Connection IDs¶
7.3. Authenticating Connection IDs¶
7.4. Transport Parameters¶
7.4.1. Values of Transport Parameters for 0-RTT¶
7.4.2. New Transport Parameters¶
7.5. Cryptographic Message Buffering¶
8. Address Validation¶
8.1. Address Validation During Connection Establishment¶
8.1.1. Token Construction¶
8.1.2. Address Validation using Retry Packets¶
8.1.3. Address Validation for Future Connections¶
8.1.4. Address Validation Token Integrity¶
8.2. Path Validation¶
8.2.1. Initiating Path Validation¶
8.2.2. Path Validation Responses¶
8.2.3. Successful Path Validation¶
8.2.4. Failed Path Validation¶
9. Connection Migration¶
9.1. Probing a New Path¶
9.2. Initiating Connection Migration¶
9.3. Responding to Connection Migration¶
9.3.1. Peer Address Spoofing¶
9.3.2. On-Path Address Spoofing¶
9.3.3. Off-Path Packet Forwarding¶
9.4. Loss Detection and Congestion Control¶
9.5. Privacy Implications of Connection Migration¶
9.6. Server's Preferred Address¶
9.6.1. Communicating a Preferred Address¶
9.6.2. Migration to a Preferred Address¶
9.6.3. Interaction of Client Migration and Preferred Address¶
9.7. Use of IPv6 Flow-Label and Migration¶
10. Connection Termination¶
10.1. Idle Timeout¶
10.1.1. Liveness Testing¶
10.1.2. Deferring Idle Timeout¶
10.2. Immediate Close¶
10.2.1. Closing Connection State¶
10.2.2. Draining Connection State¶
10.2.3. Immediate Close During the Handshake¶
10.3. Stateless Reset¶
10.3.1. Detecting a Stateless Reset¶
10.3.2. Calculating a Stateless Reset Token¶
10.3.3. Looping¶
11. Error Handling¶
11.1. Connection Errors¶
11.2. Stream Errors¶
12. Packets and Frames¶
12.1. Protected Packets¶
12.2. Coalescing Packets¶
12.3. Packet Numbers¶
12.4. Frames and Frame Types¶
12.5. Frames and Number Spaces¶
13. Packetization and Reliability¶
13.1. Packet Processing¶
13.2. Generating Acknowledgments¶
13.2.1. Sending ACK Frames¶
13.2.2. Acknowledgment Frequency¶
13.2.3. Managing ACK Ranges¶
13.2.4. Limiting Ranges by Tracking ACK Frames¶
13.2.5. Measuring and Reporting Host Delay¶
13.2.6. ACK Frames and Packet Protection¶
13.2.7. PADDING Frames Consume Congestion Window¶
13.3. Retransmission of Information¶
13.4. Explicit Congestion Notification¶
13.4.1. Reporting ECN Counts¶
13.4.2. ECN Validation¶
14. Datagram Size¶
14.1. Initial Datagram Size¶
14.2. Path Maximum Transmission Unit¶
14.2.1. Handling of ICMP Messages by PMTUD¶
14.3. Datagram Packetization Layer PMTU Discovery¶
14.3.1. DPLPMTUD and Initial Connectivity¶
14.3.2. Validating the Network Path with DPLPMTUD¶
14.3.3. Handling of ICMP Messages by DPLPMTUD¶
14.4. Sending QUIC PMTU Probes¶
14.4.1. PMTU Probes Containing Source Connection ID¶
15. Versions¶
16. Variable-Length Integer Encoding¶
17. Packet Formats¶
17.1. Packet Number Encoding and Decoding¶
17.2. Long Header Packets¶
17.2.1. Version Negotiation Packet¶
17.2.2. Initial Packet¶
17.2.3. 0-RTT¶
17.2.4. Handshake Packet¶
17.2.5. Retry Packet¶
17.3. Short Header Packets¶
17.3.1. 1-RTT Packet¶
17.4. Latency Spin Bit¶
18. Transport Parameter Encoding¶
18.1. Reserved Transport Parameters¶
18.2. Transport Parameter Definitions¶
19. Frame Types and Formats¶
19.1. PADDING Frames¶
19.2. PING Frames¶
19.3. ACK Frames¶