commit 6b0433affa4148f882a0e75f2f330741f41fe120
parent ba6fa51c57e308cd7855f053d5f954dd192d3101
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Tue, 15 Jun 2021 19:13:05 +0200
Fixed some more stuff
Diffstat:
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git 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.
