From cfad425244b05c8786213cfc2a2a28ba572dbce2 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sat, 30 Sep 2017 15:27:40 -0700 Subject: [PATCH 1/2] Fix references to drafts. --- draft-ietf-quic-http.md | 33 +++----------- draft-ietf-quic-recovery.md | 21 +-------- draft-ietf-quic-transport.md | 84 +++++++++++------------------------- 3 files changed, 32 insertions(+), 106 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 180452b952..1dae018e0d 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -19,27 +19,6 @@ author: email: Michael.Bishop@microsoft.com role: editor -normative: - - QUIC-TRANSPORT: - title: "QUIC: A UDP-Based Multiplexed and Secure Transport" - date: {DATE} - seriesinfo: - Internet-Draft: draft-ietf-quic-transport-latest - author: - - - ins: J. Iyengar - name: Jana Iyengar - org: Google - role: editor - - - ins: M. Thomson - name: Martin Thomson - org: Mozilla - role: editor - -informative: - --- abstract @@ -72,8 +51,8 @@ semantics over QUIC, drawing heavily on the existing TCP mapping, HTTP/2. Specifically, this document identifies HTTP/2 features that are subsumed by QUIC, and describes how the other features can be implemented atop QUIC. -QUIC is described in {{QUIC-TRANSPORT}}. For a full description of HTTP/2, see -{{!RFC7540}}. +QUIC is described in {{!I-D.ietf-quic-transport}}. For a full description of +HTTP/2, see {{!RFC7540}}. ## Notational Conventions @@ -140,9 +119,9 @@ MAY omit supported versions for any reason. # Connection Establishment {#connection-establishment} -HTTP/QUIC connections are established as described in {{QUIC-TRANSPORT}}. During -connection establishment, HTTP/QUIC support is indicated by selecting the ALPN -token "hq" in the crypto handshake. +HTTP/QUIC connections are established as described in +{{!I-D.ietf-quic-transport}}. During connection establishment, HTTP/QUIC support +is indicated by selecting the ALPN token "hq" in the crypto handshake. While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, HTTP-specific settings are conveyed @@ -872,7 +851,7 @@ establishment to servers. QUIC allows the application to abruptly terminate (reset) individual streams or the entire connection when an error is encountered. These are referred to as "stream errors" or "connection errors" and are described in more detail in -[QUIC-TRANSPORT]. +{{!I-D.ietf-quic-transport}}. This section describes HTTP-specific error codes which can be used to express the cause of a connection or stream error. diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 0eb8bcba1c..39b1d498b1 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -25,25 +25,6 @@ author: email: ianswett@google.com role: editor -normative: - - QUIC-TRANSPORT: - title: "QUIC: A UDP-Based Multiplexed and Secure Transport" - date: {DATE} - seriesinfo: - Internet-Draft: draft-ietf-quic-transport-latest - author: - - - ins: J. Iyengar - name: Jana Iyengar - org: Google - role: editor - - - ins: M. Thomson - name: Martin Thomson - org: Mozilla - role: editor - --- abstract This document describes loss detection and congestion control mechanisms for @@ -66,7 +47,7 @@ code and issues list for this draft can be found at QUIC is a new multiplexed and secure transport atop UDP. QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. The QUIC protocol is -described in {{QUIC-TRANSPORT}}. +described in {{!I-D.ietf-quic-transport}}. QUIC implements the spirit of known TCP loss recovery mechanisms, described in RFCs, various Internet-drafts, and also those prevalent in the Linux TCP diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5ea87bcb8d..64b976d965 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -25,42 +25,6 @@ author: email: martin.thomson@gmail.com role: editor -normative: - - QUIC-RECOVERY: - title: "QUIC Loss Detection and Congestion Control" - date: {DATE} - seriesinfo: - Internet-Draft: draft-ietf-quic-recovery-latest - author: - - - ins: J. Iyengar - name: Jana Iyengar - org: Google - role: editor - - - ins: I. Swett - name: Ian Swett - org: Google - role: editor - - QUIC-TLS: - title: "Using Transport Layer Security (TLS) to Secure QUIC" - date: {DATE} - seriesinfo: - Internet-Draft: draft-ietf-quic-tls-latest - author: - - - ins: M. Thomson - name: Martin Thomson - org: Mozilla - role: editor - - - ins: S. Turner - name: Sean Turner - org: sn3rd - role: editor - informative: EARLY-DESIGN: @@ -115,7 +79,8 @@ QUIC protocol for connection establishment, stream multiplexing, stream and connection-level flow control, and data reliability. Accompanying documents describe QUIC's loss detection and congestion control -{{QUIC-RECOVERY}}, and the use of TLS 1.3 for key negotiation {{QUIC-TLS}}. +{{!I-D.ietf-quic-recovery}}, and the use of TLS 1.3 for key negotiation +{{!I-D.ietf-quic-tls}}. # Conventions and Definitions @@ -210,7 +175,7 @@ the cryptographic handshake and QUIC options negotiation. The format of the QUIC options and parameters used during negotiation are described in this document, but the handshake protocol that runs on Stream ID 0 is described in the accompanying cryptographic handshake -draft {{QUIC-TLS}}. +draft {{!I-D.ietf-quic-tls}}. ## Stream Multiplexing @@ -302,7 +267,7 @@ The version 0x00000000 is reserved to represent an invalid version. This version of the specification is identified by the number 0x00000001. Version 0x00000001 of QUIC uses TLS as a cryptographic handshake protocol, as -described in {{QUIC-TLS}}. +described in {{!I-D.ietf-quic-tls}}. Versions with the most significant 16 bits of the version number cleared are reserved for use in future IETF consensus documents. @@ -474,7 +439,7 @@ Key Phase Bit: : The third bit (0x20) of octet 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection keys that are used to - protect the packet. See {{QUIC-TLS}} for details. + protect the packet. See {{!I-D.ietf-quic-tls}} for details. Short Packet Type: @@ -556,7 +521,7 @@ Cleartext packets are sent during the handshake prior to key negotiation. All cleartext packets contain the current QUIC version in the version field. The payload of cleartext packets also includes an integrity check, which is -described in {{QUIC-TLS}}. +described in {{!I-D.ietf-quic-tls}}. ### Client Initial Packet {#packet-client-initial} @@ -674,18 +639,18 @@ different connection ID from the server, it MUST NOT update the connection ID it uses for 0-RTT packets. This enables consistent routing for all 0-RTT packets. Packets protected with 1-RTT keys that use long headers use a type value of 0x07 -for key phase 0 and 0x08 for key phase 1; see {{QUIC-TLS}} for more details on -the use of key phases. The connection ID field for these packet types MUST -contain the value selected by the server, see {{connection-id}}. +for key phase 0 and 0x08 for key phase 1; see {{!I-D.ietf-quic-tls}} for more +details on the use of key phases. The connection ID field for these packet +types MUST contain the value selected by the server, see {{connection-id}}. The version field for protected packets is the current QUIC version. The packet number field contains a packet number, which increases with each packet sent, see {{packet-numbers}} for details. -The payload is protected using authenticated encryption. {{QUIC-TLS}} describes -packet protection in detail. After decryption, the plaintext consists of a -sequence of frames, as described in {{frames}}. +The payload is protected using authenticated encryption. {{!I-D.ietf-quic-tls}} +describes packet protection in detail. After decryption, the plaintext consists +of a sequence of frames, as described in {{frames}}. ## Connection ID {#connection-id} @@ -955,8 +920,8 @@ solicit a list of supported versions from a server. QUIC relies on a combined cryptographic and transport handshake to minimize connection establishment latency. QUIC allocates stream 0 for the cryptographic handshake. Version 0x00000001 of QUIC uses TLS 1.3 as described in -{{QUIC-TLS}}; a different QUIC version number could indicate that a different -cryptographic handshake protocol is in use. +{{!I-D.ietf-quic-tls}}; a different QUIC version number could indicate that a +different cryptographic handshake protocol is in use. QUIC provides this stream with reliable, ordered delivery of data. In return, the cryptographic handshake provides QUIC with: @@ -998,7 +963,7 @@ a 1232 octet QUIC packet payload. This includes overheads that reduce the space available to the cryptographic handshake protocol. Details of how TLS is integrated with QUIC is provided in more detail in -{{QUIC-TLS}}. +{{!I-D.ietf-quic-tls}}. ## Transport Parameters @@ -1050,8 +1015,8 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}. {: #figure-transport-parameters title="Definition of TransportParameters"} The `extension_data` field of the quic_transport_parameters extension defined in -{{QUIC-TLS}} contains a TransportParameters value. TLS encoding rules are -therefore used to encode the transport parameters. +{{!I-D.ietf-quic-tls}} contains a TransportParameters value. TLS encoding rules +are therefore used to encode the transport parameters. QUIC encodes transport parameters into a sequence of octets, which are then included in the cryptographic handshake. Once the handshake completes, the @@ -1424,8 +1389,8 @@ Gap = HKDF-Expand-Label(packet_number_secret, ~~~ The output of HKDF-Expand-Label is interpreted as a big-endian -number. "packet_number_secret" is derived from the TLS key exchange, -as described in Section 5.6 of {{QUIC-TLS}}. +number. "packet_number_secret" is derived from the TLS key exchange, as +described in Section 5.6 of {{!I-D.ietf-quic-tls}}. ### Address Validation for Migrated Connections @@ -1453,8 +1418,9 @@ signal, or they might be retransmissions of packets for which acknowledgments were lost. The draining period persists for three times the current Retransmission Timeout -(RTO) interval as defined in {{QUIC-RECOVERY}}. During this period, new packets -can be acknowledged, but no new application data can be sent on the connection. +(RTO) interval as defined in {{!I-D.ietf-quic-recovery}}. During this period, +new packets can be acknowledged, but no new application data can be sent on the +connection. Different treatment is given to packets that are received while a connection is in the draining period depending on how the connection was closed. In all @@ -2424,7 +2390,7 @@ When a packet is detected as lost, the sender re-sends any frames as necessary: Upon detecting losses, a sender MUST take appropriate congestion control action. The details of loss detection and congestion control are described in -{{QUIC-RECOVERY}}. +{{!I-D.ietf-quic-recovery}}. A packet MUST NOT be acknowledged until packet protection has been successfully removed and all frames contained in the packet have been processed. For STREAM @@ -2441,7 +2407,7 @@ acknowledge packets containing only ACK or PADDING frames in the next ACK frame that it sends. Strategies and implications of the frequency of generating acknowledgments are -discussed in more detail in {{QUIC-RECOVERY}}. +discussed in more detail in {{!I-D.ietf-quic-recovery}}. ## Special Considerations for PMTU Discovery @@ -2777,7 +2743,7 @@ is exempt from the connection-level data limits established by MAX_DATA. Stream 0 is still subject to stream-level data limits and MAX_STREAM_DATA. Flow control is described in detail in {{flow-control}}, and congestion control -is described in the companion document {{QUIC-RECOVERY}}. +is described in the companion document {{!I-D.ietf-quic-recovery}}. ## Stream Prioritization From 85e5011bfa9495447bb891619f8c1ffc2d6ee12d Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sat, 30 Sep 2017 15:31:55 -0700 Subject: [PATCH 2/2] fix tls draft as well --- draft-ietf-quic-tls.md | 54 ++++++++++++++---------------------------- 1 file changed, 18 insertions(+), 36 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index eff99dfe85..259c9cfdbc 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -25,25 +25,6 @@ author: email: sean@sn3rd.com role: editor -normative: - - QUIC-TRANSPORT: - title: "QUIC: A UDP-Based Multiplexed and Secure Transport" - date: {DATE} - seriesinfo: - Internet-Draft: draft-ietf-quic-transport-latest - author: - - - ins: J. Iyengar - name: Jana Iyengar - org: Google - role: editor - - - ins: M. Thomson - name: Martin Thomson - org: Mozilla - role: editor - informative: AEBounds: @@ -104,14 +85,13 @@ code and issues list for this draft can be found at # Introduction -This document describes how QUIC {{QUIC-TRANSPORT}} is secured using -Transport Layer Security (TLS) version 1.3 {{!I-D.ietf-tls-tls13}}. TLS -1.3 provides critical latency improvements for connection establishment -over previous versions. Absent packet loss, most new connections can be -established and secured within a single round trip; on subsequent -connections between the same client and server, the client can often -send application data immediately, that is, using a zero round trip -setup. +This document describes how QUIC {{!I-D.ietf-quic-transport}} is secured using +Transport Layer Security (TLS) version 1.3 {{!I-D.ietf-tls-tls13}}. TLS 1.3 +provides critical latency improvements for connection establishment over +previous versions. Absent packet loss, most new connections can be established +and secured within a single round trip; on subsequent connections between the +same client and server, the client can often send application data immediately, +that is, using a zero round trip setup. This document describes how the standardized TLS 1.3 acts a security component of QUIC. The same design could work for TLS 1.2, though few of the @@ -125,7 +105,7 @@ The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document. It's not shouting; when they are capitalized, they have the special meaning defined in {{!RFC2119}}. -This document uses the terminology established in {{QUIC-TRANSPORT}}. +This document uses the terminology established in {{!I-D.ietf-quic-transport}}. For brevity, the acronym TLS is used to refer to TLS 1.3. @@ -139,9 +119,9 @@ data*, though in the QUIC usage there is no use of TLS application data. # Protocol Overview -QUIC {{QUIC-TRANSPORT}} assumes responsibility for the confidentiality and -integrity protection of packets. For this it uses keys derived from a TLS 1.3 -connection {{!I-D.ietf-tls-tls13}}; QUIC also relies on TLS 1.3 for +QUIC {{!I-D.ietf-quic-transport}} assumes responsibility for the confidentiality +and integrity protection of packets. For this it uses keys derived from a TLS +1.3 connection {{!I-D.ietf-tls-tls13}}; QUIC also relies on TLS 1.3 for authentication and negotiation of parameters that are critical to security and performance. @@ -261,7 +241,8 @@ document: an additional round trip prior to the basic exchange. This is needed if the server wishes to request a different key exchange key from the client. HelloRetryRequest is also used to verify that the client is correctly able to - receive packets on the address it claims to have (see {{QUIC-TRANSPORT}}). + receive packets on the address it claims to have (see + {{!I-D.ietf-quic-transport}}). * A pre-shared key mode can be used for subsequent handshakes to reduce the number of public key operations. This is the basis for 0-RTT data, even if @@ -778,7 +759,7 @@ The associated data, A, for the AEAD is the contents of the QUIC header, starting from the flags octet in either the short or long header. The input plaintext, P, for the AEAD is the content of the QUIC frame following -the header, as described in {{QUIC-TRANSPORT}}. +the header, as described in {{!I-D.ietf-quic-transport}}. The output ciphertext, C, of the AEAD is transmitted in place of P. @@ -829,8 +810,9 @@ delayed significantly. ## Packet Number Gaps {#packet-number-gaps} -Section 7.5.1.1 of {{QUIC-TRANSPORT}} also requires a secret to compute packet -number gaps on connection ID transitions. That secret is computed as: +Section 7.5.1.1 of {{!I-D.ietf-quic-transport}} also requires a secret to +compute packet number gaps on connection ID transitions. That secret is computed +as: ~~~ packet_number_secret @@ -1421,7 +1403,7 @@ protection for these values. The `extension_data` field of the quic_transport_parameters extension contains a value that is defined by the version of QUIC that is in use. The quic_transport_parameters extension carries a TransportParameters when the -version of QUIC defined in {{QUIC-TRANSPORT}} is used. +version of QUIC defined in {{!I-D.ietf-quic-transport}} is used. The quic_transport_parameters extension is carried in the ClientHello and the EncryptedExtensions messages during the handshake. The extension MAY be