commit 05c485fc93d79c5474a0fdae741b21f400d9dcd5
parent f7743f68e876f6eacc96e3c2d89b2db9c69cb9a7
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Tue, 15 Jun 2021 14:15:51 +0200
Fixed some FIXMEs and added some comments to discuss
Diffstat:
1 file changed, 45 insertions(+), 29 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -1168,7 +1168,8 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 |
The first case is when one of the peers announces having an empty set. This is announced by setting
the SETSIZE field in the <em><xref target="messages_se" format="title" /></em> to 0.
<!-- FIXME: why not also do this if sending the elements is about as
- expensive as sending the SE? Should be a simple calculation. (thesis summermatter: future work) -->
+ expensive as sending the SE? Should be a simple calculation. (thesis summermatter: future work) @Christian:
+ As discussed 14.06 we let this comment in here as it is described in the thesis-->
The second case is if the application requests full synchronisation explicitly.
This is useful for testing and MUST NOT be used in production.
</t>
@@ -2489,7 +2490,7 @@ FUNCTION END
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. -->
+ that is then actually used. @Christian: ???-->
</t>
</section>
@@ -2851,7 +2852,8 @@ 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? -->
+ 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....-->
If the sets differ, a resynchronisation is required. The number of possible
resynchronisation MUST be limited, to prevent resource exhaustion attacks.
</t>
@@ -2872,10 +2874,22 @@ END FUNCTION
exceeded, or if the size is implausible for the given operation.
</t>
</dd>
+ <dt><xref target="messages_ibf_last" format="title" /></dt>
+ <dd>
+ <t>
+ When all <em><xref target="messages_ibf" format="title" /></em> messages have
+ been received an <em><xref target="messages_ibf_last" format="title" /></em> message
+ should conclude the transmission of the IBF and a change to the <strong>Active Decoding</strong>
+ phase should be ensured.
+ </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. -->
+ that the parameters are thus consistent apply. @Christian So we would have
+ to transmit the number of IBF slices that will be transmitted first
+ to do this check right?
+ -->
</dl>
</section>
@@ -2888,10 +2902,12 @@ END FUNCTION
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'. -->
+ I think you also do not mean 'hashes' but 'element IDs'. @Christian just omit the details
+ i guess anybody can freely decide how to handle loops its just important that e protection is
+ in place. Right?-->
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
+ by saving the element IDs 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>
@@ -2899,12 +2915,14 @@ END FUNCTION
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.
+ The upper thresholds for decoded elements from the IBF is the
+ remote set size the other peer has committed too (Case if the complete remote set is
+ new). The lower threshold for decoding element is the absolute value of the difference
+ between the local and remote set size (Case the set difference is only in the set of
+ a single peer). The other peer's committed set sizes
+ is transmitted in the the <strong>Expecting IBF</strong> state.
<!-- FIXME: be more precise about how to calculate those
- bounds from those inputs. -->
+ bounds from those inputs. @Christan better? -->
</t>
<t>Security considerations for received messages:</t>
@@ -2948,15 +2966,15 @@ END FUNCTION
<t>
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
+ 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? -->
+ 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.
- <!-- FIXME: again, how can this happen? Why should we really allow this? -->
+ <!-- FIXME: again, how can this happen? Why should we really allow this? @Christian same point above if set changes while we synchronize-->
</t>
<t>
When a <em><xref target="messages_done" format="title" /></em> message is received the
@@ -3004,14 +3022,6 @@ END FUNCTION
The set difference calculated from the strata estimator needs to be plausible,
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>
</dd>
</dl>
</section>
@@ -3036,10 +3046,10 @@ END FUNCTION
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? -->
+ <!-- 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? -->
+ <!-- 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.
@@ -3061,10 +3071,8 @@ END FUNCTION
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.
+ 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>
@@ -3074,9 +3082,17 @@ 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.
+ The upper thresholds for sent/received inquiries is the
+ remote set size the other peer has committed too (Case if the complete remote set is
+ new). The lower threshold for for sent/received inquiries is the absolute value of the
+ set difference between the local and remote set size
+ (Case the set difference is only in the set of a single peer).
+ 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). -->
+ 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.
