misc edits

1 files changed, 83 insertions, 41 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index c9c1141..0467499 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2834,22 +2834,27 @@ END FUNCTION
                 <dl>
                     <dt><xref target="messages_full_element" format="title" /></dt>
                     <dd>
-                        <t>
-                            When receiving full elements there needs to be checked, that every
-                            element is a valid element, that no element has been received more than once and
-                            not more or less elements are received, as the other peer has committed
-                            to in the beginning of the operation. The plausibility should also be checked
-                            with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>.
-                        </t>
+                      <t>
+                        When receiving full elements there needs to be checked, that every
+                        element is a valid element, that no element has been received more than once, and
+                        that not more elements have been received than the other peer has committed
+                        to at the beginning of the operation. The plausibility should also be checked
+                        with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>.
+                      </t>
                     </dd>
                     <dt><xref target="messages_full_done" format="title" /></dt>
                     <dd>
-                        <t>
-                        When receiving the <em><xref target="messages_full_done" format="title" /></em> message, it is important to check that
-                        not less elements are received as the other peer has committed to
-                        send. If the sets differ, a resynchronisation is required. The number of possible
+                      <t>
+                        When receiving the <em><xref target="messages_full_done" format="title" /></em>
+                        message, it is important to check that
+                        not fewer elements have been received than the other peer has committed to
+                        send at the beginning of the operation.
+                        <!-- FIXME: I don't see how the next sentence makes sense. If we got a FULL_DONE,
+                             and we still have differing sets, something is broken and re-doing it hardly
+                             makes sense, right? -->
+                        If the sets differ, a resynchronisation is required. The number of possible
                         resynchronisation MUST be limited, to prevent resource exhaustion attacks.
-                        </t>
+                      </t>
                     </dd>
                 </dl>
             </section>
@@ -2861,10 +2866,16 @@ END FUNCTION
                     <dt><xref target="messages_ibf" format="title" /></dt>
                     <dd>
                         <t>
-                            No special safety measures are necessary in this state.
-                            The maximum of <xref target="messages_ibf" format="title" /> messages should be limited to a reasonable amount.
+                          The application should check that the overall size of the IBF
+                          that is being transmitted is within its resource bounds, and
+                          abort the protocol if its resource limits are likely to be
+                          exceeded, or if the size is implausible for the given operation.
                         </t>
                     </dd>
+                    <!-- FIXME: we can also receive an IBF_LAST in this state,
+                         here additional sanity checks, like that we have received
+                         all of the other fragments/parts of the IBF first and
+                         that the parameters are thus consistent apply. -->
                 </dl>
             </section>
 
@@ -2872,21 +2883,28 @@ END FUNCTION
                 <name>Active Decoding</name>
                 <t>
                     In the <strong>Active Decoding</strong> state it is important to prevent an attacker from
-                    generating and passing an unlimited amount of IBFs, that do not decode or
-                    even worse, generate an IBF constructed to send the peers in an endless loop.
-                    To prevent an endless loop in decoding, a loop detection should be implemented.
-                    The simplest solution would be to prevent decoding of more than a given amount of elements.
+                    generating and transmitting an unlimited number of IBFs that all do not decode, or
+                    to generate an IBF constructed to send the peers in an endless loop.
+                    To prevent an endless loop in decoding, loop detection MUST be implemented.
+                    The simplest solution is to prevent decoding of more than a given number of elements.
+                    <!-- FIXME: this description is awkward. Needs to be discussed.
+                         I think you also do not mean 'hashes' but 'element IDs'. -->
                     A more robust solution is to implement a algorithm that detects a loop by
                     analyzing past partially decoded IBFs. This can be achieved
                     by saving the hash of all prior partly decoded IBFs hashes in a hashmap and check
                     for every inserted hash, if it is already in the hashmap.
                 </t>
                 <t>
-                    If the IBF decodes more or less elements than are plausible, the
-                    operation MUST be terminated. The upper and lower threshold
-                    for the decoded elements can be calculated with the peers set sizes
-                    and the other peer committed set sizes from the <strong>Expecting IBF</strong>
+                    If the IBF decodes more elements than are plausible, the
+                    operation MUST be terminated.Furthermore, if the IBF
+                    decoding successfully terminates and fewer elements were
+                    decoded than plausible, the operation MUST also be terminated.
+                    The upper and lower thresholds
+                    for the number of decoded elements can be calculated with the peers set sizes
+                    and the other peer's committed set sizes from the <strong>Expecting IBF</strong>
                     state.
+                    <!-- FIXME: be more precise about how to calculate those
+                         bounds from those inputs. -->
                 </t>
 
                 <t>Security considerations for received messages:</t>
@@ -2900,17 +2918,17 @@ END FUNCTION
                             all sent inquiries and offers. When answering offers these lists MUST be checked.
                             The sending and receiving of <xref target="messages_offer" format="title" /> messages should
                             always be protected with an <xref target="security_generic_functions_mfc" format="title" />
-                            to secure the protocol against missing, doubled, not in order or unexpected messages.
+                            to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
                         </t>
                     </dd>
                     <dt><xref target="messages_elements" format="title" /></dt>
                     <dd>
                         <t>
                             If an element that never has been requested by
-                            a demand or is received double, the operation MUST be terminated.
+                            a demand or is received twice, the operation MUST be terminated.
                             The sending and receiving of <xref target="messages_elements" format="title" /> messages should
                             always be protected with an <xref target="security_generic_functions_mfc" format="title" />
-                            to secure the protocol against missing, doubled, not in order or unexpected messages.
+                            to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
                         </t>
                     </dd>
                     <dt><xref target="messages_demand" format="title" /></dt>
@@ -2922,18 +2940,23 @@ END FUNCTION
                         a list which keeps track of the state of all sent offers and received demands.
                         The sending and receiving of <em><xref target="messages_demand" format="title" /></em> messages should
                         always be protected with an <xref target="security_generic_functions_mfc" format="title" />
-                        to secure the protocol against missing, doubled, not in order or unexpected messages.
+                        to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
                         </t>
                     </dd>
                     <dt><xref target="messages_done" format="title" /></dt>
                     <dd>
                         <t>
-                            The <em><xref target="messages_done" format="title" /></em> message is only received, if the IBF has been finished
+                            The <em><xref target="messages_done" format="title" /></em> message is only received if the IBF has finished
                             decoding and all offers have been sent. If the <em><xref target="messages_done" format="title" /></em> message is received before
                             the decoding of the IBF is finished or all open offers and demands
-                            have been answered, the operation MUST be terminated. If
+                            have been answered, the operation MUST be terminated.
+                            <!-- FIXME: it is legitimate to not respond to an offer, right? Otherwise
+                                 we would not need demands; hence, the above should only be
+                                 for 'open demands', right? -->
+                            If
                             the sets differ, a resynchronisation is required. The number of possible
                             resynchronisation MUST be limited to prevent resource exhaustion attacks.
+                            <!-- FIXME: again, how can this happen? Why should we really allow this? -->
                         </t>
                         <t>
                             When a <em><xref target="messages_done" format="title" /></em> message is received the
@@ -2959,7 +2982,7 @@ END FUNCTION
                     <dd>
                         When receiving <xref target="messages_elements" format="title" /> messages it is important
                         to always check the <xref target="security_generic_functions_mfc" format="title" />
-                        to secure the protocol against missing, doubled, not in order or unexpected messages.
+                        to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
                     </dd>
                 </dl>
             </section>
@@ -2982,6 +3005,10 @@ END FUNCTION
                             which means within the byzantine boundaries described in section <xref target="security_generic_functions_check_byzantine_boundaries" format="title" />.
                         </t>
                         <t>
+                          <!-- FIXME: I do not think this kind of consideration
+                               belongs into an RFC... Besides, you can have memory
+                               corruption at most steps of the algorithm if the code is sufficiently
+                               careless... -->
                             In case of compressed strata estimators the unpacking algorithm needs to
                             be protected against unpacking memory corruption (memory overflow).
                         </t>
@@ -2997,18 +3024,23 @@ END FUNCTION
                         <t>
                             When receiving full elements there needs to be checked, that every
                             element is a valid element, no element has been received more than once and
-                            not more or less elements are received, as the other peer has committed
-                            to in the beginning of the operation. The plausibility should also be checked
+                            not more elements are received than the other peer committed
+                            to sending at the beginning of the operation. The plausibility should also be checked
                             with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>.
                         </t>
                     </dd>
                     <dt><xref target="messages_full_done" format="title" /></dt>
                     <dd>
                         <t>
-                            When the <em><xref target="messages_full_done" format="title" /></em> message is received from the remote peer, all
-                            elements, that the remote peer has committed to, need to be received,
-                            otherwise the operation MUST be terminated. After receiving the
-                            <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted. If
+                            When the <em><xref target="messages_full_done" format="title" /></em> message is received from the remote peer, it should be checked that the number of
+                            elements received matches the number that the remote peer
+                            originally committed to transmitting,
+                            otherwise the operation MUST be terminated.
+                            <!-- FIXME: this is redundant, already covered by the new state, right? -->
+                            After receiving the
+                            <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted.
+                            <!-- FIXME: again, how can this happen? Why should we really allow this? -->
+                            If
                             the sets differ, a resynchronisation is required. The number of possible
                             resynchronisation MUST be limited to prevent resource exhaustion attacks.
                         </t>
@@ -3023,7 +3055,14 @@ END FUNCTION
                     <dd>
                         <t>
                             In case an <xref target="messages_ibf" format="title" /> message is received by the peer a active/passive role switch
-                            is initiated by the active decoding remote peer. In this moment the peer MUST
+                            is initiated by the active decoding remote peer.
+                            <!-- FIXME: is this a good choice? I thought we do NOT do this,
+                                 if we do, the round-trip calculations are totally WRONG as
+                                 then the swap will no longer just add 0.5 RTT! I think
+                                 we MUST instead permit that an IBF decodes to an element
+                                 that was offered/demanded (only in the previous iteration?) and then
+                                 simply SKIP that element ID! -->
+                            In this moment the peer MUST
                             wait for all open offers and demands to be fulfilled, to prevent
                             retransmission before switching into active decoding operation mode.
                             A switch into active decoding mode MUST only be permitted for
@@ -3035,9 +3074,12 @@ END FUNCTION
                         <t>
                         A check needs to be in place that prevents receiving an inquiry
                         for an element multiple times or more inquiries than are plausible.
+                        <!-- FIXME: how again does one determine how many inquiries are plausible?
+                             Be precise! I can see several options (overall set sizes, but also
+                             SE, or even IBF size). -->
                         The sending and receiving of <em><xref target="messages_inquiry" format="title" /></em> messages should
                         always be protected with an <xref target="security_generic_functions_mfc" format="title" />
-                        to secure the protocol against missing, doubled, not in order or unexpected messages.
+                        to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
                         </t>
                     </dd>
                     <dt><xref target="messages_demand" format="title" /></dt>
@@ -3067,11 +3109,11 @@ END FUNCTION
                 <name>Finish Waiting</name>
                 <t>
                     In the  <strong>Finish Waiting</strong> state the protocol waits for
-                    all sent demands to be fulfilled.
+                    all transmitted demands to be fulfilled.
                 </t>
                 <t>
-                    In case not all sent demands have been answered in time, the operation
-                    has failed and MUST be terminated.
+                    In case not all transmitted demands have been answered at this time, the operation
+                    has failed and the protocol MUST be terminated with an error.
                 </t>
                 <t>Security considerations for received messages:</t>
                 <dl>
@@ -3079,7 +3121,7 @@ END FUNCTION
                     <dd>
                         When receiving <xref target="messages_elements" format="title" /> messages it is important
                         to always check the <xref target="security_generic_functions_mfc" format="title" />
-                        to secure the protocol against missing, doubled, not in order or unexpected messages.
+                        to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
                     </dd>
                 </dl>
             </section>