Script updating gh-pages from 0bb2046. [ci skip]

0rtt-reset/draft-ietf-quic-tls.html

@@ -698,7 +698,7 @@ <h1 id="rfc.section.4">
 <li>ACK frames MAY appear in packets of any encryption level other than 0-RTT, but can only acknowledge packets which appeared in that packet number space.</li>
 <li>All other frame types MUST only be sent in the 0-RTT and 1-RTT levels.</li>
 </ul>
-<p id="rfc.section.4.p.5">Note that it is not possible to send some frames in 0-RTT for various reasons.  In addition to ACK, this includes CRYPTO, NEW_TOKEN, PATH_RESPONSE, and RETIRE_CONNECTION_ID.</p>
+<p id="rfc.section.4.p.5">Note that it is not possible to send the following frames in 0-RTT for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and RETIRE_CONNECTION_ID.</p>
 <p id="rfc.section.4.p.6">Because packets could be reordered on the wire, QUIC uses the packet type to indicate which level a given packet was encrypted under, as shown in <a href="#packet-types-levels" class="xref">Table 1</a>. When multiple packets of different encryption levels need to be sent, endpoints SHOULD use coalesced packets to send them in the same UDP datagram.</p>
 <div id="rfc.table.1"></div>
 <div id="packet-types-levels"></div>
@@ -1152,7 +1152,7 @@ <h2 id="rfc.section.9.1">
 <p id="rfc.section.9.1.p.4">However, this does not count for costs that endpoints might incur as a result of accepting 0-RTT.  A server that accepts 0-RTT is exposed to the cost of handling a new connection, plus the cost of processing 0-RTT packets.  If replay protections are unable to prevent multiple connections from being initiated, this could increase these costs because attackers can send copies of 0-RTT packets to different server instances, causing the processing to be repeated.  Servers MUST ensure that they account for any increase in costs before accepting connections or 0-RTT.</p>
 <p id="rfc.section.9.1.p.5">Ultimately, the responsibility for managing the risks of replay attacks with 0-RTT lies with an application protocol.  An application protocol that uses QUIC MUST describe how the protocol uses 0-RTT and the measures that are employed to protect against replay attack.  Disabling 0-RTT entirely is the most effective strategy.</p>
 <p id="rfc.section.9.1.p.6">In the core protocol, particular attention needs to be paid to STREAM frames, which carry application data.  If another frame type carries, or could carry, application semantics, then the risk from replay attack needs to be considered.  For instance, though this is likely to be inadvisable, an application that attached semantics to increases in flow control credit or stream cancellation would need to assess whether those uses were vulnerable to replay attack.</p>
-<p id="rfc.section.9.1.p.7">Extensions to QUIC might create an additional exposure to replay attack if they are used by application protocols.  QUIC extensions SHOULD describe how replay attacks affects their operation.  Application protocols MUST either prohibit the use of extensions in 0-RTT or provide replay mitigation strategies for those extensions that can be used.</p>
+<p id="rfc.section.9.1.p.7">Extensions to QUIC might create an additional exposure to replay attack if they are used by application protocols.  QUIC extensions SHOULD describe how replay attacks affects their operation.  Application protocols MUST either prohibit the use of any extensions that carry application semantics in 0-RTT or provide replay mitigation strategies.</p>
 <h2 id="rfc.section.9.2">
 <a href="#rfc.section.9.2">9.2.</a> <a href="#reflection" id="reflection">Packet Reflection Attack Mitigation</a>
 </h2>

0rtt-reset/draft-ietf-quic-tls.txt

@@ -418,9 +418,9 @@ Internet-Draft                QUIC over TLS                February 2019
    o  All other frame types MUST only be sent in the 0-RTT and 1-RTT
       levels.
 
-   Note that it is not possible to send some frames in 0-RTT for various
-   reasons.  In addition to ACK, this includes CRYPTO, NEW_TOKEN,
-   PATH_RESPONSE, and RETIRE_CONNECTION_ID.
+   Note that it is not possible to send the following frames in 0-RTT
+   for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
+   RETIRE_CONNECTION_ID.
 
    Because packets could be reordered on the wire, QUIC uses the packet
    type to indicate which level a given packet was encrypted under, as
@@ -1666,9 +1666,9 @@ Internet-Draft                QUIC over TLS                February 2019
    Extensions to QUIC might create an additional exposure to replay
    attack if they are used by application protocols.  QUIC extensions
    SHOULD describe how replay attacks affects their operation.
-   Application protocols MUST either prohibit the use of extensions in
-   0-RTT or provide replay mitigation strategies for those extensions
-   that can be used.
+   Application protocols MUST either prohibit the use of any extensions
+   that carry application semantics in 0-RTT or provide replay
+   mitigation strategies.