[lsd0003] branch master updated: fixes

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new 5e3e7e1  fixes
5e3e7e1 is described below

commit 5e3e7e1d6e822b25b2ce4b4dfcee6541807990cb
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Mon Jun 14 15:03:49 2021 +0200

    fixes
---
 draft-summermatter-set-union.xml | 71 ++++++++++++++++++++++++----------------
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index e0ea02f..4531e19 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2390,7 +2390,7 @@ FUNCTION unpack_counter(ibf, offset, count, cbl, pd)
 # Returns: Salted value
 
 FUNCTION se_key_salting(value, salt)
-    s=(salt * 7) % 64
+    s = (salt * 7) % 64
     return (value >> s) | (value << (64 - s))
 
                                     ]]></artwork>
@@ -2406,44 +2406,38 @@ FUNCTION se_key_salting(value, salt)
 
     <section anchor="security" numbered="true" toc="default">
         <name>Security Considerations</name>
-
         <t>
             The security considerations in this document focus mainly on the 
security
             goal of availability. The primary goal of the protocol is to 
prevent an attacker from
-            wasting cpu and network resources of the attacked peer.
+            wasting computing and network resources of the attacked peer.
         </t>
         <t>
             To prevent denial of service attacks, it is vital to check that 
peers can only
             reconcile a set once in a predefined time span. This is a 
predefined value and needs
             to be adapted per use basis. To enhance reliability and to allow
-            failed decoding attempts in the protocol, it is possible to 
introduce a threshold for max failed reconciliation
-            ties.
-        </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 MUST be validated by the 
application using
-            the protocol not by the implementation of the protocol.
-            In case the format validation fails the set operation MUST be 
terminated.
+            for legitimate failures, say due to network connectivity issues,
+            applications SHOULD define a threshold for
+            the maximum number of failed reconciliation attempts in a given 
time period.
         </t>
-
-        <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
-            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.
-        </t>
-
         <t>
             It is important to close and purge connections after a given 
timeout
             to prevent draining attacks.
         </t>
         <section anchor="security_generic_functions" numbered="true" 
toc="default">
-            <name>General Security Check</name>
+            <name>General Security Checks</name>
             <t>
                In this section general checks are described which should be 
applied to multiple states.
             </t>
 
+            <section anchor="security_generic_input_validation" 
numbered="true" toc="default">
+              <name>Input validation</name>
+              <t>
+                The format of all received messages needs to be properly 
validated. This is important to prevent many
+                attacks on the code. The application data MUST be validated by 
the application using
+                the protocol not by the implementation of the protocol.
+                In case the format validation fails the set operation MUST be 
terminated.
+              </t>
+            </section>
             <section 
anchor="security_generic_functions_check_byzantine_boundaries" numbered="true" 
toc="default">
                 <name>Byzantine Boundaries</name>
                 <t>
@@ -2481,9 +2475,21 @@ FUNCTION END
                     ]]></artwork>
                 </figure>
                 <t>
-                    For the byzantine upper bound checks to function 
flawlessly, it needs to be ensured that the estimates of the set size
-                    difference added together never exceed the set byzantine 
upper bound. This could for example happen
-                    if the strata estimator overestimates the set difference.
+                  For the byzantine upper bound checks to function
+                  correctly, implementations must ensure that the
+                  estimates of the set size difference added together
+                  never exceed the set byzantine upper bound.  This
+                  could for example happen if the strata estimator
+                  overestimates the set difference.
+                  <!-- FIXME: if an implementation does this, then
+                       the first two parts of the check are trivially
+                       satisfied; so likely we should formulate this
+                       not as a 'check' function to be _actually_
+                       executed, but as a plausibility check which
+                       is to be applied after the SE calculation to
+                       the computed set size differences, resulting
+                       in a hard cap on the set size difference estimate
+                       that is then actually used. -->
                 </t>
             </section>
 
@@ -2510,13 +2516,13 @@ FUNCTION END
 # Returns TRUE if message is valid in state and FALSE if not
 
 FUNCTION check_valid_state (as, s)
-    FOR (as in as)
+    FOR (as in as) ## FIXME: WTF? as in as??? Also: overall terrible way to do 
this -- where would 'as' come from? Also, I do not think this function SHOULD 
even be in the RFC (technically, all you want to say is 's in as').
         IF (as == s)
             RETURN TRUE
         END IF
     FOR END
     RETURN FALSE
-FUNCTION END
+FUNCTION END # FIXME: you did not use FUNCTION END above... Be consistent!
                     ]]></artwork>
                 </figure>
             </section>
@@ -2708,9 +2714,16 @@ FUNCTION END
             <section 
anchor="security_generic_functions_active_passive_switches" numbered="true" 
toc="default">
                 <name>Limit Active/Passive Decoding changes</name>
                 <t>
-                    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.
+                  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
+                  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.
+                </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,

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