draft-ietf-quic-tls-24.txt   draft-ietf-quic-tls-latest.txt 
QUIC Working Group M. Thomson, Ed. QUIC Working Group M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed. Intended status: Standards Track S. Turner, Ed.
Expires: May 7, 2020 sn3rd Expires: July 20, 2020 sn3rd
November 4, 2019 January 17, 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-24 draft-ietf-quic-tls-latest
Abstract Abstract
This document describes how Transport Layer Security (TLS) is used to This document describes how Transport Layer Security (TLS) is used to
secure QUIC. secure QUIC.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 May 7, 2020. This Internet-Draft will expire on July 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15 4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15
4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16
4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16 4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16
4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17 4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17
4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17 4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17
4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18 4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18
4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18 4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18
4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 18 4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 18
4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19 4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19
4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19 4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 20 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 23 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 22
5.4.1. Header Protection Application . . . . . . . . . . . . 23 5.4.1. Header Protection Application . . . . . . . . . . . . 23
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 29
6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 29
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 30 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Timing of Receive Key Generation . . . . . . . . . . . . 31 6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 31
6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 32 6.2. Responding to a Key Update . . . . . . . . . . . . . . . 32
6.5. Receiving with Different Keys . . . . . . . . . . . . . . 32 6.3. Timing of Receive Key Generation . . . . . . . . . . . . 33
6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 33 6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 33
6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 33 6.5. Receiving with Different Keys . . . . . . . . . . . . . . 34
7. Security of Initial Messages . . . . . . . . . . . . . . . . 33 6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 35
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 34 6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 35
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 34 7. Security of Initial Messages . . . . . . . . . . . . . . . . 35
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 34 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 35
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 35 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 36
9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 36 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 37
9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9.3. Header Protection Analysis . . . . . . . . . . . . . . . 37 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 37
9.4. Header Protection Timing Side-Channels . . . . . . . . . 38 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 38
9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 39 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9.4. Header Protection Timing Side-Channels . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.2. Informative References . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1. Normative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Sample Initial Packet Protection . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . 42
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 43
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 44 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 45 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 44
B.1. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 45 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 46
B.2. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 45 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47
B.3. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 46 B.1. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 47
B.4. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 46 B.2. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 47
B.5. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 46 B.3. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 48
B.6. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 46 B.4. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 48
B.7. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 46 B.5. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 48
B.8. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 47 B.6. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 48
B.9. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 47 B.7. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 48
B.10. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 47 B.8. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 49
B.11. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 47 B.9. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 49
B.12. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 47 B.10. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 49
B.13. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 47 B.11. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 49
B.14. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 47 B.12. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 49
B.15. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 48 B.13. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 49
B.16. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 48 B.14. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 49
B.17. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 48 B.15. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 50
B.18. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 48 B.16. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 50
B.19. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 48 B.17. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 50
B.20. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 48 B.18. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 50
B.21. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 49 B.19. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 50
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.20. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.21. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using This document describes how QUIC [QUIC-TRANSPORT] is secured using
TLS [TLS13]. TLS [TLS13].
TLS 1.3 provides critical latency improvements for connection TLS 1.3 provides critical latency improvements for connection
establishment over previous versions. Absent packet loss, most new establishment over previous versions. Absent packet loss, most new
connections can be established and secured within a single round connections can be established and secured within a single round
trip; on subsequent connections between the same client and server, trip; on subsequent connections between the same client and server,
skipping to change at page 9, line 8 skipping to change at page 9, line 8
Some frames are prohibited in different encryption levels, others Some frames are prohibited in different encryption levels, others
cannot be sent. The rules here generalize those of TLS, in that cannot be sent. The rules here generalize those of TLS, in that
frames associated with establishing the connection can usually appear frames associated with establishing the connection can usually appear
at any encryption level, whereas those associated with transferring at any encryption level, whereas those associated with transferring
data can only appear in the 0-RTT and 1-RTT encryption levels: data can only appear in the 0-RTT and 1-RTT encryption levels:
o PADDING and PING frames MAY appear in packets of any encryption o PADDING and PING frames MAY appear in packets of any encryption
level. level.
o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any o CRYPTO frames and CONNECTION_CLOSE frames signaling errors at the
encryption level except 0-RTT. QUIC layer (type 0x1c) MAY appear in packets of any encryption
level except 0-RTT.
o CONNECTION_CLOSE frames signaling application errors (type 0x1d)
MUST only be sent in packets at the 1-RTT encryption level.
o ACK frames MAY appear in packets of any encryption level other o ACK frames MAY appear in packets of any encryption level other
than 0-RTT, but can only acknowledge packets which appeared in than 0-RTT, but can only acknowledge packets which appeared in
that packet number space. that packet number space.
o All other frame types MUST only be sent in the 0-RTT and 1-RTT o All other frame types MUST only be sent in the 0-RTT and 1-RTT
levels. levels.
Note that it is not possible to send the following frames in 0-RTT Note that it is not possible to send the following frames in 0-RTT
for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
skipping to change at page 10, line 35 skipping to change at page 10, line 35
when the TLS stack has both sent a Finished message and verified the when the TLS stack has both sent a Finished message and verified the
peer's Finished message. Verifying the peer's Finished provides the peer's Finished message. Verifying the peer's Finished provides the
endpoints with an assurance that previous handshake messages have not endpoints with an assurance that previous handshake messages have not
been modified. Note that the handshake does not complete at both been modified. Note that the handshake does not complete at both
endpoints simultaneously. Consequently, any requirement that is endpoints simultaneously. Consequently, any requirement that is
based on the completion of the handshake depends on the perspective based on the completion of the handshake depends on the perspective
of the endpoint in question. of the endpoint in question.
4.1.2. Handshake Confirmed 4.1.2. Handshake Confirmed
In this document, the TLS handshake is considered confirmed at an In this document, the TLS handshake is considered confirmed at the
endpoint when the following two conditions are met: the handshake is server when the handshake completes. At the client, the handshake is
complete, and the endpoint has received an acknowledgment for a considered confirmed when a HANDSHAKE_DONE frame is received.
packet sent with 1-RTT keys. This second condition can be
implemented by recording the lowest packet number sent with 1-RTT A client MAY consider the handshake to be confirmed when it receives
keys, and the highest value of the Largest Acknowledged field in any an acknowledgement for a 1-RTT packet. This can be implemented by
received 1-RTT ACK frame: once the latter is higher than or equal to recording the lowest packet number sent with 1-RTT keys, and
the former, the handshake is confirmed. comparing it to the Largest Acknowledged field in any received 1-RTT
ACK frame: once the latter is greater than or equal to the former,
the handshake is confirmed.
4.1.3. Sending and Receiving Handshake Messages 4.1.3. Sending and Receiving Handshake Messages
In order to drive the handshake, TLS depends on being able to send In order to drive the handshake, TLS depends on being able to send
and receive handshake messages. There are two basic functions on and receive handshake messages. There are two basic functions on
this interface: one where QUIC requests handshake messages and one this interface: one where QUIC requests handshake messages and one
where QUIC provides handshake packets. where QUIC provides handshake packets.
Before starting the handshake QUIC provides TLS with the transport Before starting the handshake QUIC provides TLS with the transport
parameters (see Section 8.2) that it wishes to carry. parameters (see Section 8.2) that it wishes to carry.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
Thus, a client MUST discard Initial keys when it first sends a Thus, a client MUST discard Initial keys when it first sends a
Handshake packet and a server MUST discard Initial keys when it first Handshake packet and a server MUST discard Initial keys when it first
successfully processes a Handshake packet. Endpoints MUST NOT send successfully processes a Handshake packet. Endpoints MUST NOT send
Initial packets after this point. Initial packets after this point.
This results in abandoning loss recovery state for the Initial This results in abandoning loss recovery state for the Initial
encryption level and ignoring any outstanding Initial packets. encryption level and ignoring any outstanding Initial packets.
4.10.2. Discarding Handshake Keys 4.10.2. Discarding Handshake Keys
An endpoint MUST NOT discard its handshake keys until the TLS An endpoint MUST discard its handshake keys when the TLS handshake is
handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard confirmed (Section 4.1.2). The server MUST send a HANDSHAKE_DONE
its handshake keys as soon as it has confirmed the handshake. Most frame as soon as it completes the handshake.
application protocols will send data after the handshake, resulting
in acknowledgements that allow both endpoints to discard their
handshake keys promptly. Endpoints that do not have reason to send
immediately after completing the handshake MAY send ack-eliciting
frames, such as PING, which will cause the handshake to be confirmed
when they are acknowledged.
4.10.3. Discarding 0-RTT Keys 4.10.3. Discarding 0-RTT Keys
0-RTT and 1-RTT packets share the same packet number space, and 0-RTT and 1-RTT packets share the same packet number space, and
clients do not send 0-RTT packets after sending a 1-RTT packet clients do not send 0-RTT packets after sending a 1-RTT packet
(Section 5.6). (Section 5.6).
Therefore, a client SHOULD discard 0-RTT keys as soon as it installs Therefore, a client SHOULD discard 0-RTT keys as soon as it installs
1-RTT keys, since they have no use after that moment. 1-RTT keys, since they have no use after that moment.
skipping to change at page 28, line 11 skipping to change at page 28, line 11
handshake is complete. The 1-RTT keys necessary to remove packet handshake is complete. The 1-RTT keys necessary to remove packet
protection cannot be derived until the client receives all server protection cannot be derived until the client receives all server
handshake messages. handshake messages.
5.7. Receiving Out-of-Order Protected Frames 5.7. Receiving Out-of-Order Protected Frames
Due to reordering and loss, protected packets might be received by an Due to reordering and loss, protected packets might be received by an
endpoint before the final TLS handshake messages are received. A endpoint before the final TLS handshake messages are received. A
client will be unable to decrypt 1-RTT packets from the server, client will be unable to decrypt 1-RTT packets from the server,
whereas a server will be able to decrypt 1-RTT packets from the whereas a server will be able to decrypt 1-RTT packets from the
client. client. Endpoints in either role MUST NOT decrypt 1-RTT packets from
their peer prior to completing the handshake.
Even though 1-RTT keys are available to a server after receiving the Even though 1-RTT keys are available to a server after receiving the
first handshake messages from a client, it is missing assurances on first handshake messages from a client, it is missing assurances on
the client state: the client state:
o The client is not authenticated, unless the server has chosen to o The client is not authenticated, unless the server has chosen to
use a pre-shared key and validated the client's pre-shared key use a pre-shared key and validated the client's pre-shared key
binder; see Section 4.2.11 of [TLS13]. binder; see Section 4.2.11 of [TLS13].
o The client has not demonstrated liveness, unless a RETRY packet o The client has not demonstrated liveness, unless a RETRY packet
was used. was used.
o Any received 0-RTT data that the server responds to might be due o Any received 0-RTT data that the server responds to might be due
to a replay attack. to a replay attack.
Therefore, the server's use of 1-RTT keys is limited before the Therefore, the server's use of 1-RTT keys MUST be limited to sending
handshake is complete. A server MUST NOT process data from incoming data before the handshake is complete. A server MUST NOT process
1-RTT protected packets before the TLS handshake is complete. incoming 1-RTT protected packets before the TLS handshake is
Because sending acknowledgments indicates that all frames in a packet complete. Because sending acknowledgments indicates that all frames
have been processed, a server cannot send acknowledgments for 1-RTT in a packet have been processed, a server cannot send acknowledgments
packets until the TLS handshake is complete. Received packets for 1-RTT packets until the TLS handshake is complete. Received
protected with 1-RTT keys MAY be stored and later decrypted and used packets protected with 1-RTT keys MAY be stored and later decrypted
once the handshake is complete. and used once the handshake is complete.
Note: TLS implementations might provide all 1-RTT secrets prior to
handshake completion. Even where QUIC implementations have 1-RTT
read keys, those keys cannot be used prior to completing the
handshake.
The requirement for the server to wait for the client Finished The requirement for the server to wait for the client Finished
message creates a dependency on that message being delivered. A message creates a dependency on that message being delivered. A
client can avoid the potential for head-of-line blocking that this client can avoid the potential for head-of-line blocking that this
implies by sending its 1-RTT packets coalesced with a handshake implies by sending its 1-RTT packets coalesced with a handshake
packet containing a copy of the CRYPTO frame that carries the packet containing a copy of the CRYPTO frame that carries the
Finished message, until one of the handshake packets is acknowledged. Finished message, until one of the handshake packets is acknowledged.
This enables immediate server processing for those packets. This enables immediate server processing for those packets.
A server could receive packets protected with 0-RTT keys prior to A server could receive packets protected with 0-RTT keys prior to
receiving a TLS ClientHello. The server MAY retain these packets for receiving a TLS ClientHello. The server MAY retain these packets for
later decryption in anticipation of receiving a ClientHello. later decryption in anticipation of receiving a ClientHello.
5.8. Retry Packet Integrity
Retry packets (see the Retry Packet section of [QUIC-TRANSPORT])
carry a Retry Integrity Tag that provides two properties: it allows
discarding packets that have accidentally been corrupted by the
network, and it diminishes off-path attackers' ability to send valid
Retry packets.
The Retry Integrity Tag is a 128-bit field that is computed as the
output of AEAD_AES_128_GCM [AEAD] used with the following inputs:
o The secret key, K, is 128 bits equal to
0xf5ed4642e0e4c8d878bbbc8a828821c9.
o The nonce, N, is 96 bits all set to zero.
o The plaintext, P, is empty.
o The associated data, A, is the contents of the Retry Pseudo-
Packet, as illustrated in Figure 8:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| 3 | Unused|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Retry Pseudo-Packet
The Retry Pseudo-Packet is not sent over the wire. It is computed by
taking the transmitted Retry packet, removing the Retry Integrity Tag
and prepending the two following fields:
ODCID Len: The ODCID Len contains the length in bytes of the
Original Destination Connection ID field that follows it, encoded
as an 8-bit unsigned integer.
Original Destination Connection ID: The Original Destination
Connection ID contains the value of the Destination Connection ID
from the Initial packet that this Retry is in response to. The
length of this field is given in ODCID Len. The presence of this
field mitigates an off-path attacker's ability to inject a Retry
packet.
6. Key Update 6. Key Update
Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY
initiate a key update. initiate a key update.
The Key Phase bit indicates which packet protection keys are used to The Key Phase bit indicates which packet protection keys are used to
protect the packet. The Key Phase bit is initially set to 0 for the protect the packet. The Key Phase bit is initially set to 0 for the
first set of 1-RTT packets and toggled to signal each subsequent key first set of 1-RTT packets and toggled to signal each subsequent key
update. update.
skipping to change at page 29, line 21 skipping to change at page 30, line 37
material without needing to receive the first packet that triggered material without needing to receive the first packet that triggered
the change. An endpoint that notices a changed Key Phase bit updates the change. An endpoint that notices a changed Key Phase bit updates
keys and decrypts the packet that contains the changed value. keys and decrypts the packet that contains the changed value.
This mechanism replaces the TLS KeyUpdate message. Endpoints MUST This mechanism replaces the TLS KeyUpdate message. Endpoints MUST
NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt
of a TLS KeyUpdate message as a connection error of type 0x10a, of a TLS KeyUpdate message as a connection error of type 0x10a,
equivalent to a fatal TLS alert of unexpected_message (see equivalent to a fatal TLS alert of unexpected_message (see
Section 4.9). Section 4.9).
Figure 8 shows a key update process, where the initial set of keys Figure 9 shows a key update process, where the initial set of keys
used (identified with @M) are replaced by updated keys (identified used (identified with @M) are replaced by updated keys (identified
with @N). The value of the Key Phase bit is indicated in brackets with @N). The value of the Key Phase bit is indicated in brackets
[]. [].
Initiating Peer Responding Peer Initiating Peer Responding Peer
@M [0] QUIC Packets @M [0] QUIC Packets
... Update to @N ... Update to @N
@N [1] QUIC Packets @N [1] QUIC Packets
skipping to change at page 29, line 46 skipping to change at page 31, line 25
QUIC Packets [1] @N QUIC Packets [1] @N
containing ACK containing ACK
<-------- <--------
... Key Update Permitted ... Key Update Permitted
@N [1] QUIC Packets @N [1] QUIC Packets
containing ACK for @N packets containing ACK for @N packets
--------> -------->
Key Update Permitted ... Key Update Permitted ...
Figure 8: Key Update Figure 9: Key Update
6.1. Initiating a Key Update 6.1. Initiating a Key Update
Endpoints maintain separate read and write secrets for packet Endpoints maintain separate read and write secrets for packet
protection. An endpoint initiates a key update by updating its protection. An endpoint initiates a key update by updating its
packet protection write secret and using that to protect new packets. packet protection write secret and using that to protect new packets.
The endpoint creates a new write secret from the existing write The endpoint creates a new write secret from the existing write
secret as performed in Section 7.2 of [TLS13]. This uses the KDF secret as performed in Section 7.2 of [TLS13]. This uses the KDF
function provided by TLS with a label of "quic ku". The function provided by TLS with a label of "quic ku". The
corresponding key and IV are created from that secret as defined in corresponding key and IV are created from that secret as defined in
Section 5.1. The header protection key is not updated. Section 5.1. The header protection key is not updated.
For example, to update write keys with TLS 1.3, HKDF-Expand-Label is For example, to update write keys with TLS 1.3, HKDF-Expand-Label is
used as: used as:
secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku", secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
skipping to change at page 31, line 50 skipping to change at page 33, line 29
protection keys in place of discarded keys when key updates are not protection keys in place of discarded keys when key updates are not
yet permitted. Using dummy keys will generate no variation in the yet permitted. Using dummy keys will generate no variation in the
timing signal produced by attempting to remove packet protection, and timing signal produced by attempting to remove packet protection, and
results in all packets with an invalid Key Phase bit being rejected. results in all packets with an invalid Key Phase bit being rejected.
The process of creating new packet protection keys for receiving The process of creating new packet protection keys for receiving
packets could reveal that a key update has occurred. An endpoint MAY packets could reveal that a key update has occurred. An endpoint MAY
perform this process as part of packet processing, but this creates a perform this process as part of packet processing, but this creates a
timing signal that can be used by an attacker to learn when key timing signal that can be used by an attacker to learn when key
updates happen and thus the value of the Key Phase bit in certain updates happen and thus the value of the Key Phase bit in certain
packets. Endpoints SHOULD instead defer the creation of the next set packets. Endpoints MAY instead defer the creation of the next set of
of receive packet protection keys until some time after a key update receive packet protection keys until some time after a key update
completes, up to three times the PTO; see Section 6.5. completes, up to three times the PTO; see Section 6.5.
Once generated, the next set of packet protection keys SHOULD be Once generated, the next set of packet protection keys SHOULD be
retained, even if the packet that was received was subsequently retained, even if the packet that was received was subsequently
discarded. Packets containing apparent key updates are easy to forge discarded. Packets containing apparent key updates are easy to forge
and - while the process of key update does not require significant and - while the process of key update does not require significant
effort - triggering this process could be used by an attacker for effort - triggering this process could be used by an attacker for
DoS. DoS.
For this reason, endpoints MUST be able to retain two sets of packet For this reason, endpoints MUST be able to retain two sets of packet
skipping to change at page 34, line 29 skipping to change at page 36, line 9
QUIC uses the TLS handshake for more than just negotiation of QUIC uses the TLS handshake for more than just negotiation of
cryptographic parameters. The TLS handshake provides preliminary cryptographic parameters. The TLS handshake provides preliminary
values for QUIC transport parameters and allows a server to perform values for QUIC transport parameters and allows a server to perform
return routability checks on clients. return routability checks on clients.
8.1. Protocol Negotiation 8.1. Protocol Negotiation
QUIC requires that the cryptographic handshake provide authenticated QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation. TLS uses Application Layer Protocol protocol negotiation. TLS uses Application Layer Protocol
Negotiation (ALPN) [RFC7301] to select an application protocol. Negotiation (ALPN) [ALPN] to select an application protocol. Unless
Unless another mechanism is used for agreeing on an application another mechanism is used for agreeing on an application protocol,
protocol, endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST use ALPN for this purpose. When using ALPN, endpoints
endpoints MUST immediately close a connection (see Section 10.3 in MUST immediately close a connection (see Section 10.3 in
[QUIC-TRANSPORT]) if an application protocol is not negotiated with a [QUIC-TRANSPORT]) if an application protocol is not negotiated with a
no_application_protocol TLS alert (QUIC error code 0x178, see no_application_protocol TLS alert (QUIC error code 0x178, see
Section 4.9). While [RFC7301] only specifies that servers use this Section 4.9). While [ALPN] only specifies that servers use this
alert, QUIC clients MUST also use it to terminate a connection when alert, QUIC clients MUST also use it to terminate a connection when
ALPN negotiation fails. ALPN negotiation fails.
An application-layer protocol MAY restrict the QUIC versions that it An application protocol MAY restrict the QUIC versions that it can
can operate over. Servers MUST select an application protocol operate over. Servers MUST select an application protocol compatible
compatible with the QUIC version that the client has selected. If with the QUIC version that the client has selected. The server MUST
the server cannot select a compatible combination of application treat the inability to select a compatible application protocol as a
protocol and QUIC version, it MUST abort the connection. A client connection error of type 0x178 (no_application_protocol). Similarly,
MUST abort a connection if the server picks an application protocol a client MUST treat the selection of an incompatible application
incompatible with the protocol version being used. protocol by a server as a connection error of type 0x178.
8.2. QUIC Transport Parameters Extension 8.2. QUIC Transport Parameters Extension
QUIC transport parameters are carried in a TLS extension. Different QUIC transport parameters are carried in a TLS extension. Different
versions of QUIC might define a different method for negotiating versions of QUIC might define a different method for negotiating
transport configuration. transport configuration.
Including transport parameters in the TLS handshake provides Including transport parameters in the TLS handshake provides
integrity protection for these values. integrity protection for these values.
skipping to change at page 39, line 33 skipping to change at page 41, line 10
The initial secrets use a key that is specific to the negotiated QUIC The initial secrets use a key that is specific to the negotiated QUIC
version. New QUIC versions SHOULD define a new salt value used in version. New QUIC versions SHOULD define a new salt value used in
calculating initial secrets. calculating initial secrets.
10. IANA Considerations 10. IANA Considerations
This document does not create any new IANA registries, but it This document does not create any new IANA registries, but it
registers the values in the following registries: registers the values in the following registries:
o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register o TLS ExtensionType Values Registry [TLS-REGISTRIES] - IANA is to
the quic_transport_parameters extension found in Section 8.2. The register the quic_transport_parameters extension found in
Recommended column is to be marked Yes. The TLS 1.3 Column is to Section 8.2. The Recommended column is to be marked Yes. The TLS
include CH and EE. 1.3 Column is to include CH and EE.
o QUIC Error Codes Registry [QUIC-TRANSPORT] - IANA is to register o QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to
the KEY_UPDATE_ERROR (0xE), as described in Section 6.7. register the KEY_UPDATE_ERROR (0xE), as described in Section 6.7.
11. References 11. References
11.1. Normative References 11.1. Normative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[AES] "Advanced encryption standard (AES)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001. DOI 10.6028/nist.fips.197, November 2001.
[ALPN] 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>.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-24 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-24 (work in progress). transport-latest (work in progress).
[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/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA] Dang, Q., "Secure Hash Standard", National Institute of [SHA] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.180-4, July 2015. DOI 10.6028/nist.fips.180-4, July 2015.
[TLS-REGISTRIES] [TLS-REGISTRIES]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for TLS
skipping to change at page 41, line 18 skipping to change at page 42, line 42
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269,
November 2014. November 2014.
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp. AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019. 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
QUIC", draft-ietf-quic-http-24 (work in progress). (HTTP/3)", draft-ietf-quic-http-latest (work in progress).
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 43, line 22 skipping to change at page 44, line 52
4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006 4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
736572766572ff01000100000a001400 12001d00170018001901000101010201 736572766572ff01000100000a001400 12001d00170018001901000101010201
03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f 03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403 2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
05030603020308040805080604010501 060102010402050206020202002d0002 05030603020308040805080604010501 060102010402050206020202002d0002
0101001c00024001 0101001c00024001
The unprotected header includes the connection ID and a 4 byte packet The unprotected header includes the connection ID and a 4 byte packet
number encoding for a packet number of 2: number encoding for a packet number of 2:
c3ff000017088394c8f03e5157080000449e00000002 c3ff000019088394c8f03e5157080000449e00000002
Protecting the payload produces output that is sampled for header Protecting the payload produces output that is sampled for header
protection. Because the header uses a 4 byte packet number encoding, protection. Because the header uses a 4 byte packet number encoding,
the first 16 bytes of the protected payload is sampled, then applied the first 16 bytes of the protected payload is sampled, then applied
to the header: to the header:
sample = 535064a4268a0d9d7b1c9d250ae35516 sample = 535064a4268a0d9d7b1c9d250ae35516
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 833b343aaa = 833b343aaa
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
= c0 = c0
header[17..20] ^= mask[1..4] header[18..21] ^= mask[1..4]
= 3b343aa8 = 3b343aa8
header = c0ff000017088394c8f03e5157080000449e3b343aa8 header = c0ff000019088394c8f03e5157080000449e3b343aa8
The resulting protected packet is: The resulting protected packet is:
c0ff000017088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c c0ff000019088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752 9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752
4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec 4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec
b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f
e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d
12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6 12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6
11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50 11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50
1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008 1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008
0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f 0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f
cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724 cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724
87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d 87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d
skipping to change at page 44, line 42 skipping to change at page 46, line 42
93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9 93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9
44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14 44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14
a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5 a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5
b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6 b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6
6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e 6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e
c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e
eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f
cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da
acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc
13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d 13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d
c9be6c7803567321829dd85853396269 aebe13f98ec51170a4aad0a8324bb768
A.3. Server Initial A.3. Server Initial
The server sends the following payload in response, including an ACK The server sends the following payload in response, including an ACK
frame, a CRYPTO frame, and no PADDING frames: frame, a CRYPTO frame, and no PADDING frames:
0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988 0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002 89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
0304 0304
The header from the server includes a new connection ID and a 2-byte The header from the server includes a new connection ID and a 2-byte
packet number encoding for a packet number of 1: packet number encoding for a packet number of 1:
c1ff0000170008f067a5502a4262b50040740001 c1ff0000190008f067a5502a4262b50040740001
As a result, after protection, the header protection sample is taken As a result, after protection, the header protection sample is taken
starting from the third protected octet: starting from the third protected octet:
sample = 7002596f99ae67abf65a5852f54f58c3 sample = 7002596f99ae67abf65a5852f54f58c3
mask = 38168a0c25 mask = 38168a0c25
header = c9ff0000170008f067a5502a4262b5004074168b header = c9ff0000190008f067a5502a4262b5004074168b
The final protected packet is then: The final protected packet is then:
c9ff0000170008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a c9ff0000190008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493 5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3 537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b9cf9bb6d091ddfc8b32d cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b99c8ae5833225cb51855
432348a2c413 20d61e68cf5f
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.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
B.1. Since draft-ietf-quic-tls-23 B.1. Since draft-ietf-quic-tls-23
 End of changes. 36 change blocks. 
132 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/