[lsd0003] branch master updated: Fixed some more stuff

[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 6b0433a  Fixed some more stuff
6b0433a is described below

commit 6b0433affa4148f882a0e75f2f330741f41fe120
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Tue Jun 15 19:13:05 2021 +0200

    Fixed some more stuff
---
 draft-summermatter-set-union.xml | 35 ++++++++++-------------------------
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index c0a8d52..3ac6a5e 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2862,13 +2862,11 @@ END FUNCTION
                         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? @Christian im not sure about 
that it could be that for example
-                             the set size changes (from application or other 
sync) while synchronisation is in progress.... something went
-                             wrong (HW Failures) Should never occur! 
Fehlgeschlagen! Final checksum in done/full done sha512-->
+                             makes sense, right? -->
 
                         If the sets differ (the FINAL CHECKSUM field in the 
<xref target="messages_full_done" format="title" />
-                        does not match to the sha-512 hash in our set), The 
operation has failed. This is a strong indicator
-                        that something went horribly wrong (eg. some hardware 
bug), this should never ever happen!
+                        message does not match to the sha-512 hash in our 
set), the operation has failed. This is a strong indicator
+                        that something went wrong (eg. some hardware bug), 
this should never occur!
                       </t>
                     </dd>
                 </dl>
@@ -2991,12 +2989,9 @@ END FUNCTION
                             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 
demands
                             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? @Christian your 
right corrected this one-->
-                            If
-                            the sets differ, a resynchronisation is required. 
The number of possible
-                            resynchronisation MUST be limited to prevent 
resource exhaustion attacks.
+                            If the sets differ (the FINAL CHECKSUM field in 
the <xref target="messages_done" format="title" />
+                            message does not match to the sha-512 hash in our 
set), the operation has failed. This is a strong indicator
+                            that something went wrong (eg. some hardware bug), 
this should never occur!
                             <!-- FIXME: again, how can this happen? Why should 
we really allow this? @Christian same point above if set changes while we 
synchronize-->
                         </t>
                         <t>
@@ -3072,10 +3067,10 @@ END FUNCTION
                             <!-- FIXME: this is redundant, already covered by 
the new state, right? @Christian: ??? State-->
                             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? @Christian Again set changes while sync ;-) -->
-                            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?-->
+                            If the sets differ (the FINAL CHECKSUM field in 
the <xref target="messages_full_done" format="title" />
+                            message does not match to the sha-512 hash in our 
set), the operation has failed. This is a strong indicator
+                            that something went wrong (eg. some hardware bug), 
this should never occur!
                         </t>
                     </dd>
                 </dl>
@@ -3089,13 +3084,6 @@ END FUNCTION
                         <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.
-                            <!-- 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! @Christian oh i 
missed this one. Yes, your right we dont do this!
-                                  -->
                             A switch into active decoding mode MUST only be 
permitted for
                             a predefined number of times as described in <xref 
target="security_generic_functions_active_passive_switches" format="default"/>
                         </t>
@@ -3113,9 +3101,6 @@ END FUNCTION
                         The other peer's committed set sizes is transmitted in 
the the <strong>Expecting IBF</strong> state.
                         Beware that it is possible to get key collisions and 
an inquiry for the same key
                         can be transmitted multiple times, so the threshold 
should take this into account.
-                        <!-- 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). @Christian I Added check 
parameter-->
                         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, duplicated, 
out-of-order or unexpected messages.

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