From 83c3971625eb2ee210d6777ee90bd786fcb12adc Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 1 Aug 2018 10:51:38 +1000 Subject: [PATCH 1/2] Fix broken references from transport draft, fixes #1618. --- draft-ietf-quic-transport.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bcbc9fe630..89e23b4b06 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -348,7 +348,7 @@ Packet Number: : The packet number field is 1, 2, or 4 octets long. The packet number has confidentiality protection separate from packet protection, as described - in Section 5.6 of {{QUIC-TLS}}. The length of the packet number field is + in Section 5.3 of {{QUIC-TLS}}. The length of the packet number field is encoded in the plaintext packet number. See {{packet-numbers}} for details. Payload: @@ -459,7 +459,7 @@ Packet Number: : The packet number field is 1, 2, or 4 octets long. The packet number has confidentiality protection separate from packet protection, as described in - Section 5.6 of {{QUIC-TLS}}. The length of the packet number field is encoded + Section 5.3 of {{QUIC-TLS}}. The length of the packet number field is encoded in the plaintext packet number. See {{packet-numbers}} for details. Protected Payload: @@ -874,7 +874,8 @@ connection ID to vary in length and still be used by the load balancer. The very first packet sent by a client includes a random value for Destination Connection ID. The same value MUST be used for all 0-RTT packets sent on that connection ({{packet-protected}}). This randomized value is used to determine -the handshake packet protection keys (see Section 5.3.2 of {{QUIC-TLS}}). +the packet protection keys for Initial packets (see Section 5.1.1 of +{{QUIC-TLS}}). A Version Negotiation ({{packet-version}}) packet MUST use both connection IDs selected by the client, swapped to ensure correct routing toward the client. @@ -935,7 +936,7 @@ number are provided, as shown in {{pn-encodings}}. Note that these encodings are similar to those in {{integer-encoding}}, but use different values. -The encoded packet number is protected as described in Section 5.6 +The encoded packet number is protected as described in Section 5.3 {{QUIC-TLS}}. Protection of the packet number is removed prior to recovering the full packet number. The full packet number is reconstructed at the receiver based on the number of significant bits present, the content of those @@ -1408,7 +1409,7 @@ handling. The format of the transport parameters is the TransportParameters struct from {{figure-transport-parameters}}. This is described using the presentation -language from Section 3 of {{!I-D.ietf-tls-tls13}}. +language from Section 3 of {{!TLS13=I-D.ietf-tls-tls13}}. ~~~ uint32 QuicVersion; @@ -3285,8 +3286,7 @@ messages are delayed or lost. Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. Endpoints SHOULD send acknowledgments for packets containing CRYPTO frames with -a reduced delay; see Section 3.5.1 of {{QUIC-RECOVERY}}. - +a reduced delay; see Section 4.3.1 of {{QUIC-RECOVERY}}. ## ACK_ECN Frame {#frame-ack-ecn} From 35c83e767faa2da3d524308c58e96634217754ce Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 1 Aug 2018 10:56:44 +1000 Subject: [PATCH 2/2] Fix broken references from tls draft, fixes #1617. --- draft-ietf-quic-tls.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 0b27733a43..b10c2931ab 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -351,7 +351,7 @@ UDP datagram. | Short Header | 1-RTT | 0/1-RTT | {: #packet-types-levels title="Encryption Levels by Packet Type"} -Section 6.3 of {{QUIC-TRANSPORT}} shows how packets at the various encryption +Section 6.5 of {{QUIC-TRANSPORT}} shows how packets at the various encryption levels fit into the handshake process. ## Interface to TLS @@ -598,14 +598,14 @@ can be used to correct a client's incorrect KeyShare extension as well as for a stateless round-trip check. From the perspective of QUIC, this just looks like additional messages carried in the Initial encryption level. Although it is in principle possible to use this feature for address verification in QUIC, QUIC -implementations SHOULD instead use the Retry feature (see Section 4.4.2 of +implementations SHOULD instead use the Retry feature (see Section 4.4 of {{QUIC-TRANSPORT}}). HelloRetryRequest is still used to request key shares. ## TLS Errors If TLS experiences an error, it generates an appropriate alert as defined in -Section 6 of {{TLS13}}. +Section 6 of {{!TLS13}}. A TLS alert is turned into a QUIC connection error by converting the one-octet alert description into a QUIC error code. The alert description is added to @@ -631,11 +631,12 @@ traffic keys using as described in Section 7.3 of {{!TLS13}} The keys for the Initial encryption level are computed based on the client's initial Destination Connection ID, as described in {{initial-secrets}}. -The keys for the remaining encryption level are computed in the same fashion as -the corresponding TLS keys (see Section 7 of {{!TLS13}}), except that the label -for HKDF-Expand-Label uses the prefix "quic " rather than "tls13 ". A different +The keys for other encryption levels are computed in the same fashion as the +corresponding TLS keys (see Section 7 of {{!TLS13}}), except that the label for +HKDF-Expand-Label uses the prefix "quic " rather than "tls13 ". A different label provides key separation between TLS and QUIC. + ### Initial Secrets {#initial-secrets} Initial packets are protected with a secret derived from the Destination @@ -766,7 +767,7 @@ protection algorithms MUST NOT sample more ciphertext than the minimum expansion of the corresponding AEAD. Packet number protection is applied to the packet number encoded as described in -Section 4.8 of {{QUIC-TRANSPORT}}. Since the length of the packet number is +Section 4.11 of {{QUIC-TRANSPORT}}. Since the length of the packet number is stored in the first octet of the encoded packet number, it may be necessary to progressively decrypt the packet number. @@ -895,10 +896,11 @@ cannot be used until the endpoint has received and successfully decrypted a packet with a matching KEY_PHASE. A receiving endpoint detects an update when the KEY_PHASE bit doesn't match what -it is expecting. It creates a new secret (see Section 7.2 of {{TLS13}}) and the -corresponding read key and IV. If the packet can be decrypted and authenticated -using these values, then the keys it uses for packet protection are also -updated. The next packet sent by the endpoint will then use the new keys. +it is expecting. It creates a new secret (see Section 7.2 of {{!TLS13}}) and +the corresponding read key and IV. If the packet can be decrypted and +authenticated using these values, then the keys it uses for packet protection +are also updated. The next packet sent by the endpoint will then use the new +keys. An endpoint doesn't need to send packets immediately when it detects that its peer has updated keys. The next packet that it sends will simply use the new @@ -1041,10 +1043,10 @@ by an attacker. QUIC includes three defenses against this attack. First, the packet containing a ClientHello MUST be padded to a minimum size. Second, if responding to an unverified source address, the server is forbidden to send more than three UDP -datagrams in its first flight (see Section 4.4.3 of -{{QUIC-TRANSPORT}}). Finally, because acknowledgements of Handshake packets are -authenticated, a blind attacker cannot forge them. Put together, these defenses -limit the level of amplification. +datagrams in its first flight (see Section 4.7 of {{QUIC-TRANSPORT}}). Finally, +because acknowledgements of Handshake packets are authenticated, a blind +attacker cannot forge them. Put together, these defenses limit the level of +amplification. ## Peer Denial of Service {#useless}