Script updating gh-pages from 3836d2e. [ci skip]

draft-ietf-quic-tls.html

@@ -623,7 +623,7 @@ <h2 id="rfc.section.2.1">
 <p></p>
 
 <ul>
-<li>Plaintext</li>
+<li>Initial Keys</li>
 <li>Early Data (0-RTT) Keys</li>
 <li>Handshake Keys</li>
 <li>Application Data (1-RTT) Keys</li>
@@ -899,7 +899,7 @@ <h2 id="rfc.section.5.1">
 </h2>
 <p id="rfc.section.5.1.p.1">QUIC derives packet protection keys in the same way that TLS derives record protection keys.</p>
 <p id="rfc.section.5.1.p.2">Each encryption level has separate secret values for protection of packets sent in each direction.  These traffic secrets are derived by TLS (see Section 7.1 of <a href="#TLS13" class="xref">[TLS13]</a>) and are used by QUIC for all encryption levels except the Initial encryption level.  The secrets for the Initial encryption level are computed based on the client&#8217;s initial Destination Connection ID, as described in <a href="#initial-secrets" class="xref">Section 5.2</a>.</p>
-<p id="rfc.section.5.1.p.3">The keys used for packet protection are computed from the TLS secrets using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of <a href="#TLS13" class="xref">[TLS13]</a> is used, using the hash function from the negotiated cipher suite.  Other versions of TLS MUST provide a similar function in order to be used QUIC.</p>
+<p id="rfc.section.5.1.p.3">The keys used for packet protection are computed from the TLS secrets using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of <a href="#TLS13" class="xref">[TLS13]</a> is used, using the hash function from the negotiated cipher suite.  Other versions of TLS MUST provide a similar function in order to be used with QUIC.</p>
 <p id="rfc.section.5.1.p.4">The current encryption level secret and the label &#8220;quic key&#8221; are input to the KDF to produce the AEAD key; the label &#8220;quic iv&#8221; is used to derive the IV, see <a href="#aead" class="xref">Section 5.3</a>.  The header protection key uses the &#8220;quic hp&#8221; label, see <a href="#header-protect" class="xref">Section 5.4</a>.  Using these labels provides key separation between QUIC and TLS, see <a href="#key-diversity" class="xref">Section 9.4</a>.</p>
 <p id="rfc.section.5.1.p.5">The KDF used for initial secrets is always the HKDF-Expand-Label function from TLS 1.3 (see <a href="#initial-secrets" class="xref">Section 5.2</a>).</p>
 <h2 id="rfc.section.5.2">
@@ -920,7 +920,7 @@ <h2 id="rfc.section.5.2">
 </pre>
 <p id="rfc.section.5.2.p.2">The hash function for HKDF when deriving initial secrets and keys is SHA-256 <a href="#SHA" class="xref">[SHA]</a>.</p>
 <p id="rfc.section.5.2.p.3">The connection ID used with HKDF-Expand-Label is the Destination Connection ID in the Initial packet sent by the client.  This will be a randomly-selected value unless the client creates the Initial packet after receiving a Retry packet, where the Destination Connection ID is selected by the server.</p>
-<p id="rfc.section.5.2.p.4">The value of initial_salt is a 20 byte sequence shown in the figure in hexadecimal notation. Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC. This prevents a middlebox that only recognizes one version of QUIC from seeing or modifying the contents of handshake packets from future versions.</p>
+<p id="rfc.section.5.2.p.4">The value of initial_salt is a 20 byte sequence shown in the figure in hexadecimal notation. Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC. This prevents a middlebox that only recognizes one version of QUIC from seeing or modifying the contents of packets from future versions.</p>
 <p id="rfc.section.5.2.p.5">The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include TLS 1.3.</p>
 <p><a href="#test-vectors-initial" class="xref">Appendix A</a> contains test vectors for the initial packet encryption.</p>
 <p></p>
@@ -1126,7 +1126,7 @@ <h2 id="rfc.section.8.2">
       quic_transport_parameters(0xffa5), (65535)
    } ExtensionType;
 </pre>
-<p id="rfc.section.8.2.p.3">The <samp>extension_data</samp> 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 <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a> is used.</p>
+<p id="rfc.section.8.2.p.3">The <samp>extension_data</samp> 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 struct when the version of QUIC defined in <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a> is used.</p>
 <p id="rfc.section.8.2.p.4">The quic_transport_parameters extension is carried in the ClientHello and the EncryptedExtensions messages during the handshake.</p>
 <p id="rfc.section.8.2.p.5">While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the handshake completes, and reliance on them should be minimized.  However, any tampering with the parameters will cause the handshake to fail.</p>
 <p id="rfc.section.8.2.p.6">Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in <a href="#TLS13" class="xref">[TLS13]</a>).  A fatal unsupported_extension alert MUST be sent if this extension is received when the transport is not QUIC.</p>

draft-ietf-quic-tls.txt

@@ -282,7 +282,7 @@ Thomson & Turner         Expires August 15, 2019                [Page 5]
 Internet-Draft                QUIC over TLS                February 2019
 
 
-   o  Plaintext
+   o  Initial Keys
 
    o  Early Data (0-RTT) Keys
 
@@ -975,7 +975,7 @@ Internet-Draft                QUIC over TLS                February 2019
    using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
    function described in Section 7.1 of [TLS13] is used, using the hash
    function from the negotiated cipher suite.  Other versions of TLS
-   MUST provide a similar function in order to be used QUIC.
+   MUST provide a similar function in order to be used with QUIC.
 
    The current encryption level secret and the label "quic key" are
    input to the KDF to produce the AEAD key; the label "quic iv" is used
@@ -1023,8 +1023,8 @@ Internet-Draft                QUIC over TLS                February 2019
    in hexadecimal notation.  Future versions of QUIC SHOULD generate a
    new salt value, thus ensuring that the keys are different for each
    version of QUIC.  This prevents a middlebox that only recognizes one
-   version of QUIC from seeing or modifying the contents of handshake
-   packets from future versions.
+   version of QUIC from seeing or modifying the contents of packets from
+   future versions.
 
    The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
    Initial packets even where the TLS versions offered do not include
@@ -1573,7 +1573,7 @@ Internet-Draft                QUIC over TLS                February 2019
    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
+   TransportParameters struct when the version of QUIC defined in
    [QUIC-TRANSPORT] is used.
 
    The quic_transport_parameters extension is carried in the ClientHello