Cleanup text.

3 files changed, 12 insertions, 11 deletions

diff --git a/noise.md b/noise.md
index a5c93bc..1ba0cbf 100644
--- a/noise.md
+++ b/noise.md
@@ -1535,8 +1535,9 @@ Note that rekey only updates the cipherstate's `k` value, it doesn't reset the c
 
 In some use cases, Noise transport messages might be lost or arrive
 out-of-order (e.g. when messages are sent over UDP).  To handle this, an
-application protocol can attach the `n` value to each message, and recipients
-can call the `SetNonce()` function on the receiving `CipherState` using the
+application protocol can send the `n` value used for encrypting each transport
+message alongside that message.  On receiving such a message the recipient
+would call the `SetNonce()` function on the receiving `CipherState` using the
 received nonce.  Recipients doing this must track the received `n` values and
 reject repeated values to prevent replay attacks.
 
@@ -1682,14 +1683,14 @@ An application built on Noise must consider several issues:
 
 This section collects various security considerations:
 
- * **Authentication**:  A Noise protocol with static public keys checks that
+ * **Authentication**:  A Noise protocol with static public keys verifies that
    the corresponding private keys are possessed by the participant(s), but it's
-   up to the application to authenticate that the public keys are correct.
-   Methods for doing so include certificates which sign the public key (and
-   which may be passed in handshake payloads), preconfigured lists of public
-   keys, or "pinning" / "key-continuity" approaches where parties remember
-   public keys they encounter and check whether the same party presents the
-   same public key in the future.
+   up to the application to determine whether the remote party's static public
+   key is acceptable.  Methods for doing so include certificates which sign the
+   public key (and which may be passed in handshake payloads), preconfigured
+   lists of public keys, or "pinning" / "key-continuity" approaches where
+   parties remember public keys they encounter and check whether the same party
+   presents the same public key in the future.
 
  * **Session termination**:  Preventing attackers from truncating a stream of
    transport messages is an application responsibility.  See previous section.
diff --git a/output/noise.html b/output/noise.html
index 79631a4..6cfd3fb 100644
--- a/output/noise.html
+++ b/output/noise.html
@@ -1068,7 +1068,7 @@ Noise_IK(s, rs):
 <p>Applications must make these decisions on their own; there are no modifiers which specify rekey behavior.</p>
 <p>Note that rekey only updates the cipherstate's <code>k</code> value, it doesn't reset the cipherstate's <code>n</code> value, so applications performing rekey must still perform a new handshake if sending 2<sup>64</sup> or more transport messages.</p>
 <h2 id="out-of-order-nonces">11.4. Out-of-order nonces</h2>
-<p>In some use cases, Noise transport messages might be lost or arrive out-of-order (e.g. when messages are sent over UDP). To handle this, an application protocol can attach the <code>n</code> value to each message, and recipients can call the <code>SetNonce()</code> function on the receiving <code>CipherState</code> using the received nonce. Recipients doing this must track the received <code>n</code> values and reject repeated values to prevent replay attacks.</p>
+<p>In some use cases, Noise transport messages might be lost or arrive out-of-order (e.g. when messages are sent over UDP). To handle this, an application protocol can send the <code>n</code> value used for encrypting each transport message alongside that message, and recipients can call the <code>SetNonce()</code> function on the receiving <code>CipherState</code> using the received nonce. Recipients doing this must track the received <code>n</code> values and reject repeated values to prevent replay attacks.</p>
 <h2 id="half-duplex-protocols">11.5. Half-duplex protocols</h2>
 <p>In some application protocols the parties strictly alternate sending messages. In this case Noise can be used in a &quot;half-duplex&quot; mode <span class="citation">[<a href="#ref-blinker">6</a>]</span> where the first <code>CipherState</code> returned by <code>Split()</code> is used for encrypting messages in both directions. This provides a small optimization, since <code>Split()</code> only has to output a single <code>CipherState</code>, and both parties only need to store a single <code>CipherState</code> during the transport phase.</p>
 <p>This feature must be used with extreme caution. In particular, it would be a catastrophic security failure if the protocol is not strictly alternating and both parties encrypt different messages using the same <code>CipherState</code> and nonce value.</p>
@@ -1133,7 +1133,7 @@ Noise_IK(s, rs):
 <h1 id="security-considerations">14. Security considerations</h1>
 <p>This section collects various security considerations:</p>
 <ul>
-<li><p><strong>Authentication</strong>: A Noise protocol with static public keys checks that the corresponding private keys are possessed by the participant(s), but it's up to the application to authenticate that the public keys are correct. Methods for doing so include certificates which sign the public key (and which may be passed in handshake payloads), preconfigured lists of public keys, or &quot;pinning&quot; / &quot;key-continuity&quot; approaches where parties remember public keys they encounter and check whether the same party presents the same public key in the future.</p></li>
+<li><p><strong>Authentication</strong>: A Noise protocol with static public keys verifies that the corresponding private keys are possessed by the participant(s), but it's up to the application to determine whether the remote party's static public key is acceptable. Methods for doing so include certificates which sign the public key (and which may be passed in handshake payloads), preconfigured lists of public keys, or &quot;pinning&quot; / &quot;key-continuity&quot; approaches where parties remember public keys they encounter and check whether the same party presents the same public key in the future.</p></li>
 <li><p><strong>Session termination</strong>: Preventing attackers from truncating a stream of transport messages is an application responsibility. See previous section.</p></li>
 <li><p><strong>Rollback</strong>: If parties decide on a Noise protocol based on some previous negotiation that is not included as prologue, then a rollback attack might be possible. This is a particular risk with fallback handshakes, and requires careful attention if a Noise handshake is preceded by communication between the parties.</p></li>
 <li><p><strong>Misusing public keys as secrets</strong>: It might be tempting to use a pattern with a pre-message public key and assume that a successful handshake implies the other party's knowledge of the public key. Unfortunately, this is not the case, since setting public keys to invalid values might cause predictable DH output. For example, a <code>Noise_NK_25519</code> initiator might send an invalid ephemeral public key to cause a known DH output of all zeros, despite not knowing the responder's static public key. If the parties want to authenticate with a shared secret, it should be used as a PSK.</p></li>
diff --git a/output/noise.pdf b/output/noise.pdf
index e3b9f9b..6fa82e6 100644
--- a/output/noise.pdf
+++ b/output/noise.pdf