QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-25
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9000.
|
|
|---|---|---|---|
| Authors | Jana Iyengar , Martin Thomson | ||
| Last updated | 2020-01-21 | ||
| Replaces | draft-hamilton-quic-transport-protocol, draft-ietf-quic-spin-exp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-32)
by Stewart Bryant
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9000 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-quic-transport-25
JOSE Working Group M. Jones
Internet-Draft Microsoft
Intended status: Standards Track March 31, 2014
Expires: October 2, 2014
JSON Web Key (JWK)
draft-ietf-jose-json-web-key-25
Abstract
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data
structure that represents a cryptographic key. This specification
also defines a JSON Web Key Set (JWK Set) JSON data structure for
representing a set of JWKs. Cryptographic algorithms and identifiers
for use with this specification are described in the separate JSON
Web Algorithms (JWA) specification and IANA registries defined by
that specification.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
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 October 2, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Jones Expires October 2, 2014 [Page 1]
Internet-Draft JWK March 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Key (JWK) Format . . . . . . . . . . . . . . . . . . 5
3.1. "kty" (Key Type) Parameter . . . . . . . . . . . . . . . . 5
3.2. "use" (Public Key Use) Parameter . . . . . . . . . . . . . 6
3.3. "key_ops" (Key Operations) Parameter . . . . . . . . . . . 6
3.4. "alg" (Algorithm) Parameter . . . . . . . . . . . . . . . 7
3.5. "kid" (Key ID) Parameter . . . . . . . . . . . . . . . . . 7
3.6. "x5u" (X.509 URL) Parameter . . . . . . . . . . . . . . . 8
3.7. "x5c" (X.509 Certificate Chain) Parameter . . . . . . . . 8
3.8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter . . . 9
4. JSON Web Key Set (JWK Set) Format . . . . . . . . . . . . . . 9
4.1. "keys" Parameter . . . . . . . . . . . . . . . . . . . . . 10
5. String Comparison Rules . . . . . . . . . . . . . . . . . . . 10
6. Encrypted JWK and Encrypted JWK Set Formats . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. JSON Web Key Parameters Registry . . . . . . . . . . . . . 11
7.1.1. Registration Template . . . . . . . . . . . . . . . . 12
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13
7.2. JSON Web Key Use Registry . . . . . . . . . . . . . . . . 14
7.2.1. Registration Template . . . . . . . . . . . . . . . . 14
7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 15
7.3. JSON Web Key Operations Registry . . . . . . . . . . . . . 15
7.3.1. Registration Template . . . . . . . . . . . . . . . . 15
7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 16
7.4. JSON Web Key Set Parameters Registry . . . . . . . . . . . 16
7.4.1. Registration Template . . . . . . . . . . . . . . . . 17
7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 17
7.5. Media Type Registration . . . . . . . . . . . . . . . . . 17
7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Example JSON Web Key Sets . . . . . . . . . . . . . . 21
A.1. Example Public Keys . . . . . . . . . . . . . . . . . . . 21
A.2. Example Private Keys . . . . . . . . . . . . . . . . . . . 22
A.3. Example Symmetric Keys . . . . . . . . . . . . . . . . . . 24
Appendix B. Example Use of "x5c" (X.509 Certificate Chain)
Parameter . . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Example Encrypted RSA Private Key . . . . . . . . . . 25
Jones Expires October 2, 2014 [Page 2]
Internet-Draft JWK March 2014
C.1. Plaintext RSA Private Key . . . . . . . . . . . . . . . . 26
C.2. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . 29
C.3. Content Encryption Key (CEK) . . . . . . . . . . . . . . . 29
C.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 30
C.5. Key Encryption . . . . . . . . . . . . . . . . . . . . . . 30
C.6. Initialization Vector . . . . . . . . . . . . . . . . . . 30
C.7. Additional Authenticated Data . . . . . . . . . . . . . . 31
C.8. Content Encryption . . . . . . . . . . . . . . . . . . . . 31
C.9. Complete Representation . . . . . . . . . . . . . . . . . 34
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Appendix E. Document History . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41
Jones Expires October 2, 2014 [Page 3]
Internet-Draft JWK March 2014
1. Introduction
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) [RFC7159]
data structure that represents a cryptographic key. This
specification also defines a JSON Web Key Set (JWK Set) JSON data
structure for representing a set of JWKs. Cryptographic algorithms
and identifiers for use with this specification are described in the
separate JSON Web Algorithms (JWA) [JWA] specification and IANA
registries defined by that specification.
Goals for this specification do not include representing certificate
chains, representing certified keys, and replacing X.509
certificates.
JWKs and JWK Sets are used in the JSON Web Signature (JWS) [JWS] and
JSON Web Encryption (JWE) [JWE] specifications.
Names defined by this specification are short because a core goal is
for the resulting representations to be compact.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in Key
words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
these words are used without being spelled in uppercase then they are
to be interpreted with their normal natural language meanings.
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 2.
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
of STRING.
ASCII(STRING) denotes the octets of the ASCII [USASCII]
representation of STRING.
The concatenation of two values A and B is denoted as A || B.
2. Terminology
These terms defined by the JSON Web Signature (JWS) [JWS]
specification are incorporated into this specification: "Base64url
Encoding" and "Collision-Resistant Name".
These terms are defined for use by this specification:
Jones Expires October 2, 2014 [Page 4]
Internet-Draft JWK March 2014
JSON Web Key (JWK)
A JSON object that represents a cryptographic key.
JSON Web Key Set (JWK Set)
A JSON object that contains an array of JWKs as the value of its
"keys" member.
3. JSON Web Key (JWK) Format
A JSON Web Key (JWK) is a JSON object. The members of the object
represent properties of the key, including its value. This document
defines the key parameters that are not algorithm specific, and thus
common to many keys.
In addition to the common parameters, each JWK will have members that
are specific to the kind of key being represented. These members
represent the parameters of the key. Section 6 of the JSON Web
Algorithms (JWA) [JWA] specification defines multiple kinds of
cryptographic keys and their associated members.
The member names within a JWK MUST be unique; recipients MUST either
reject JWKs with duplicate member names or use a JSON parser that
returns only the lexically last duplicate member name, as specified
in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
Additional members can be present in the JWK; if not understood by
implementations encountering them, they MUST be ignored. Member
names used for representing key parameters for different keys types
need not be distinct. Any new member name should either be
registered in the IANA JSON Web Key Parameters registry defined in
Section 7.1 or be a value that contains a Collision-Resistant Name.
3.1. "kty" (Key Type) Parameter
The "kty" (key type) member identifies the cryptographic algorithm
family used with the key. "kty" values should either be registered in
the IANA JSON Web Key Types registry defined in [JWA] or be a value
that contains a Collision-Resistant Name. The "kty" value is a case-
sensitive string. This member MUST be present in a JWK.
A list of defined "kty" values can be found in the IANA JSON Web Key
Types registry defined in [JWA]; the initial contents of this
registry are the values defined in Section 6.1 of the JSON Web
Algorithms (JWA) [JWA] specification.
The key type definitions include specification of the members to be
used for those key types. Additional members used with "kty" values
Jones Expires October 2, 2014 [Page 5]
Internet-Draft JWK March 2014
can also be found in the IANA JSON Web Key Parameters registry
defined in Section 7.1.
3.2. "use" (Public Key Use) Parameter
The "use" (public key use) member identifies the intended use of the
public key. The "use" parameter is intended for use cases in which
it is useful to distinguish between public signing keys and public
encryption keys. It is not intended for use cases in which private
or symmetric keys may also be present.
Values defined by this specification are:
o "sig" (signature)
o "enc" (encryption)
Other values MAY be used. Public Key Use values can be registered in
the IANA JSON Web Key Use registry defined in Section 7.2. The "use"
value is a case-sensitive string. Use of the "use" member is
OPTIONAL, unless the application requires its presence.
When a key is used to wrap another key and a key use designation for
the first key is desired, the "enc" (encryption) key use value SHOULD
be used, since key wrapping is a kind of encryption. The "enc" value
SHOULD also be used for public keys used for key agreement
operations. (The "alg" member can be used to specify the particular
cryptographic operation to be performed, when desired.)
3.3. "key_ops" (Key Operations) Parameter
The "key_ops" (key operations) member identifies the operations(s)
that the key is intended to be used for. The "key_ops" parameter is
intended for use cases in which public, private, or symmetric keys
may be present.
Its value is an array of key operation values. Values defined by
this specification are:
o "sign" (compute signature or MAC)
o "verify" (verify signature or MAC)
o "encrypt" (encrypt content)
o "decrypt" (decrypt content and validate decryption, if applicable)
Jones Expires October 2, 2014 [Page 6]
quot;, RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
23.2. Informative References
[EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2
December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
Iyengar & Thomson Expires 25 July 2020 [Page 153]
Internet-Draft QUIC Transport Protocol January 2020
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-07, 22 January 2020,
<https://tools.ietf.org/html/draft-ietf-quic-invariants-
07>.
[QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-05, 5 July 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
manageability-05.txt>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, DOI 10.17487/RFC2360, June 1998,
<https://www.rfc-editor.org/info/rfc2360>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
Iyengar & Thomson Expires 25 July 2020 [Page 154]
Internet-Draft QUIC Transport Protocol January 2020
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[SLOWLORIS]
RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
<https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>.
[STD] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
Appendix A. Sample Packet Number Decoding Algorithm
The pseudo-code in Figure 37 shows how an implementation can decode
packet numbers after header protection has been removed.
Iyengar & Thomson Expires 25 July 2020 [Page 155]
Internet-Draft QUIC Transport Protocol January 2020
DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
expected_pn = largest_pn + 1
pn_win = 1 << pn_nbits
pn_hwin = pn_win / 2
pn_mask = pn_win - 1
// The incoming packet number should be greater than
// expected_pn - pn_hwin and less than or equal to
// expected_pn + pn_hwin
//
// This means we can't just strip the trailing bits from
// expected_pn and add the truncated_pn because that might
// yield a value outside the window.
//
// The following code calculates a candidate value and
// makes sure it's within the packet number window.
// Note the extra checks to prevent overflow and underflow.
candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
if candidate_pn <= expected_pn - pn_hwin and
candidate_pn < (1 << 62) - pn_win:
return candidate_pn + pn_win
if candidate_pn > expected_pn + pn_hwin and
candidate_pn >= pn_win:
return candidate_pn - pn_win
return candidate_pn
Figure 37: Sample Packet Number Decoding Algorithm
Appendix B. Sample ECN Validation Algorithm
Each time an endpoint commences sending on a new network path, it
determines whether the path supports ECN; see Section 13.4. If the
path supports ECN, the goal is to use ECN. Endpoints might also
periodically reassess a path that was determined to not support ECN.
This section describes one method for testing new paths. This
algorithm is intended to show how a path might be tested for ECN
support. Endpoints can implement different methods.
The path is assigned an ECN state that is one of "testing",
"unknown", "failed", or "capable". On paths with a "testing" or
"capable" state the endpoint sends packets with an ECT marking, by
default ECT(0); otherwise, the endpoint sends unmarked packets.
To start testing a path, the ECN state is set to "testing" and
existing ECN counts are remembered as a baseline.
The testing period runs for a number of packets or round-trip times,
as determined by the endpoint. The goal is not to limit the duration
Iyengar & Thomson Expires 25 July 2020 [Page 156]
Internet-Draft QUIC Transport Protocol January 2020
of the testing period, but to ensure that enough marked packets are
sent for received ECN counts to provide a clear indication of how the
path treats marked packets. Section 13.4.2.2 suggests limiting this
to 10 packets or 3 round-trip times.
After the testing period ends, the ECN state for the path becomes
"unknown". From the "unknown" state, successful validation of the
ECN counts an ACK frame (see Section 13.4.2.2) causes the ECN state
for the path to become "capable", unless no marked packet has been
acknowledged.
If validation of ECN counts fails at any time, the ECN state for the
affected path becomes "failed". An endpoint can also mark the ECN
state for a path as "failed" if marked packets are all declared lost
or if they are all CE marked.
Following this algorithm ensures that ECN is rarely disabled for
paths that properly support ECN. Any path that incorrectly modifies
markings will cause ECN to be disabled. For those rare cases where
marked packets are discarded by the path, the short duration of the
testing period limits the number of losses incurred.
Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-24
* Added HANDSHAKE_DONE to signal handshake confirmation (#2863,
#3142, #3145)
* Add integrity check to Retry packets (#3014, #3274, #3120)
* Specify handling of reordered NEW_CONNECTION_ID frames (#3194,
#3202)
* Require checking of sequence numbers in RETIRE_CONNECTION_ID
(#3037, #3036)
* active_connection_id_limit is enforced (#3193, #3197, #3200,
#3201)
* Correct overflow in packet number decode algorithm (#3187, #3188)
Iyengar & Thomson Expires 25 July 2020 [Page 157]
Internet-Draft QUIC Transport Protocol January 2020
* Allow use of CRYPTO_BUFFER_EXCEEDED for CRYPTO frame errors
(#3258, #3186)
* Define applicability and scope of NEW_TOKEN (#3150, #3152, #3155,
#3156)
* Tokens from Retry and NEW_TOKEN must be differentiated (#3127,
#3128)
* Allow CONNECTION_CLOSE in response to invalid token (#3168, #3107)
* Treat an invalid CONNECTION_CLOSE as an invalid frame (#2475,
#3230, #3231)
* Throttle when sending CONNECTION_CLOSE after discarding state
(#3095, #3157)
* Application-variant of CONNECTION_CLOSE can only be sent in 0-RTT
or 1-RTT packets (#3158, #3164)
* Advise sending while blocked to avoid idle timeout (#2744, #3266)
* Define error codes for invalid frames (#3027, #3042)
* Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170)
C.2. Since draft-ietf-quic-transport-23
* Allow ClientHello to span multiple packets (#2928, #3045)
* Client Initial size constraints apply to UDP datagram payload
(#3053, #3051)
* Stateless reset changes (#2152, #2993)
- tokens need to be compared in constant time
- detection uses UDP datagrams, not packets
- tokens cannot be reused (#2785, #2968)
* Clearer rules for sharing of UDP ports and use of connection IDs
when doing so (#2844, #2851)
Iyengar & Thomson Expires 25 July 2020 [Page 158]
Internet-Draft QUIC Transport Protocol January 2020
* A new connection ID is necessary when responding to migration
(#2778, #2969)
* Stronger requirements for connection ID retirement (#3046, #3096)
* NEW_TOKEN cannot be empty (#2978, #2977)
* PING can be sent at any encryption level (#3034, #3035)
* CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
* Frame encoding error conditions updated (#3027, #3042)
* Non-ack-eliciting packets cannot be sent in response to non-ack-
eliciting packets (#3100, #3104)
* Servers have to change connection IDs in Retry (#2837, #3147)
C.3. Since draft-ietf-quic-transport-22
* Rules for preventing correlation by connection ID tightened
(#2084, #2929)
* Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688)
* Discourage regressions of largest acknowledged in ACK (#2205,
#2752)
* Improved robustness of validation process for ECN counts (#2534,
#2752)
* Require endpoints to ignore spurious migration attempts (#2342,
#2893)
* Transport parameter for disabling migration clarified to allow NAT
rebinding (#2389, #2893)
* Document principles for defining new error codes (#2388, #2880)
* Reserve transport parameters for greasing (#2550, #2873)
* A maximum ACK delay of 0 is used for handshake packet number
spaces (#2646, #2638)
* Improved rules for use of congestion control state on new paths
(#2685, #2918)
Iyengar & Thomson Expires 25 July 2020 [Page 159]
Internet-Draft QUIC Transport Protocol January 2020
* Removed recommendation to coordinate spin for multiple connections
that share a path (#2763, #2882)
* Allow smaller stateless resets and recommend a smaller minimum on
packets that might trigger a stateless reset (#2770, #2869, #2927,
#3007).
* Provide guidance around the interface to QUIC as used by
application protocols (#2805, #2857)
* Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
#2826)
* Tighter rules about processing of rejected 0-RTT packets (#2829,
#2840, #2841)
* Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
* Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921)
* Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916).
C.4. Since draft-ietf-quic-transport-21
* Connection ID lengths are now one octet, but limited in version 1
to 20 octets of length (#2736, #2749)
C.5. Since draft-ietf-quic-transport-20
* Error codes are encoded as variable-length integers (#2672, #2680)
* NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769)
* Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794)
* Recommend having only one packet per encryption level in a
datagram (#2308, #2747)
* More normative language about use of stateless reset (#2471,
#2574)
* Allow reuse of stateless reset tokens (#2732, #2733)
Iyengar & Thomson Expires 25 July 2020 [Page 160]
Internet-Draft QUIC Transport Protocol January 2020
Internet-Draft JWK March 2014
o "wrapKey" (encrypt key)
o "unwrapKey" (decrypt key and validate decryption, if applicable)
o "deriveKey" (derive key)
o "deriveBits" (derive bits not to be used as a key)
(Note that the "key_ops" values intentionally match the "KeyUsage"
values defined in the Web Cryptography API [WebCrypto]
specification.)
Other values MAY be used. Key operation values can be registered in
the IANA JSON Web Key Operations registry defined in Section 7.3.
The key operation values are case-sensitive strings. Duplicate key
operation values MUST NOT be present in the array.
Use of the "key_ops" member is OPTIONAL, unless the application
requires its presence.
Multiple unrelated key operations SHOULD NOT be specified for a key
because of the potential vulnerabilities associated with using the
same key with multiple algorithms. Thus, the combinations "sign"
with "verify", "encrypt" with "decrypt", and "wrapKey" with
"unwrapKey" are permitted, but other combinations SHOULD NOT be used.
The "use" and "key_ops" JWK members SHOULD NOT be used together.
Applications should specify which of these members they use, if
either is to be used by the application.
3.4. "alg" (Algorithm) Parameter
The "alg" (algorithm) member identifies the algorithm intended for
use with the key. The values used should either be registered in the
IANA JSON Web Signature and Encryption Algorithms registry defined in
[JWA] or be a value that contains a Collision-Resistant Name. Use of
this member is OPTIONAL.
3.5. "kid" (Key ID) Parameter
The "kid" (key ID) member can be used to match a specific key. This
can be used, for instance, to choose among a set of keys within a JWK
Set during key rollover. The structure of the "kid" value is
unspecified. When "kid" values are used within a JWK Set, different
keys within the JWK Set SHOULD use distinct "kid" values. (One
example in which different keys might use the same "kid" value is if
they have different "kty" (key type) values but are considered to be
equivalent alternatives by the application using them.) The "kid"
Jones Expires October 2, 2014 [Page 7]
Internet-Draft JWK March 2014
value is a case-sensitive string. Use of this member is OPTIONAL.
When used with JWS or JWE, the "kid" value is used to match a JWS or
JWE "kid" Header Parameter value.
3.6. "x5u" (X.509 URL) Parameter
The "x5u" (X.509 URL) member is a URI [RFC3986] that refers to a
resource for an X.509 public key certificate or certificate chain
[RFC5280]. The identified resource MUST provide a representation of
the certificate or certificate chain that conforms to RFC 5280
[RFC5280] in PEM encoded form [RFC1421]. The key in the first
certificate MUST match the public key represented by other members of
the JWK. The protocol used to acquire the resource MUST provide
integrity protection; an HTTP GET request to retrieve the certificate
MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be
validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of
this member is OPTIONAL.
While there is no requirement that members other than those
representing the public key be populated when an "x5u" member is
present, doing so may improve interoperability for applications that
do not handle PKIX certificates. If other members are present, the
contents of those members MUST be semantically consistent with the
related fields in the first certificate. For instance, if the "use"
member is present, then it needs to allow for only a subset of the
usages that are permitted by the certificate. Similarly, if the
"alg" member is present, it should represent an algorithm that the
certificate allows.
3.7. "x5c" (X.509 Certificate Chain) Parameter
The "x5c" (X.509 Certificate Chain) member contains a chain of one or
more PKIX certificates [RFC5280]. The certificate chain is
represented as a JSON array of certificate value strings. Each
string in the array is a base64 encoded ([RFC4648] Section 4 -- not
base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The
PKIX certificate containing the key value MUST be the first
certificate. This MAY be followed by additional certificates, with
each subsequent certificate being the one used to certify the
previous one. The key in the first certificate MUST match the public
key represented by other members of the JWK. Use of this member is
OPTIONAL.
As with the "x5u" member, members other than those representing the
public key may also be populated when an "x5c" member is present. If
other members are present, the contents of those members MUST be
semantically consistent with the related fields in the first
Jones Expires October 2, 2014 [Page 8]
Internet-Draft JWK March 2014
certificate. See the last paragraph of Section 3.6 for additional
guidance on this.
3.8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter
The "x5t" (X.509 Certificate SHA-1 Thumbprint) member is a base64url
encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an
X.509 certificate [RFC5280]. The key in the certificate MUST match
the public key represented by other members of the JWK. Use of this
member is OPTIONAL.
If, in the future, certificate thumbprints need to be computed using
hash functions other than SHA-1, it is suggested that additional
related JWK parameters be defined for that purpose. For example, it
is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) JWK parameter could be defined by registering it in
the IANA JSON Web Key Parameters registry defined in Section 7.1.
As with the "x5u&* Allow, but not require, enforcing non-duplicate transport
parameters (#2689, #2691)
* Added an active_connection_id_limit transport parameter (#1994,
#1998)
* max_ack_delay transport parameter defaults to 0 (#2638, #2646)
* When sending 0-RTT, only remembered transport parameters apply
(#2458, #2360, #2466, #2461)
* Define handshake completion and confirmation; define clearer rules
when it encryption keys should be discarded (#2214, #2267, #2673)
* Prohibit path migration prior to handshake confirmation (#2309,
#2370)
* PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637)
* PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729)
* Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402)
C.6. Since draft-ietf-quic-transport-19
* Refine discussion of 0-RTT transport parameters (#2467, #2464)
* Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467)
* Spin bit text incorporated (#2564)
* Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487)
* New connection ID required for intentional migration (#2414,
#2413)
* Connection ID issuance can be rate-limited (#2436, #2428)
* The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
* Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523)
Iyengar & Thomson Expires 25 July 2020 [Page 161]
Internet-Draft QUIC Transport Protocol January 2020
* CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524)
* Stateless reset uses a short header packet (#2599, #2600)
C.7. Since draft-ietf-quic-transport-18
* Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313)
* Added discussion of the use of IPv6 flow labels (#2348, #2399)
* A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420)
* Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454)
* Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414)
* Increased the set of permissible frames in 0-RTT (#2344, #2355)
C.8. Since draft-ietf-quic-transport-17
* Stream-related errors now use STREAM_STATE_ERROR (#2305)
* Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045)
* Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161)
* Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
#2241)
* Endpoints are permitted to discard malformed initial packets
(#2141)
* Clarified ECN implementation and usage requirements (#2156, #2201)
* Disable ECN count verification for packets that arrive out of
order (#2198, #2215)
* Use Probe Timeout (PTO) instead of RTO (#2206, #2238)
* Loosen constraints on retransmission of ACK ranges (#2199, #2245)
Iyengar & Thomson Expires 25 July 2020 [Page 162]
Internet-Draft QUIC Transport Protocol January 2020
* Limit Retry and Version Negotiation to once per datagram (#2259,
#2303)
* Set a maximum value for max_ack_delay transport parameter (#2282,
#2301)
* Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296)
* Corrected requirements for migration to a preferred address
(#2146, #2349)
* ACK of non-existent packet is illegal (#2298, #2302)
C.9. Since draft-ietf-quic-transport-16
* Stream limits are defined as counts, not maximums (#1850, #1906)
* Require amplification attack defense after closing (#1905, #1911)
* Remove reservation of application error code 0 for STOPPING
(#1804, #1922)
* Renumbered frames (#1945)
* Renumbered transport parameters (#1946)
* Numeric transport parameters are expressed as varints (#1608,
#1947, #1955)
* Reorder the NEW_CONNECTION_ID frame (#1952, #1963)
* Rework the first byte (#2006)
- Fix the 0x40 bit
- Change type values for long header
- Add spin bit to short header (#631, #1988)
- Encrypt the remainder of the first byte (#1322)
- Move packet number length to first byte
- Move ODCIL to first byte of retry packets
- Simplify packet number protection (#1575)
Iyengar & Thomson Expires 25 July 2020 [Page 163]
Internet-Draft QUIC Transport Protocol January 2020
* Allow STOP_SENDING to open a remote bidirectional stream (#1797,
#2013)
* Added mitigation for off-path migration attacks (#1278, #1749,
#2033)
* Don't let the PMTU to drop below 1280 (#2063, #2069)
* Require peers to replace retired connection IDs (#2085)
* Servers are required to ignore Version Negotiation packets (#2088)
* Tokens are repeated in all Initial packets (#2089)
* Clarified how PING frames are sent after loss (#2094)
* Initial keys are discarded once Handshake are available (#1951,
#2045)
* ICMP PTB validation clarifications (#2161, #2109, #2108)
C.10. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes.
C.11. Since draft-ietf-quic-transport-14
* Merge ACK and ACK_ECN (#1778, #1801)
* Explicitly communicate max_ack_delay (#981, #1781)
* Validate original connection ID after Retry packets (#1710, #1486,
#1793)
* Idle timeout is optional and has no specified maximum (#1765)
* Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821)
* Include a Token in all Initial packets (#1649, #1794)
* Prevent handshake deadlock (#1764, #1824)
C.12. Since draft-ietf-quic-transport-13
* Streams open when higher-numbered streams of the same type open
(#1342, #1549)
Iyengar & Thomson Expires 25 July 2020 [Page 164]
Internet-Draft QUIC Transport Protocol January 2020
* Split initial stream flow control limit into 3 transport
parameters (#1016, #1542)
* All flow control transport parameters are optional (#1610)
* Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
* Permit stateless reset in response to any packet (#1348, #1553)
* Recommended defense against stateless reset spoofing (#1386,
#1554)
* Prevent infinite stateless reset exchanges (#1443, #1627)
* Forbid processing of the same packet number twice (#1405, #1624)
* Added a packet number decoding example (#1493)
* More precisely define idle timeout (#1429, #1614, #1652)
* Corrected format of Retry packet and prevented looping (#1492,
#1451, #1448, #1498)
* Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621)
* Permit Retry in response to 0-RTT (#1547, #1552)
* Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565)
* Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
C.13. Since draft-ietf-quic-transport-12
* Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458)
- The cryptographic handshake uses CRYPTO frames, not stream 0
- QUIC packet protection is used in place of TLS record
protection
- Separate QUIC packet number spaces are used for the handshake
- Changed Retry to be independent of the cryptographic handshake
- Added NEW_TOKEN frame and Token fields to Initial packet
Iyengar & Thomson Expires 25 July 2020 [Page 165]
Internet-Draft QUIC Transport Protocol January 2020
- Limit the use of HelloRetryRequest to address TLS needs (like
key shares)
* Enable server to transition connections to a preferred address
(#560, #1251, #1373)
* Added ECN feedback mechanisms and handling; new ACK_ECN frame
(#804, #805, #1372)
* Changed rules and recommendations for use of new connection IDs
(#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465)
* Added a transport parameter to disable intentional connection
migration (#1271, #1447)
* Packets from different connection ID can't be coalesced (#1287,
#1423)
* Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389)
* Stateless Reset is now symmetric and subject to size constraints
(#466, #1346)
* Added frame type extension mechanism (#58, #1473)
C.14. Since draft-ietf-quic-transport-11
* Enable server to transition connections to a preferred address
(#560, #1251)
* Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079)
* Packet numbers use a variable-length encoding (#989, #1334)
* STREAM frames can now be empty (#1350)
C.15. Since draft-ietf-quic-transport-10
* Swap payload length and packed number fields in long header
(#1294)
* Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274)
* Spin bit reserved (#1283)
Iyengar & Thomson Expires 25 July 2020 [Page 166]
Internet-Draft QUIC Transport Protocol January 2020
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
* A more complete connection migration (#1249)
* Refine opportunistic ACK defense text (#305, #1030, #1185)
* A Stateless Reset Token isn't mandatory (#818, #1191)
* Removed implicit stream opening (#896, #1193)
* An empty STREAM frame can be used to open a stream without sending
data (#901, #1194)
* Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065)
* STOP_SENDING is now prohibited before streams are used (#1050)
* Recommend including ACK in Retry packets and allow PADDING (#1067,
#882)
* Endpoints now become closing after an idle timeout (#1178, #1179)
* Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197)
C.16. Since draft-ietf-quic-transport-09
* Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086)
* A server can now only send 3 packets without validating the client
address (#38, #1090)
* Delivery order of stream data is no longer strongly specified
(#252, #1070)
* Rework of packet handling and version negotiation (#1038)
* Stream 0 is now exempt from flow control until the handshake
completes (#1074, #725, #825, #1082)
* Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053)
* Added an error code for server busy signals (#1137)
Iyengar & Thomson Expires 25 July 2020 [Page 167]
Internet-Draft QUIC Transport Protocol January 2020
* Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
C.17. Since draft-ietf-quic-transport-08
* Clarified requirements for BLOCKED usage (#65, #924)
* BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928)
* GAP limitation in ACK Frame (#613)
* Improved PMTUD description (#614, #1036)
* Clarified stream state machine (#634, #662, #743, #894)
* Reserved versions don't need to be generated deterministically
(#831, #931)
* You don't always need the draining period (#871)
* Stateless reset clarified as version-specific (#930, #986)
* initial_max_stream_id_x transport parameters are optional (#970,
#971)
* Ack Delay assumes a default value during the handshake (#1007,
#1009)
* Removed transport parameters from NewSessionTicket (#1015)
C.18. Since draft-ietf-quic-transport-07
* The long header now has version before packet number (#926, #939)
* Rename and consolidate packet types (#846, #822, #847)
* Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956)
* Removed type for Version Negotiation and use Version 0 (#963,
#968)
* Streams are split into unidirectional and bidirectional (#643,
#656, #720, #872, #175, #885)
Iyengar & Thomson Expires 25 July 2020 [Page 168]
Internet-Draft QUIC Transport Protocol January 2020
- Stream limits now have separate uni- and bi-directional
transport parameters (#909, #958)
- Stream limit transport parameters are now optional and default
to 0 (#970, #971)
* The stream state machine has been split into read and write (#634,
#894)
* Employ variable-length integer encodings throughout (#595)
* Improvements to connection close
- Added distinct closing and draining states (#899, #871)
- Draining period can terminate early (#869, #870)
- Clarifications about stateless reset (#889, #890)
* Address validation for connection migration (#161, #732, #878)
* Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
* negotiated_version is sent in server transport parameters (#710,
#959)
* Increased the range over which packet numbers are randomized
(#864, #850, #964)
C.19. Since draft-ietf-quic-transport-06
* Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
* Split error code space between application and transport (#485)
* Stateless reset token moved to end (#820)
* 1-RTT-protected long header types removed (#848)
* No acknowledgments during draining period (#852)
* Remove "application close" as a separate close type (#854)
* Remove timestamps from the ACK frame (#841)
* Require transport parameters to only appear once (#792)
Iyengar & Thomson Expires 25 July 2020 [Page 169]
Internet-Draft QUIC Transport Protocol January 2020
C.20. Since draft-ietf-quic-transport-05
* Stateless token is server-only (#726)
* Refactor section on connection termination (#733, #748, #328,
#177)
* Limit size of Version Negotiation packet (#585)
* Clarify when and what to ack (#736)
* Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
* Clarify Keep-alive requirements (#729)
C.21. Since draft-ietf-quic-transport-04
* Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165)
* Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696)
* Reduced the number of error codes (#96, #177, #184, #211)
* Version validation fields can't move or change (#121)
* Removed versions from the transport parameters in a
NewSessionTicket message (#547)
* Clarify the meaning of "bytes in flight" (#550)
* Public reset is now stateless reset and not visible to the path
(#215)
* Reordered bits and fields in STREAM frame (#620)
* Clarifications to the stream state machine (#572, #571)
* Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629)
* truncate_connection_id is renamed to omit_connection_id (#659)
* CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328)
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
Iyengar & Thomson Expires 25 July 2020 [Page 170]
Internet-Draft QUIC Transport Protocol January 2020
C.22. Since draft-ietf-quic-transport-03
* Change STREAM and RESET_STREAM layout
* Add MAX_STREAM_ID settings
C.23. Since draft-ietf-quic-transport-02
* The size of the initial packet payload has a fixed minimum (#267,
#472)
* Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474)
* The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517)
* Rework initial packet types to change how the connection ID is
chosen (#482, #442, #493)
* No timestamps are forbidden in unprotected packets (#542, #429)
* Cryptographic handshake is now on stream 0 (#456)
* Remove congestion control exemption for cryptographic handshake
(#248, #476)
* Version 1 of QUIC uses TLS; a new version is needed to use a
different handshake protocol (#516)
* STREAM frames have a reduced number of offset lengths (#543, #430)
* Split some frames into separate connection- and stream- level
frames (#443)
- WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)
- BLOCKED split to match WINDOW_UPDATE split (#454)
- Define STREAM_ID_NEEDED frame (#455)
* A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496)
* Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512)
Iyengar & Thomson Expires 25 July 2020 [Page 171]
Internet-Draft QUIC Transport Protocol January 2020
- A client in 0-RTT no longer required to reset excess streams
(#425, #479)
* Expanded security considerations (#440, #444, #445, #448)
C.24. Since draft-ietf-quic-transport-01
* Defined short and long packet headers (#40, #148, #361)
* Defined a versioning scheme and stable fields (#51, #361)
* Define reserved version values for "greasing" negotiation (#112,
#278)
* The initial packet number is randomized (#35, #283)
* Narrow the packet number encoding range requirement (#67, #286,
#299, #323, #356)
* Defined client address validation (#52, #118, #120, #275)
* Define transport parameters as a TLS extension (#49, #122)
* SCUP and COPT parameters are no longer valid (#116, #117)
* Transport parameters for 0-RTT are either remembered from before,
or assume default values (#126)
* The server chooses connection IDs in its final flight (#119, #349,
#361)
* The server echoes the Connection ID and packet number fields when
sending a Version Negotiation packet (#133, #295, #244)
* Defined a minimum packet size for the initial handshake packet
from the client (#69, #136, #139, #164)
* Path MTU Discovery (#64, #106)
* The initial handshake packet from the client needs to fit in a
single packet (#338)
* Forbid acknowledgment of packets containing only ACK and PADDING
(#291)
* Require that frames are processed when packets are acknowledged
(#381, #341)
Iyengar & Thomson Expires 25 July 2020 [Page 172]
Internet-Draft QUIC Transport Protocol January 2020
* Removed the STOP_WAITING frame (#66)
* Don't require retransmission of old timestamps for lost ACK frames
(#308)
* Clarified that frames are not retransmitted, but the information
in them can be (#157, #298)
* Error handling definitions (#335)
* Split error codes into four sections (#74)
* Forbid the use of Public Reset where CONNECTION_CLOSE is possible
(#289)
* Define packet protection rules (#336)
* Require that stream be entirely delivered or reset, including
acknowledgment of all STREAM frames or the RESET_STREAM, before it
closes (#381)
* Remove stream reservation from state machine (#174, #280)
* Only stream 1 does not contribute to connection-level flow control
(#204)
* Stream 1 counts towards the maximum concurrent stream limit (#201,
#282)
* Remove connection-level flow control exclusion for some streams
(except 1) (#246)
* RESET_STREAM affects connection-level flow control (#162, #163)
* Flow control accounting uses the maximum data offset on each
stream, rather than bytes received (#378)
* Moved length-determining fields to the start of STREAM and ACK
(#168, #277)
* Added the ability to pad between frames (#158, #276)
* Remove error code and reason phrase from GOAWAY (#352, #355)
* GOAWAY includes a final stream number for both directions (#347)
* Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249)
Iyengar & Thomson Expires 25 July 2020 [Page 173]
Internet-Draft QUIC Transport Protocol January 2020
* Defined priority as the responsibility of the application protocol
(#104, #303)
C.25. Since draft-ietf-quic-transport-00
* Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
* Defined versioning
* Reworked description of packet and frame layout
* Error code space is divided into regions for each component
* Use big endian for all numeric values
C.26. Since draft-hamilton-quic-transport-protocol-01
* Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list
* Added IANA Considerations section
* Moved Contributors and Acknowledgments to appendices
Contributors
The original design and rationale behind this protocol draw
significantly from work by Jim Roskind [EARLY-DESIGN].
The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive
contributions to this document: Alessandro Ghedini, Alyssa Wilk,
Antoine Delignat-Lavaud, Brian Trammell, Christian Huitema, Colin
Perkins, David Schinazi, Dmitri Tikhonov, Eric Kinnear, Eric
Rescorla, Gorry Fairhurst, Ian Swett, Igor Lubashev, 奥 一穂 (Kazuho
Oku), Lucas Pardue, Magnus Westerlund, Marten Seemann, Martin Duke,
Mike Bishop, Mikkel Fahnøe Jørgensen, Mirja Kühlewind, Nick Banks,
Nick Harper, Patrick McManus, Roberto Peon, Ryan Hamilton, Subodh
Iyengar, Tatsuhiro Tsujikawa, Ted Hardie, Tom Jones, and Victor
Vasiliev.
Authors' Addresses
Jana Iyengar (editor)
Fastly
Email: jri.ietf@gmail.com
Iyengar & Thomson Expires 25 July 2020 [Page 174]
Internet-Draft QUIC Transport Protocol January 2020
Martin Thomson (editor)
Mozilla
Email: mt@lowentropy.net
Iyengar & Thomson Expires 25 July 2020 [Page 175]