[lsd0004] branch master updated: clarify path element signatures and verification

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new fec1554  clarify path element signatures and verification
fec1554 is described below

commit fec15549407552db80575ae1f8b199da8f7e08ea
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Mon Mar 14 01:07:29 2022 +0100

    clarify path element signatures and verification
---
 draft-schanzen-r5n.xml | 42 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 6096c24..cc59f22 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -408,7 +408,7 @@ Connectivity | |Underlay|  |Underlay|
           <dd>
             is a signed path of the IDs of peers which the query
            traversed through the network. The DHT will try to make
-           the path available if the RecordRoute flag was set by
+           the path available if the <tt>RecordRoute</tt> flag was set by
            the application calling the PUT procedure. The reported
            path may have been silently truncated from the beginning.
           </dd>
@@ -416,7 +416,7 @@ Connectivity | |Underlay|  |Underlay|
           <dd>
             is a signed path of the IDs of peers which the
            result message traversed.  The DHT will try to make the
-           path available if the RecordRoute flag was set for the GET 
procedure.
+           path available if the <tt>RecordRoute</tt> flag was set for the GET 
procedure.
            The reported path may have been silently truncated from the 
beginning.
            As the block was cached by the node at the end of this
            path, this path is more likely to be stale compared to the
@@ -1420,7 +1420,18 @@ bchar = *(ALPHA / DIGIT)
             <li>
               If the <tt>RecordRoute</tt> flag is set in FLAGS,
               the local peer address <bcp14>MUST</bcp14> be appended to the 
<tt>PUTPATH</tt>
-              of the message.
+              of the message.  If the flag is not set, the <tt>PATH_LEN</tt> 
+             <bcp14>MUST</bcp14> be set to zero.
+            </li>
+            <li>
+              If the <tt>PATH_LEN</tt> is non-zero, 
+              the local peer <bcp14>SHOULD</bcp14> verify the signatures from 
the <tt>PUTPATH</tt>.
+             Verification <bcp14>MAY</bcp14> involve checking all signatures 
or any random
+             subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that 
peers adapt 
+             their behavior to available computational resources so as to not 
make signature
+             verification a bottleneck.  If an invalid signature is found, the
+             <tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include 
the elements
+             following the invalid signature.
             </li>
             <li>
               If the local peer is the closest peer
@@ -1737,7 +1748,7 @@ bchar = *(ALPHA / DIGIT)
               is a 32-bit block type field. The block type indicates the 
content
               type of the payload. In network byte order.
             </dd>
-            <dt>PUTPATH_L</dt>
+            <dt>PUTPATH_LEN</dt>
             <dd>
               is a 16-bit number indicating the length of the PUT path recorded
               in <tt>PUTPATH</tt>. As <tt>PUTPATH</tt> is optional, this value 
may be zero
@@ -1798,6 +1809,18 @@ bchar = *(ALPHA / DIGIT)
              If the result is <tt>BLOCK_INVALID</tt>, the message 
<bcp14>MUST</bcp14> be
              discarded.
             </li>
+            <li>
+              If the <tt>PUT_PATH_LEN</tt> or the <tt>GET_PATH_LEN</tt> are 
non-zero, 
+              the local peer <bcp14>SHOULD</bcp14> verify the signatures from 
the <tt>PUTPATH</tt>
+             and the <tt>GETPATH</tt>.
+             Verification <bcp14>MAY</bcp14> involve checking all signatures 
or any random
+             subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that 
peers adapt 
+             their behavior to available computational resources so as to not 
make signature
+             verification a bottleneck.  If an invalid signature is found, the
+             path <bcp14>MUST</bcp14> be truncated to only include the elements
+             following the invalid signature.  In particular, any invalid 
signature
+             on the <tt>GETPATH</tt> will cause <tt>PUT_PATH_LEN</tt> to be 
set to 0.
+            </li>
            <li>
              The peer also attempts to compute the
              key using <tt>DeriveBlockKey</tt>.  This may result in 
<tt>NONE</tt>.
@@ -1823,7 +1846,7 @@ bchar = *(ALPHA / DIGIT)
               </t>
              <ol type="%c)">
                <li>
-                 If the approximate flag was not set in the query and the 
<tt>BTYPE</tt> allowed the
+                 If the <tt>FindApproximate</tt> flag was not set in the query 
and the <tt>BTYPE</tt> allowed the
                  implementation to compute the key from the block, the 
computed key must
                  exactly match the <tt>QUERY_HASH</tt>, otherwise the result 
does
                  not match the pending query and processing continues with the 
next pending query.               
@@ -1845,6 +1868,15 @@ bchar = *(ALPHA / DIGIT)
                  The result of this duplicate filtering is always either
                  <tt>FILTER_MORE</tt> or <tt>FILTER_DUPLICATE</tt>.
                 </li>
+               <li>
+                 If the <tt>RecordRoute</tt> flag is set in FLAGS,
+                  the local peer address <bcp14>MUST</bcp14> be appended to 
the <tt>GETPATH</tt>
+                  of the message and the respective signature 
<bcp14>MUST</bcp14> be
+                  set using the query origin as the <tt>PEER SUCCESSOR</tt> 
and the
+                 response origin as the <tt>PEER PREDECESSOR</tt>.  If the 
flag is not set, 
+                  the <tt>GET_PATH_LEN</tt> and <tt>PUT_PATH_LEN</tt> 
+                 <bcp14>MUST</bcp14> be set to zero when forwarding the result.
+                </li>
               </ol>
              <t>
                If the result is either <tt>FILTER_MORE</tt> or 
<tt>FILTER_LAST</tt>,

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.