Merge pull request #389 from ianswett/patch-5

Tweaks to the Extracting SNI section

draft-ietf-quic-manageability.md

@@ -634,8 +634,8 @@ and other protocols that use TLS.
 ### Extracting Server Name Indication (SNI) Information
 
 If the ClientHello is not encrypted, SNI can be derived from the client's
-Initial packet by calculating the Initial secret to decrypt the packet payload
-and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello.
+Initial packet(s) by calculating the Initial secret to decrypt the packet
+payload and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello.
 
 As both the derivation of the Initial secret and the structure of the Initial
 packet itself are version-specific, the first step is always to parse the
@@ -661,28 +661,29 @@ other than the one used to generate the Initial secret. Therefore, attempts to
 decrypt these packets using the procedure above might fail unless the Initial
 secret is retained by the observer.
 
-To determine the end of the header and find the start of the payload, the packet
-number length, the source connection ID length, and the token length need to be
-extracted. The packet number length is defined by the seventh and eight bits of
-the header as described in {{Section 17.2 of QUIC-TRANSPORT}}, but is obfuscated
-as described in {{Section 5.4 of QUIC-TLS}}. The source connection ID length is
-specified in the byte after the destination connection ID. The token length,
-which follows the source connection ID, is a variable-length integer as
-specified in {{Section 16 of QUIC-TRANSPORT}}.
-
-After decryption, the client's Initial packet can be parsed to detect the CRYPTO
-frame(s) that contains the TLS ClientHello, which then can be parsed similarly
-to TLS over TCP connections. Note that there can be multiple CRYPTO frames,
-and they might not be in order, so reassembling the CRYPTO stream by parsing
-offsets and lengths is required. Further, the client's Initial packet may
-contain other frames, so the first bytes of each frame need to be checked
-to identify the frame type, and if needed skipped over it. Note that the
-length of the frames is dependent on the frame type; see {{Section 18 of
-QUIC-TRANSPORT}}. E.g. PADDING frames, each consisting
-of a single zero byte, may occur before, after, or
-between CRYPTO frames. However, extensions might define additional frame types.
-If an unknown frame type is encountered, it is impossible to know the length of
-that frame which prevents skipping over it, and therefore parsing fails.
+To determine the end of the packet header and find the start of the payload,
+the packet number length, the source connection ID length, and the token length
+need to be extracted. The packet number length is defined by the seventh and
+eight bits of the header as described in {{Section 17.2 of QUIC-TRANSPORT}},
+but is obfuscated as described in {{Section 5.4 of QUIC-TLS}}. The source
+connection ID length is specified in the byte after the destination
+connection ID. The token length, which follows the source connection ID, is
+a variable-length integer as specified in {{Section 16 of QUIC-TRANSPORT}}.
+
+After decryption, the client's Initial packet(s) can be parsed to detect the
+CRYPTO frame(s) that contains the TLS ClientHello, which then can be parsed
+similarly to TLS over TCP connections. Note that there can be multiple CRYPTO
+frames spread out over one or mor Initial packets, and they might not be in
+order, so reassembling the CRYPTO stream by parsing offsets and lengths is
+required. Further, the client's Initial packet(s) may contain other frames,
+so the first bytes of each frame need to be checked to identify the frame
+type, and if needed skipped over it. Note that the length of the frames is
+dependent on the frame type; see {{Section 18 of QUIC-TRANSPORT}}.
+E.g. PADDING frames, each consisting of a single zero byte, may occur before,
+after, or between CRYPTO frames. However, extensions might define additional
+frame types. If an unknown frame type is encountered, it is impossible to
+know the length of that frame which prevents skipping over it, and therefore
+parsing fails.
 
 ## Flow Association {#sec-flow-association}