commit f7743f68e876f6eacc96e3c2d89b2db9c69cb9a7
parent ec5663ea14762c53bbad474b93858be9e4f00f24
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 15 Jun 2021 11:14:53 +0200
misc edits
Diffstat:
1 file changed, 83 insertions(+), 41 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -2834,22 +2834,27 @@ END FUNCTION
<dl>
<dt><xref target="messages_full_element" format="title" /></dt>
<dd>
- <t>
- When receiving full elements there needs to be checked, that every
- element is a valid element, that no element has been received more than once and
- not more or less elements are received, as the other peer has committed
- to in the beginning of the operation. The plausibility should also be checked
- with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>.
- </t>
+ <t>
+ When receiving full elements there needs to be checked, that every
+ element is a valid element, that no element has been received more than once, and
+ that not more elements have been received than the other peer has committed
+ to at the beginning of the operation. The plausibility should also be checked
+ with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>.
+ </t>
</dd>
<dt><xref target="messages_full_done" format="title" /></dt>
<dd>
- <t>
- When receiving the <em><xref target="messages_full_done" format="title" /></em> message, it is important to check that
- not less elements are received as the other peer has committed to
- send. If the sets differ, a resynchronisation is required. The number of possible
+ <t>
+ When receiving the <em><xref target="messages_full_done" format="title" /></em>
+ message, it is important to check that
+ not fewer elements have been received than the other peer has committed to
+ 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? -->
+ If the sets differ, a resynchronisation is required. The number of possible
resynchronisation MUST be limited, to prevent resource exhaustion attacks.
- </t>
+ </t>
</dd>
</dl>
</section>
@@ -2861,10 +2866,16 @@ END FUNCTION
<dt><xref target="messages_ibf" format="title" /></dt>
<dd>
<t>
- No special safety measures are necessary in this state.
- The maximum of <xref target="messages_ibf" format="title" /> messages should be limited to a reasonable amount.
+ The application should check that the overall size of the IBF
+ that is being transmitted is within its resource bounds, and
+ abort the protocol if its resource limits are likely to be
+ exceeded, or if the size is implausible for the given operation.
</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. -->
</dl>
</section>
@@ -2872,21 +2883,28 @@ END FUNCTION
<name>Active Decoding</name>
<t>
In the <strong>Active Decoding</strong> state it is important to prevent an attacker from
- generating and passing an unlimited amount of IBFs, that do not decode or
- even worse, generate an IBF constructed to send the peers in an endless loop.
- To prevent an endless loop in decoding, a loop detection should be implemented.
- The simplest solution would be to prevent decoding of more than a given amount of elements.
+ generating and transmitting an unlimited number of IBFs that all do not decode, or
+ to generate an IBF constructed to send the peers in an endless loop.
+ 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'. -->
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
for every inserted hash, if it is already in the hashmap.
</t>
<t>
- If the IBF decodes more or less elements than are plausible, the
- operation MUST be terminated. The upper and lower threshold
- for the decoded elements can be calculated with the peers set sizes
- and the other peer committed set sizes from the <strong>Expecting IBF</strong>
+ If the IBF decodes more elements than are plausible, the
+ 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.
+ <!-- FIXME: be more precise about how to calculate those
+ bounds from those inputs. -->
</t>
<t>Security considerations for received messages:</t>
@@ -2900,17 +2918,17 @@ END FUNCTION
all sent inquiries and offers. When answering offers these lists MUST be checked.
The sending and receiving of <xref target="messages_offer" format="title" /> messages should
always be protected with an <xref target="security_generic_functions_mfc" format="title" />
- to secure the protocol against missing, doubled, not in order or unexpected messages.
+ to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
</t>
</dd>
<dt><xref target="messages_elements" format="title" /></dt>
<dd>
<t>
If an element that never has been requested by
- a demand or is received double, the operation MUST be terminated.
+ a demand or is received twice, the operation MUST be terminated.
The sending and receiving of <xref target="messages_elements" format="title" /> messages should
always be protected with an <xref target="security_generic_functions_mfc" format="title" />
- to secure the protocol against missing, doubled, not in order or unexpected messages.
+ to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
</t>
</dd>
<dt><xref target="messages_demand" format="title" /></dt>
@@ -2922,18 +2940,23 @@ END FUNCTION
a list which keeps track of the state of all sent offers and received demands.
The sending and receiving of <em><xref target="messages_demand" format="title" /></em> messages should
always be protected with an <xref target="security_generic_functions_mfc" format="title" />
- to secure the protocol against missing, doubled, not in order or unexpected messages.
+ to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
</t>
</dd>
<dt><xref target="messages_done" format="title" /></dt>
<dd>
<t>
- The <em><xref target="messages_done" format="title" /></em> message is only received, if the IBF has been finished
+ 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
- have been answered, the operation MUST be terminated. If
+ 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? -->
+ 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? -->
</t>
<t>
When a <em><xref target="messages_done" format="title" /></em> message is received the
@@ -2959,7 +2982,7 @@ END FUNCTION
<dd>
When receiving <xref target="messages_elements" format="title" /> messages it is important
to always check the <xref target="security_generic_functions_mfc" format="title" />
- to secure the protocol against missing, doubled, not in order or unexpected messages.
+ to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
</dd>
</dl>
</section>
@@ -2982,6 +3005,10 @@ END FUNCTION
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>
@@ -2997,18 +3024,23 @@ END FUNCTION
<t>
When receiving full elements there needs to be checked, that every
element is a valid element, no element has been received more than once and
- not more or less elements are received, as the other peer has committed
- to in the beginning of the operation. The plausibility should also be checked
+ not more elements are received than the other peer committed
+ to sending at the beginning of the operation. The plausibility should also be checked
with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>.
</t>
</dd>
<dt><xref target="messages_full_done" format="title" /></dt>
<dd>
<t>
- When the <em><xref target="messages_full_done" format="title" /></em> message is received from the remote peer, all
- elements, that the remote peer has committed to, need to be received,
- otherwise the operation MUST be terminated. After receiving the
- <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted. If
+ When the <em><xref target="messages_full_done" format="title" /></em> message is received from the remote peer, it should be checked that the number of
+ 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? -->
+ 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? -->
+ If
the sets differ, a resynchronisation is required. The number of possible
resynchronisation MUST be limited to prevent resource exhaustion attacks.
</t>
@@ -3023,7 +3055,14 @@ END FUNCTION
<dd>
<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. In this moment the peer MUST
+ 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! -->
+ 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.
A switch into active decoding mode MUST only be permitted for
@@ -3035,9 +3074,12 @@ 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.
+ <!-- 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). -->
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, doubled, not in order or unexpected messages.
+ to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
</t>
</dd>
<dt><xref target="messages_demand" format="title" /></dt>
@@ -3067,11 +3109,11 @@ END FUNCTION
<name>Finish Waiting</name>
<t>
In the <strong>Finish Waiting</strong> state the protocol waits for
- all sent demands to be fulfilled.
+ all transmitted demands to be fulfilled.
</t>
<t>
- In case not all sent demands have been answered in time, the operation
- has failed and MUST be terminated.
+ In case not all transmitted demands have been answered at this time, the operation
+ has failed and the protocol MUST be terminated with an error.
</t>
<t>Security considerations for received messages:</t>
<dl>
@@ -3079,7 +3121,7 @@ END FUNCTION
<dd>
When receiving <xref target="messages_elements" format="title" /> messages it is important
to always check the <xref target="security_generic_functions_mfc" format="title" />
- to secure the protocol against missing, doubled, not in order or unexpected messages.
+ to secure the protocol against missing, duplicated, out-of-order or unexpected messages.
</dd>
</dl>
</section>
