From f7743f68e876f6eacc96e3c2d89b2db9c69cb9a7 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Tue, 15 Jun 2021 11:14:53 +0200 Subject: misc edits --- draft-summermatter-set-union.xml | 124 ++++++++++++++++++++++++++------------- 1 file changed, 83 insertions(+), 41 deletions(-) diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml index c9c1141..0467499 100644 --- a/draft-summermatter-set-union.xml +++ b/draft-summermatter-set-union.xml @@ -2834,22 +2834,27 @@ END FUNCTION
- - 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 . - + + 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 . +
- - When receiving the 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 + + When receiving the + 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. + + If the sets differ, a resynchronisation is required. The number of possible resynchronisation MUST be limited, to prevent resource exhaustion attacks. - +
@@ -2861,10 +2866,16 @@ END FUNCTION
- No special safety measures are necessary in this state. - The maximum of 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.
+ @@ -2872,21 +2883,28 @@ END FUNCTION Active Decoding In the Active Decoding 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. + 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. - 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 Expecting IBF + 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 Expecting IBF state. + Security considerations for received messages: @@ -2900,17 +2918,17 @@ END FUNCTION all sent inquiries and offers. When answering offers these lists MUST be checked. The sending and receiving of messages should always be protected with an - 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.
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 messages should always be protected with an - 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.
@@ -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 messages should always be protected with an - 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.
- The message is only received, if the IBF has been finished + The message is only received if the IBF has finished decoding and all offers have been sent. If the 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. + + If the sets differ, a resynchronisation is required. The number of possible resynchronisation MUST be limited to prevent resource exhaustion attacks. + When a message is received the @@ -2959,7 +2982,7 @@ END FUNCTION
When receiving messages it is important to always check the - 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.
@@ -2982,6 +3005,10 @@ END FUNCTION which means within the byzantine boundaries described in section . + In case of compressed strata estimators the unpacking algorithm needs to be protected against unpacking memory corruption (memory overflow). @@ -2997,18 +3024,23 @@ END FUNCTION 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 .
- When the 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 - message, future elements MUST NOT be accepted. If + When the 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. + + After receiving the + message, future elements MUST NOT be accepted. + + If the sets differ, a resynchronisation is required. The number of possible resynchronisation MUST be limited to prevent resource exhaustion attacks. @@ -3023,7 +3055,14 @@ END FUNCTION
In case an 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. + + 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 A check needs to be in place that prevents receiving an inquiry for an element multiple times or more inquiries than are plausible. + The sending and receiving of messages should always be protected with an - 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.
@@ -3067,11 +3109,11 @@ END FUNCTION Finish Waiting In the Finish Waiting state the protocol waits for - all sent demands to be fulfilled. + all transmitted demands to be fulfilled. - 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. Security considerations for received messages:
@@ -3079,7 +3121,7 @@ END FUNCTION
When receiving messages it is important to always check the - 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.
-- cgit v1.2.3