diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index c72ec08378..b8ebc9d462 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -331,9 +331,9 @@ only appear in the 0-RTT and 1-RTT encryption levels - CONNECTION_CLOSE and CRYPTO_CLOSE MAY appear in packets of any encryption level other than 0-RTT. - PADDING and PING frames MAY appear in packets of any encryption level. -- ACK frames MAY appear in packets of any encryption level, but - can only acknowledge packets which appeared in that encryption - level. +- ACK frames MAY appear in packets of any encryption level other than + 0-RTT, but can only acknowledge packets which appeared in that + encryption level. - STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels. - All other frame types MUST only appear at the 1-RTT levels. @@ -676,10 +676,10 @@ QUIC packets are protected prior to applying packet number encryption (A). When removing packet protection, an endpoint first removes the protection from the packet number. -All QUIC packets other than Version Negotiation and Stateless Reset +All QUIC packets other than Version Negotiation and Retry packets are protected with an AEAD algorithm {{!AEAD}}. Prior to establishing a shared secret, packets are protected with -AEAD_AES_128_GCM and a key derived from the from the destination +AEAD_AES_128_GCM and a key derived from the destination connection ID in the client's first Initial packet (see {{initial-secrets}}). This provides protection against off-path attackers and robustness against QUIC version unaware middleboxes, but diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4d87b8cd6e..8ba75cf9fe 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -551,10 +551,10 @@ provides some level of protection against off-path attackers. ### Initial Packet {#packet-initial} The Initial packet uses long headers with a type value of 0x7F. It -carries the first CRYPTO_HS frames sent by the client as well as the -cryptographic messages sent by the server to perform key exchange, and -may carry ACKs in either direction. The Initial packet is protected by -Initial keys as described in {{QUIC-TLS}}. +carries the first CRYPTO_HS frames sent by the client and server to +perform key exchange, and may carry ACKs in either direction. The +Initial packet is protected by Initial keys as described in +{{QUIC-TLS}}. The Initial packet has two additional header fields that follow the normal Long Header. @@ -582,7 +582,7 @@ NEW_TOKEN frame. The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. In addition to -the first packet(s), This includes all cases where a new packet +the first packet(s). This includes all cases where a new packet containing the initial cryptographic message needs to be created, such as the packets sent after receiving a Version Negotiation ({{packet-version}}) or Retry packet ({{packet-retry}}). @@ -592,7 +592,7 @@ server may send multiple Initial packets. The cryptographic key exchange could require multiple round trips or retransmissions of this data. The payload of an Initial packet includes a CRYPTO_HS frame (or -frames), containing a cryptographic handshake message, ACK frames, or +frames) containing a cryptographic handshake message, ACK frames, or both. The first CRYPTO_HS frame sent always begins at an offset of 0 (see {{handshake}}). The client's complete first message MUST fit in a single packet (see {{handshake}}). Note that if the server sends a @@ -608,7 +608,7 @@ Connection ID field with an unpredictable value. This MUST be at least 8 octets in length. Until a packet is received from the server, the client MUST use the same value unless it abandons the connection attempt and starts a new one. The initial Destination Connection ID is -used to determine packet protection keys. +used to determine packet protection keys for Initial packets. The client populates the Source Connection ID field with a value of its choosing and sets the SCIL field to match. @@ -807,8 +807,8 @@ A sender can coalesce multiple QUIC packets (typically a Cryptographic Handshake packet and a Protected packet) into one UDP datagram. This can reduce the number of UDP datagrams needed to send application data during the handshake and immediately afterwards. It is not necessary for senders to coalesce -packets -- though failing to do so will require sending a significantly -larger number of packets during the handshake -- but receivers MUST +packets, though failing to do so will require sending a significantly +larger number of datagrams during the handshake. Receivers MUST be able to process coalesced packets. Senders SHOULD coalesce packets in order of increasing encryption levels @@ -3207,7 +3207,7 @@ frame offers the cryptographic protocol an in-order stream of bytes. CRYPTO_HS frames are functionally identical to STREAM frames, except that they do not bear a stream identifier; they are not flow controlled; and they do not carry markers for optional offset, -optional, length, and the end of the stream. +optional length, and the end of the stream. A CRYPTO_HS frame is shown below.