Cleanup fallback / switch text

3 files changed, 31 insertions, 55 deletions

diff --git a/noise.md b/noise.md
index 8481247..aa5668d 100644
--- a/noise.md
+++ b/noise.md
@@ -1494,9 +1494,9 @@ handshake as if Alice had sent an `XX` initial message instead of an `IK` initia
 
 The `fallback` modifier converts an Alice-initiated pattern to a Bob-initiated
 pattern by converting Alice's initial message to a pre-message that Bob must
-receive through some other means (e.g. as the initial field in an initial
-`IK` message from Alice).  After this conversion, the rest of the handshake pattern
-is interpreted as a Bob-initiated handshake pattern.
+receive through some other means (e.g. via an initial `IK` message from Alice).
+After this conversion, the rest of the handshake pattern is interpreted as a
+Bob-initiated handshake pattern.
 
 For example, here is the `fallback` modifier applied to `XX` to produce `XXfallback`:
 
@@ -1516,43 +1516,32 @@ For example, here is the `fallback` modifier applied to `XX` to produce `XXfallb
 
 Note that `fallback` can only be applied to handshake patterns in Alice-initiated form where Alice's first message is capable of being interpreted as a pre-message (i.e. it must be either `"e"`, `"s"`, or `"e, s"`).
 
-## 10.3. Indicating fallback
+## 10.3. Zero-RTT and Noise protocols
 
 A typical compound protocol for zero-RTT encryption involves three different Noise protocols:
 
- * A **full handshake** is used if Alice doesn't possess stored information about Bob that would enable zero-RTT encryption, or doesn't wish to use the zero-RTT handshake.
+ * A **full protocol** is used if Alice doesn't possess stored information about Bob that would enable zero-RTT encryption, or doesn't wish to use the zero-RTT handshake.
 
- * A **zero-RTT handshake** allows encryption of data in the initial message.
+ * A **zero-RTT protocol** allows encryption of data in the initial message.
 
- * A **fallback handshake** is triggered by Bob if he can't decrypt Alice's first zero-RTT handshake message.
+ * A **switch protocol** is triggered by Bob if he can't decrypt Alice's first zero-RTT handshake message.
 
-There must be some way for Bob to distinguish full versus zero-RTT handshakes on receiving the first message.  If Alice makes a zero-RTT attempt, there must be some way for her to distinguish zero-RTT from fallback handshakes on receiving the response.
+There must be some way for Bob to distinguish the full versus zero-RTT cases
+on receiving the first message.  If Alice makes a zero-RTT attempt, there must
+be some way for her to distinguish the zero-RTT versus switch cases on receiving
+the response.
 
-For example, each handshake message could be preceded by a `type` byte (see
-[Section 13](#application-responsibilities)).  This byte is not part of the
-Noise message proper, but signals which handshake is being used:
-
- * If `type == 0` in Alice's first message then she is performing a full
-   handshake.
-
- * If `type == 1` in Alice's first message then she is performing a zero-RTT
-   handshake.
-
- * If `type == 0` in the response then the zero-RTT message was accepted.
-
- * If `type == 1` in the response then Bob failed to decrypt
-   Alice's zero-RTT message and is performing a fallback handshake.
-
-Note that the `type` byte doesn't need to be explicitly authenticated (either as
-prologue, or as "associated data" in the AEAD encryption), since it's implicitly authenticated if the
-message is processed succesfully.
+For example, each handshake message could be preceded by some negotiation data,
+such as a `type` byte (see [Section 13](#application-responsibilities)).  This
+data is not part of the Noise message proper, but signals which Noise protocol
+is being used.
 
 ## 10.4. Noise Pipes
 
-This section defines the **Noise Pipe** compound protocol.  These handshake patterns
-satisfy the full, zero-RTT, and fallback roles discussed in the previous
-section, so can be used to provide a full handshake with a simple zero-RTT
-option:
+This section defines the **Noise Pipe** compound protocol.  The following
+handshake patterns satisfy the full, zero-RTT, and switch roles discussed in
+the previous section, so can be used to provide a full handshake with a simple
+zero-RTT option:
 
     XX:  
       -> e
@@ -1577,10 +1566,8 @@ public key.
 
 The `IK` pattern is used for a **zero-RTT handshake**.  
 
-The `XXfallback` pattern is used for a **fallback handshake** if Bob fails to
-decrypt the first `IK` message (perhaps due to having changed his static key).
-
-\newpage
+The `XXfallback` pattern is used for a **switch handshake** if Bob fails to
+decrypt an initial `IK` message (perhaps due to having changed his static key).
 
 ## 10.5. Handshake indistinguishability
 
@@ -1612,8 +1599,6 @@ if the eavesdropper can't distinguish the different handshakes.  To make the
 ephemerals indistinguishable from random byte sequences, techniques like
 Elligator [@elligator] could be used.
 
-\newpage
-
 # 11. Advanced features
 
 ## 11.1. Dummy keys
diff --git a/output/noise.html b/output/noise.html
index 9cf378d..519d19e 100644
--- a/output/noise.html
+++ b/output/noise.html
@@ -62,7 +62,7 @@
 <li><a href="#compound-protocols">10. Compound protocols</a><ul>
 <li><a href="#rationale-for-compound-protocols">10.1. Rationale for compound protocols</a></li>
 <li><a href="#the-fallback-modifier">10.2. The <code>fallback</code> modifier</a></li>
-<li><a href="#indicating-fallback">10.3. Indicating fallback</a></li>
+<li><a href="#zero-rtt-and-noise-protocols">10.3. Zero-RTT and Noise protocols</a></li>
 <li><a href="#noise-pipes">10.4. Noise Pipes</a></li>
 <li><a href="#handshake-indistinguishability">10.5. Handshake indistinguishability</a></li>
 </ul></li>
@@ -1113,7 +1113,7 @@ KK:
 <p>Noise Pipes support the <code>XX</code> pattern, but also allow Alice to cache Bob's static public key and attempt an <code>IK</code> handshake with 0-RTT encryption.</p>
 <p>In case Bob can't decrypt Alice's initial <code>IK</code> message, he will switch to the <code>XXfallback</code> pattern, which essentially allows the parties to complete an <code>XX</code> handshake as if Alice had sent an <code>XX</code> initial message instead of an <code>IK</code> initial message.</p>
 <h2 id="the-fallback-modifier">10.2. The <code>fallback</code> modifier</h2>
-<p>The <code>fallback</code> modifier converts an Alice-initiated pattern to a Bob-initiated pattern by converting Alice's initial message to a pre-message that Bob must receive through some other means (e.g. as the initial field in an initial <code>IK</code> message from Alice). After this conversion, the rest of the handshake pattern is interpreted as a Bob-initiated handshake pattern.</p>
+<p>The <code>fallback</code> modifier converts an Alice-initiated pattern to a Bob-initiated pattern by converting Alice's initial message to a pre-message that Bob must receive through some other means (e.g. via an initial <code>IK</code> message from Alice). After this conversion, the rest of the handshake pattern is interpreted as a Bob-initiated handshake pattern.</p>
 <p>For example, here is the <code>fallback</code> modifier applied to <code>XX</code> to produce <code>XXfallback</code>:</p>
 
 <p> </p>
@@ -1128,24 +1128,17 @@ XXfallback:
   &lt;- e, ee, s, es
   -&gt; s, se</code></pre>
 <p>Note that <code>fallback</code> can only be applied to handshake patterns in Alice-initiated form where Alice's first message is capable of being interpreted as a pre-message (i.e. it must be either <code>&quot;e&quot;</code>, <code>&quot;s&quot;</code>, or <code>&quot;e, s&quot;</code>).</p>
-<h2 id="indicating-fallback">10.3. Indicating fallback</h2>
+<h2 id="zero-rtt-and-noise-protocols">10.3. Zero-RTT and Noise protocols</h2>
 <p>A typical compound protocol for zero-RTT encryption involves three different Noise protocols:</p>
 <ul>
-<li><p>A <strong>full handshake</strong> is used if Alice doesn't possess stored information about Bob that would enable zero-RTT encryption, or doesn't wish to use the zero-RTT handshake.</p></li>
-<li><p>A <strong>zero-RTT handshake</strong> allows encryption of data in the initial message.</p></li>
-<li><p>A <strong>fallback handshake</strong> is triggered by Bob if he can't decrypt Alice's first zero-RTT handshake message.</p></li>
+<li><p>A <strong>full protocol</strong> is used if Alice doesn't possess stored information about Bob that would enable zero-RTT encryption, or doesn't wish to use the zero-RTT handshake.</p></li>
+<li><p>A <strong>zero-RTT protocol</strong> allows encryption of data in the initial message.</p></li>
+<li><p>A <strong>switch protocol</strong> is triggered by Bob if he can't decrypt Alice's first zero-RTT handshake message.</p></li>
 </ul>
-<p>There must be some way for Bob to distinguish full versus zero-RTT handshakes on receiving the first message. If Alice makes a zero-RTT attempt, there must be some way for her to distinguish zero-RTT from fallback handshakes on receiving the response.</p>
-<p>For example, each handshake message could be preceded by a <code>type</code> byte (see <a href="#application-responsibilities">Section 13</a>). This byte is not part of the Noise message proper, but signals which handshake is being used:</p>
-<ul>
-<li><p>If <code>type == 0</code> in Alice's first message then she is performing a full handshake.</p></li>
-<li><p>If <code>type == 1</code> in Alice's first message then she is performing a zero-RTT handshake.</p></li>
-<li><p>If <code>type == 0</code> in the response then the zero-RTT message was accepted.</p></li>
-<li><p>If <code>type == 1</code> in the response then Bob failed to decrypt Alice's zero-RTT message and is performing a fallback handshake.</p></li>
-</ul>
-<p>Note that the <code>type</code> byte doesn't need to be explicitly authenticated (either as prologue, or as &quot;associated data&quot; in the AEAD encryption), since it's implicitly authenticated if the message is processed succesfully.</p>
+<p>There must be some way for Bob to distinguish the full versus zero-RTT cases on receiving the first message. If Alice makes a zero-RTT attempt, there must be some way for her to distinguish the zero-RTT versus switch cases on receiving the response.</p>
+<p>For example, each handshake message could be preceded by some negotiation data, such as a <code>type</code> byte (see <a href="#application-responsibilities">Section 13</a>). This data is not part of the Noise message proper, but signals which Noise protocol is being used.</p>
 <h2 id="noise-pipes">10.4. Noise Pipes</h2>
-<p>This section defines the <strong>Noise Pipe</strong> compound protocol. These handshake patterns satisfy the full, zero-RTT, and fallback roles discussed in the previous section, so can be used to provide a full handshake with a simple zero-RTT option:</p>
+<p>This section defines the <strong>Noise Pipe</strong> compound protocol. The following handshake patterns satisfy the full, zero-RTT, and switch roles discussed in the previous section, so can be used to provide a full handshake with a simple zero-RTT option:</p>
 <pre><code>XX:  
   -&gt; e
   &lt;- e, ee, s, es
@@ -1164,8 +1157,7 @@ XXfallback:
   -&gt; s, se</code></pre>
 <p>The <code>XX</code> pattern is used for a <strong>full handshake</strong> if the parties haven't communicated before, after which Alice can cache Bob's static public key.</p>
 <p>The <code>IK</code> pattern is used for a <strong>zero-RTT handshake</strong>.</p>
-<p>The <code>XXfallback</code> pattern is used for a <strong>fallback handshake</strong> if Bob fails to decrypt the first <code>IK</code> message (perhaps due to having changed his static key).</p>
-
+<p>The <code>XXfallback</code> pattern is used for a <strong>switch handshake</strong> if Bob fails to decrypt an initial <code>IK</code> message (perhaps due to having changed his static key).</p>
 <h2 id="handshake-indistinguishability">10.5. Handshake indistinguishability</h2>
 <p>Parties might wish to hide from an eavesdropper which type of handshake they are performing. For example, suppose parties are using Noise Pipes, and want to hide whether they are performing a full handshake, zero-RTT handshake, or fallback handshake.</p>
 <p>This is fairly easy:</p>
@@ -1176,7 +1168,6 @@ XXfallback:
 <li><p>An Alice attempting a full handshake will send an ephemeral public key, then random padding, and will use <code>XXfallback</code> to handle the response. Note that <code>XX</code> isn't used, because the server can't distinguish an <code>XX</code> message from a failed <code>IK</code> attempt by using trial decryption.</p></li>
 </ul>
 <p>This leaves the Noise ephemeral public keys in the clear. Ephemeral public keys are randomly chosen DH public values, but they will typically have enough structure that an eavesdropper might suspect the parties are using Noise, even if the eavesdropper can't distinguish the different handshakes. To make the ephemerals indistinguishable from random byte sequences, techniques like Elligator <span class="citation">[<a href="#ref-elligator">5</a>]</span> could be used.</p>
-
 <h1 id="advanced-features">11. Advanced features</h1>
 <h2 id="dummy-keys">11.1. Dummy keys</h2>
 <p>Consider a protocol where an initiator will authenticate herself if the responder requests it. This could be viewed as the initiator choosing between patterns like <code>NX</code> and <code>XX</code> based on some value inside the responder's first handshake payload.</p>
diff --git a/output/noise.pdf b/output/noise.pdf
index 7fc06ab..970c5eb 100644
--- a/output/noise.pdf
+++ b/output/noise.pdf