[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: misc edits
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: misc edits |
|
Date: |
Tue, 15 Jun 2021 11:17:44 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0003.
The following commit(s) were added to refs/heads/master by this push:
new f7743f6 misc edits
f7743f6 is described below
commit f7743f68e876f6eacc96e3c2d89b2db9c69cb9a7
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Tue Jun 15 11:14:53 2021 +0200
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
<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>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0003] branch master updated: misc edits,
gnunet <=