[lsd0003] branch master updated: Added some more sc

[gnunet]

This is an automated email from the git hooks/post-receive script.

elias-summermatter pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new e3781d0  Added some more sc
e3781d0 is described below

commit e3781d00ce1a0c6608ed9eaa9af7845288834930
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Sun Feb 28 21:48:41 2021 +0100

    Added some more sc
---
 draft-summermatter-set-union.xml | 47 ++++++++++++++++++++++------------------
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 9758292..adc2a5c 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -1838,47 +1838,40 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
         <name>Security Considerations</name>
 
         <t>
-            In this protocol the definition of security is different then in 
other
-            protocols. This peer to peer protocol should primarily prevent an 
attacker from
-            wasting cpu and network resources.
+            The security considerations in this document focus mainly on the 
security
+            goal of availability, the primary goal of the protocol is prevent 
an attacker from
+            wasting cpu and network resources of the attacked peer.
         </t>
         <t>
-            To prevent Denial of Service attacks its vital to check that any 
other peer can only try to
-            reconcile a set once in a pre defined time span. If necessary to 
enhance reliability and to allow
+            To prevent denial of service attacks its vital to check that peers 
can only
+            reconcile a set once in a pre defined time span. This is a 
predefined values and need
+            to be adapted on per use basis. To enhance reliability and to allow
             failures in the protocol its possible to introduce a threshold for 
max failed reconciliation
-            ties in given time. The optimal values for these thresholds depend 
on the use case.
+            ties.
             <!-- IMPLEMENT: How to implement? IP? Other construct? -->
         </t>
         <t>
             The formal format of all messages needs to be properly validated, 
this is important to prevent many
             attacks on the code. The application data should be validated by 
the application using
             the protocol not by the implementation of the protocol.
-            In case the format validation fails the set operation should be 
terminated.
+            In case the format validation fails the set operation MUST be 
terminated.
             <!-- IMPLEMENT: Are all messages checked for formal valid format 
-->
         </t>
 
         <t>
-            To prevent the protocol to loop for ever between active and 
passive decoding a
-            limitation for active/passive switches in needed. This can be 
implemented by
-            a simple counter which terminates the connection after a 
predefined count of switches.
+            To prevent an attacker from sending a peer into a endless loop 
between active and passive decoding a
+            limitation for active/passive roll switches in required. This can 
be implemented by
+            a simple counter which terminates the operation after a predefined 
count of switches.
             The count of switches needs to be defined as such that its very 
undroppable that more
-            switches are required.
+            switches are required an the malicious intend of the other peer 
can be assumed.
             <!-- IMPLEMENT: This counter -->
         </t>
 
         <t>
+            <!--- SHOULD BE HANDLED BY UNDERLYING PROTOCOL BUT HOW IS IT 
HANDLED? -->
             Its important to close and purge connections after a given timeout
             to prevent draining attacks.
-            <!-- IMPLEMENT: How ist this handeld right now? -->
-        </t>
-
-        <t>
-            In the last protocol message (<xref target="messages_done" 
format="title" /> or
-            <xref target="messages_full_done" format="title" /> ) a 512-bit 
hash of
-            the complete synchronized set has to be transmitted to the other 
peer.
-            Sending the hash ensures that both sets are truly identical, if
-            they differ a resynchronisation is required. The count of possible
-            resynchronisation MUST be limited to prevent resource exhaustion 
attacks.
+            <!-- IMPLEMENT: How ist this handheld right now? -->
         </t>
 
 
@@ -1955,6 +1948,10 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                         When receiving the full done message its important to 
check that
                         not less elements are received as the other peer has 
committed to
                         send.
+                        The 512-bit hash of the complete reconciled set 
contained in
+                        the full done message is required to ensures that both 
sets are truly identical. If
+                        the sets differ a resynchronisation is required. The 
count of possible
+                        resynchronisation MUST be limited to prevent resource 
exhaustion attacks.
                         <!-- IMPLEMENT: Is this check already implemented?-->
                     </dd>
                 </dl>
@@ -2035,6 +2032,10 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                         the decoding of the IBF is finished or all open offers 
and demands
                         have been answered the operation MUST be terminated.
                         <!-- IMPLEMENT: Check that in active decoding no done 
message is received before ibf has been decoded-->
+                        The 512-bit hash of the complete reconciled set 
contained in
+                        the done message is required to ensures that both sets 
are truly identical. If
+                        the sets differ a resynchronisation is required. The 
count of possible
+                        resynchronisation MUST be limited to prevent resource 
exhaustion attacks.
                     </dd>
                 </dl>
             </section>
@@ -2100,6 +2101,10 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                         otherwise the operation MUST be terminated. After 
receiving the
                         full done message no future elements should be 
accepted.
                         <!-- FIXME: Check that after full done in full 
receiving no elements can be received anymore! Additional state? -->
+                        The 512-bit hash of the complete reconciled set 
contained in
+                        the full done message is required to ensures that both 
sets are truly identical. If
+                        the sets differ a resynchronisation is required. The 
count of possible
+                        resynchronisation MUST be limited to prevent resource 
exhaustion attacks.
                     </dd>
                 </dl>
             </section>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.