RPC text changes for -tls

draft-ietf-quic-tls.md

@@ -102,6 +102,45 @@ informative:
     date: 2020-05-16
     target: "https://eprint.iacr.org/2020/718"
 
+  CCM-ANALYSIS:
+    title: "On the Security of CTR + CBC-MAC"
+    author:
+      -
+        initials: J.
+        surname: Jonsson
+        name: Jakob Jonsson
+    date: 2003
+    refcontent:
+      - "Selected Areas in Cryptography"
+      - "SAC 2002"
+      - "Lecture Notes in Computer Science, vol 2595"
+      - "pp. 76-93"
+    seriesinfo:
+      DOI: 10.1007/3-540-36492-7_7
+
+  NAN:
+    title: "Nonces Are Noticed: AEAD Revisited"
+    author:
+      -
+        initials: M.
+        surname: Bellare
+        name: Mihir Bellare
+      -
+        initials: R.
+        surname: Ng
+        name: Ruth Ng
+      -
+        initials: B.
+        surname: Tackmann
+        name: Björn Tackmann
+    date: 2019
+    refcontent:
+      - "Advances in Cryptology - CRYPTO 2019"
+      - "Lecture Notes in Computer Science, vol 11692"
+      - "pp. 235-265"
+    seriesinfo:
+      DOI: 10.1007/978-3-030-26948-7_9
+
 
 --- abstract
 
@@ -661,16 +700,16 @@ verification that the identity of the server is included in a certificate and
 that the certificate is issued by a trusted entity (see for example
 {{?RFC2818}}).
 
-Note:
-
-: Where servers provide certificates for authentication, the size of the
+<aside markdown="block"><t markdown="block">
+Note: Where servers provide certificates for authentication, the size of the
   certificate chain can consume a large number of bytes.  Controlling the size
   of certificate chains is critical to performance in QUIC as servers are
   limited to sending 3 bytes for every byte received prior to validating the
   client address; see {{Section 8.1 of QUIC-TRANSPORT}}.  The size of a
   certificate chain can be managed by limiting the number of names or
   extensions; using keys with small public key representations, like ECDSA; or
   by using certificate compression {{?COMPRESS=RFC8879}}.
+</t></aside>
 
 A server MAY request that the client authenticate during the handshake. A server
 MAY refuse a connection if the client is unable to authenticate when requested.
@@ -1030,14 +1069,14 @@ server sends a Retry packet to use the connection ID value selected by the
 server.  The secrets do not change when a client changes the Destination
 Connection ID it uses in response to an Initial packet from the server.
 
-Note:
-
-: The Destination Connection ID field could be any length up to 20 bytes,
+<aside markdown="block"><t markdown="block">
+Note: The Destination Connection ID field could be any length up to 20 bytes,
   including zero length if the server sends a Retry packet with a zero-length
   Source Connection ID field. After a Retry, the Initial keys provide the client
   no assurance that the server received its packet, so the client has to rely on
   the exchange that included the Retry packet to validate the server address;
   see {{Section 8.1 of QUIC-TRANSPORT}}.
+</t></aside>
 
 {{test-vectors}} contains sample Initial packets.
 
@@ -1056,11 +1095,9 @@ a header protection scheme for all cipher suites defined in {{!TLS13}} aside
 from TLS_AES_128_CCM_8_SHA256.  These cipher suites have a 16-byte
 authentication tag and produce an output 16 bytes larger than their input.
 
-Note:
-
-: An endpoint MUST NOT reject a ClientHello that offers a cipher suite that it
-  does not support, or it would be impossible to deploy a new cipher suite.
-  This also applies to TLS_AES_128_CCM_8_SHA256.
+An endpoint MUST NOT reject a ClientHello that offers a cipher suite that it
+does not support, or it would be impossible to deploy a new cipher suite.  This
+also applies to TLS_AES_128_CCM_8_SHA256.
 
 When constructing packets, the AEAD function is applied prior to applying
 header protection; see {{header-protect}}. The unprotected packet header is part
@@ -1204,11 +1241,11 @@ The header protection algorithm uses both the header protection key and a sample
 of the ciphertext from the packet Payload field.
 
 The same number of bytes are always sampled, but an allowance needs to be made
-for the endpoint removing protection, which will not know the length of the
-Packet Number field.  The sample of ciphertext is taken starting from an offset
-of 4 bytes after the start of the Packet Number field.  That is, in sampling
-packet ciphertext for header protection, the Packet Number field is assumed to
-be 4 bytes long (its maximum possible encoded length).
+for the removal of protection by a receiving endpoint, which will not know the
+length of the Packet Number field.  The sample of ciphertext is taken starting
+from an offset of 4 bytes after the start of the Packet Number field.  That is,
+in sampling packet ciphertext for header protection, the Packet Number field is
+assumed to be 4 bytes long (its maximum possible encoded length).
 
 An endpoint MUST discard packets that are not long enough to contain a complete
 sample.
@@ -1360,13 +1397,13 @@ decrypt 0-RTT packets it receives and instead MUST discard them.
 Once a client has installed 1-RTT keys, it MUST NOT send any more 0-RTT
 packets.
 
-Note:
-
-: 0-RTT data can be acknowledged by the server as it receives it, but any
+<aside markdown="block"><t markdown="block">
+Note: 0-RTT data can be acknowledged by the server as it receives it, but any
   packets containing acknowledgments of 0-RTT data cannot have packet protection
   removed by the client until the TLS handshake is complete.  The 1-RTT keys
   necessary to remove packet protection cannot be derived until the client
   receives all server handshake messages.
+</t></aside>
 
 
 ## Receiving Out-of-Order Protected Packets {#pre-hs-protected}
@@ -1399,11 +1436,11 @@ acknowledgments for 1-RTT packets until the TLS handshake is complete.  Received
 packets protected with 1-RTT keys MAY be stored and later decrypted and used
 once the handshake is complete.
 
-Note:
-
-: TLS implementations might provide all 1-RTT secrets prior to handshake
+<aside markdown="block"><t markdown="block">
+Note: TLS implementations might provide all 1-RTT secrets prior to handshake
   completion.  Even where QUIC implementations have 1-RTT read keys, those keys
   are not to be used prior to completing the handshake.
+</t></aside>
 
 The requirement for the server to wait for the client Finished message creates
 a dependency on that message being delivered.  A client can avoid the
@@ -1558,10 +1595,10 @@ implemented by tracking the lowest packet number sent with each key phase and
 the highest acknowledged packet number in the 1-RTT space: once the latter is
 higher than or equal to the former, another key update can be initiated.
 
-Note:
-
-: Keys of packets other than the 1-RTT packets are never updated; their keys are
-  derived solely from the TLS handshake state.
+<aside markdown="block"><t markdown="block">
+Note: Keys of packets other than the 1-RTT packets are never updated; their keys
+  are derived solely from the TLS handshake state.
+</t></aside>
 
 The endpoint that initiates a key update also updates the keys that it uses for
 receiving packets.  These keys will be needed to process packets the peer sends
@@ -1615,9 +1652,9 @@ Endpoints responding to an apparent key update MUST NOT generate a timing
 side-channel signal that might indicate that the Key Phase bit was invalid (see
 {{hp-side-channel}}).  Endpoints can use randomized packet protection keys in
 place of discarded keys when key updates are not yet permitted.  Using
-randomized keys will generate no variation in the timing signal produced by
-attempting to remove packet protection, and results in all packets with an
-invalid Key Phase bit being rejected.
+randomized keys ensures that attempting to remove packet protection does not
+result in timing variations, and results in packets with an invalid Key Phase
+bit being rejected.
 
 The process of creating new packet protection keys for receiving packets could
 reveal that a key update has occurred. An endpoint MAY generate new keys as
@@ -1930,15 +1967,13 @@ states if frames are replayed, reordered, or lost.  QUIC connections do not
 produce effects that last beyond the lifetime of the connection, except for
 those produced by the application protocol that QUIC serves.
 
-Important:
-
-: TLS session tickets and address validation tokens are used to carry QUIC
-  configuration information between connections, specifically to enable a server
-  to efficiently recover state that is used in connection establishment and
-  address validation.  These MUST NOT be used to communicate application
-  semantics between endpoints; clients MUST treat them as opaque values.  The
-  potential for reuse of these tokens means that they require stronger
-  protections against replay.
+TLS session tickets and address validation tokens are used to carry QUIC
+configuration information between connections, specifically, to enable a server
+to efficiently recover state that is used in connection establishment and
+address validation.  These MUST NOT be used to communicate application semantics
+between endpoints; clients MUST treat them as opaque values.  The potential for
+reuse of these tokens means that they require stronger protections against
+replay.
 
 A server that accepts 0-RTT on a connection incurs a higher cost than accepting
 a connection without 0-RTT.  This includes higher processing and computation
@@ -1976,7 +2011,7 @@ limit the level of amplification.
 
 ## Header Protection Analysis {#header-protect-analysis}
 
-{{?NAN=DOI.10.1007/978-3-030-26948-7_9}} analyzes authenticated encryption
+{{NAN}} analyzes authenticated encryption
 algorithms that provide nonce privacy, referred to as "Hide Nonce" (HN)
 transforms. The general header protection construction in this document is
 one of those algorithms (HN1). Header protection is applied after the packet
@@ -2514,19 +2549,19 @@ for AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires limits
 on use that ensure that both confidentiality and integrity are preserved. This
 section documents that analysis.
 
-{{?CCM-ANALYSIS=DOI.10.1007/3-540-36492-7_7}} is used as the basis of this
+{{CCM-ANALYSIS}} is used as the basis of this
 analysis. The results of that analysis are used to derive usage limits that are
 based on those chosen in {{?TLS13}}.
 
-For confidentiality, Theorem 2 in {{?CCM-ANALYSIS}} establishes that an attacker
+For confidentiality, Theorem 2 in {{CCM-ANALYSIS}} establishes that an attacker
 gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of
 no more than the following:
 
 ~~~
 (2l * q)^2 / 2^n
 ~~~
 
-The integrity limit in Theorem 1 in {{?CCM-ANALYSIS}} provides an attacker a
+The integrity limit in Theorem 1 in {{CCM-ANALYSIS}} provides an attacker a
 strictly higher advantage for the same number of messages. As the targets for
 the confidentiality advantage and the integrity advantage are the same, only
 Theorem 1 needs to be considered.