commit 5e3e7e1d6e822b25b2ce4b4dfcee6541807990cb
parent d5ed370b23b09aa95094e15dd010aaf0bae40cce
Author: Christian Grothoff <christian@grothoff.org>
Date: Mon, 14 Jun 2021 15:03:49 +0200
fixes
Diffstat:
1 file changed, 42 insertions(+), 29 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -2390,7 +2390,7 @@ FUNCTION unpack_counter(ibf, offset, count, cbl, pd)
# Returns: Salted value
FUNCTION se_key_salting(value, salt)
- s=(salt * 7) % 64
+ s = (salt * 7) % 64
return (value >> s) | (value << (64 - s))
]]></artwork>
@@ -2406,44 +2406,38 @@ FUNCTION se_key_salting(value, salt)
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
-
<t>
The security considerations in this document focus mainly on the security
goal of availability. The primary goal of the protocol is to prevent an attacker from
- wasting cpu and network resources of the attacked peer.
+ wasting computing and network resources of the attacked peer.
</t>
<t>
To prevent denial of service attacks, it is vital to check that peers can only
reconcile a set once in a predefined time span. This is a predefined value and needs
to be adapted per use basis. To enhance reliability and to allow
- failed decoding attempts in the protocol, it is possible to introduce a threshold for max failed reconciliation
- ties.
- </t>
- <t>
- The formal format of all messages needs to be properly validated. This is important to prevent many
- attacks on the code. The application data MUST be validated by the application using
- the protocol not by the implementation of the protocol.
- In case the format validation fails the set operation MUST be terminated.
+ for legitimate failures, say due to network connectivity issues,
+ applications SHOULD define a threshold for
+ the maximum number of failed reconciliation attempts in a given time period.
</t>
-
- <t>
- To prevent an attacker from sending a peer into an endless loop between active and passive decoding, a
- limitation for active/passive roll switches is required. This can be implemented by
- a simple counter which terminates the operation after a predefined number of switches.
- The number of switches needs to be defined in such a way that it is very unprobable that more
- switches are required an the malicious intend of the other peer can be assumed.
- </t>
-
<t>
It is important to close and purge connections after a given timeout
to prevent draining attacks.
</t>
<section anchor="security_generic_functions" numbered="true" toc="default">
- <name>General Security Check</name>
+ <name>General Security Checks</name>
<t>
In this section general checks are described which should be applied to multiple states.
</t>
+ <section anchor="security_generic_input_validation" numbered="true" toc="default">
+ <name>Input validation</name>
+ <t>
+ The format of all received messages needs to be properly validated. This is important to prevent many
+ attacks on the code. The application data MUST be validated by the application using
+ the protocol not by the implementation of the protocol.
+ In case the format validation fails the set operation MUST be terminated.
+ </t>
+ </section>
<section anchor="security_generic_functions_check_byzantine_boundaries" numbered="true" toc="default">
<name>Byzantine Boundaries</name>
<t>
@@ -2481,9 +2475,21 @@ FUNCTION END
]]></artwork>
</figure>
<t>
- For the byzantine upper bound checks to function flawlessly, it needs to be ensured that the estimates of the set size
- difference added together never exceed the set byzantine upper bound. This could for example happen
- if the strata estimator overestimates the set difference.
+ For the byzantine upper bound checks to function
+ correctly, implementations must ensure that the
+ estimates of the set size difference added together
+ never exceed the set byzantine upper bound. This
+ could for example happen if the strata estimator
+ overestimates the set difference.
+ <!-- FIXME: if an implementation does this, then
+ the first two parts of the check are trivially
+ satisfied; so likely we should formulate this
+ not as a 'check' function to be _actually_
+ executed, but as a plausibility check which
+ 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. -->
</t>
</section>
@@ -2510,13 +2516,13 @@ FUNCTION END
# Returns TRUE if message is valid in state and FALSE if not
FUNCTION check_valid_state (as, s)
- FOR (as in as)
+ FOR (as in as) ## FIXME: WTF? as in as??? Also: overall terrible way to do this -- where would 'as' come from? Also, I do not think this function SHOULD even be in the RFC (technically, all you want to say is 's in as').
IF (as == s)
RETURN TRUE
END IF
FOR END
RETURN FALSE
-FUNCTION END
+FUNCTION END # FIXME: you did not use FUNCTION END above... Be consistent!
]]></artwork>
</figure>
</section>
@@ -2708,9 +2714,16 @@ FUNCTION END
<section anchor="security_generic_functions_active_passive_switches" numbered="true" toc="default">
<name>Limit Active/Passive Decoding changes</name>
<t>
- The limitation of the maximum allowed active/passive changes during differential synchronisation is key
- to security. By limiting the maximum rounds in differential synchronisation an attacker can not waste
- unlimited amount of resources by just pretending an IBF does not decode.
+ To prevent an attacker from sending a peer into an endless loop between active and passive decoding, a
+ limitation for active/passive roll switches is required. This can be implemented by
+ a simple counter which terminates the operation after a predefined number of switches.
+ The number of switches needs to be defined in such a way that it is very unprobable that more
+ switches are required an the malicious intend of the other peer can be assumed.
+ </t>
+ <t>
+ Thus, the limitation of the maximum allowed active/passive changes during differential synchronisation is key
+ to security. By limiting the maximum rounds in differential synchronisation an attacker can not waste
+ unlimited amount of resources by just pretending an IBF does not decode.
</t>
<t>
The question after how many active/passive switches it can be assumed that the other peer is not honest,
