more work on 8.x

1 files changed, 19 insertions, 17 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 44f377a..dd73158 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2723,23 +2723,26 @@ FUNCTION END
                 <name>Limit Active/Passive Decoding changes</name>
                 <t>
                   To prevent an attacker from sending a peer into an endless loop between active and passive decoding, a
-                  limitation for active/passive roll switches is required. This can be implemented by
+                  limitation for active/passive roll switches is required.
+                  Otherwise, an attacker could
+                  force the victim to waste unlimited amount of resources by just transmitting
+                  IBFs that do not decode.
+                  This can be implemented by
                   a simple counter which terminates the operation after a predefined number of switches.
-                  The number of switches needs to be defined in such a way that it is very unprobable that more
-                  switches are required an the malicious intend of the other peer can be assumed.
+                  The maximum number of switches needs to be defined in such a way that it is
+                  very improbable that more switches are required in a legitimate interaction,
+                  and hence the malicious behavior of the other peer is assured.
                 </t>
                 <t>
-                  Thus, the limitation of the maximum allowed active/passive changes during differential synchronisation is key
-                  to security. By limiting the maximum rounds in differential synchronisation an attacker can not waste
-                  unlimited amount of resources by just pretending an IBF does not decode.
-                </t>
-                <t>
-                    The question after how many active/passive switches it can be assumed that the other peer is not honest,
-                    depends on many factors and can only be solved probabilistically. This is described in detail in <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
-                    in section 5.4. From this work it is concluded that the probability of decoding failure is about
-                    15% for each round. The probability that there will be n active/passive changes is given by 0.15^{round number}.
-                    Which means that after about 30 active/passive switches it can be said with a certainty of 2^80 that one of the peers
-                    is not following the protocol. It is reasonable that a maximum of 30 active/passive changes should be set.
+                  The question after how many active/passive switches it can be assumed that the other peer is not honest,
+                  depends on the various tuning parameters of the algorithm.
+                  Section 5.4 of <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
+                  demonstrates that the probability of decoding failure is less than
+                  15% for each round. The probability that there will be n legitimate
+                  active/passive changes is thus less than 0.15^{round number}.
+                  Which means that after about 30 active/passive switches it can be said with a certainty of 2^80 that one of the peers
+                  is not following the protocol.
+                  Hence, participants MUST impose a maximum of 30 active/passive changes.
                 </t>
             </section>
 
@@ -2749,14 +2752,13 @@ FUNCTION END
                     An attacker can try to use up a peer's bandwidth by pretending that the peer
                     needs full synchronisation, even if the set difference is very small and the attacker
                     only has a few (or even zero) elements that are not already synchronised.
-                    In such a case, it would be ideal, if the plausibility could already be checked
+                    In such a case, it would be ideal if the plausibility could already be checked
                     during full synchronisation as to whether the other peer was honest or not with
                     regard to the estimation of the set size difference and thus the choice of mode
                     of operation.
                 </t>
                 <t>
-                    In order to calculate this plausibility, in Summmermatters paper <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/> in section 5.5
-                    a formula was developed, which depicts the probability with which one
+                    In order to calculate this plausibility, section 5.5 of <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/> describes a formula, which depicts the probability with which one
                     can calculate the corresponding plausibility based on the number of
                     new and repeated elements after each received element.
                 </t>