diff options
Diffstat (limited to 'draft-summermatter-set-union.xml')
-rw-r--r-- | draft-summermatter-set-union.xml | 124 |
1 files 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 | |||
2834 | <dl> | 2834 | <dl> |
2835 | <dt><xref target="messages_full_element" format="title" /></dt> | 2835 | <dt><xref target="messages_full_element" format="title" /></dt> |
2836 | <dd> | 2836 | <dd> |
2837 | <t> | 2837 | <t> |
2838 | When receiving full elements there needs to be checked, that every | 2838 | When receiving full elements there needs to be checked, that every |
2839 | element is a valid element, that no element has been received more than once and | 2839 | element is a valid element, that no element has been received more than once, and |
2840 | not more or less elements are received, as the other peer has committed | 2840 | that not more elements have been received than the other peer has committed |
2841 | to in the beginning of the operation. The plausibility should also be checked | 2841 | to at the beginning of the operation. The plausibility should also be checked |
2842 | with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>. | 2842 | with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>. |
2843 | </t> | 2843 | </t> |
2844 | </dd> | 2844 | </dd> |
2845 | <dt><xref target="messages_full_done" format="title" /></dt> | 2845 | <dt><xref target="messages_full_done" format="title" /></dt> |
2846 | <dd> | 2846 | <dd> |
2847 | <t> | 2847 | <t> |
2848 | When receiving the <em><xref target="messages_full_done" format="title" /></em> message, it is important to check that | 2848 | When receiving the <em><xref target="messages_full_done" format="title" /></em> |
2849 | not less elements are received as the other peer has committed to | 2849 | message, it is important to check that |
2850 | send. If the sets differ, a resynchronisation is required. The number of possible | 2850 | not fewer elements have been received than the other peer has committed to |
2851 | send at the beginning of the operation. | ||
2852 | <!-- FIXME: I don't see how the next sentence makes sense. If we got a FULL_DONE, | ||
2853 | and we still have differing sets, something is broken and re-doing it hardly | ||
2854 | makes sense, right? --> | ||
2855 | If the sets differ, a resynchronisation is required. The number of possible | ||
2851 | resynchronisation MUST be limited, to prevent resource exhaustion attacks. | 2856 | resynchronisation MUST be limited, to prevent resource exhaustion attacks. |
2852 | </t> | 2857 | </t> |
2853 | </dd> | 2858 | </dd> |
2854 | </dl> | 2859 | </dl> |
2855 | </section> | 2860 | </section> |
@@ -2861,10 +2866,16 @@ END FUNCTION | |||
2861 | <dt><xref target="messages_ibf" format="title" /></dt> | 2866 | <dt><xref target="messages_ibf" format="title" /></dt> |
2862 | <dd> | 2867 | <dd> |
2863 | <t> | 2868 | <t> |
2864 | No special safety measures are necessary in this state. | 2869 | The application should check that the overall size of the IBF |
2865 | The maximum of <xref target="messages_ibf" format="title" /> messages should be limited to a reasonable amount. | 2870 | that is being transmitted is within its resource bounds, and |
2871 | abort the protocol if its resource limits are likely to be | ||
2872 | exceeded, or if the size is implausible for the given operation. | ||
2866 | </t> | 2873 | </t> |
2867 | </dd> | 2874 | </dd> |
2875 | <!-- FIXME: we can also receive an IBF_LAST in this state, | ||
2876 | here additional sanity checks, like that we have received | ||
2877 | all of the other fragments/parts of the IBF first and | ||
2878 | that the parameters are thus consistent apply. --> | ||
2868 | </dl> | 2879 | </dl> |
2869 | </section> | 2880 | </section> |
2870 | 2881 | ||
@@ -2872,21 +2883,28 @@ END FUNCTION | |||
2872 | <name>Active Decoding</name> | 2883 | <name>Active Decoding</name> |
2873 | <t> | 2884 | <t> |
2874 | In the <strong>Active Decoding</strong> state it is important to prevent an attacker from | 2885 | In the <strong>Active Decoding</strong> state it is important to prevent an attacker from |
2875 | generating and passing an unlimited amount of IBFs, that do not decode or | 2886 | generating and transmitting an unlimited number of IBFs that all do not decode, or |
2876 | even worse, generate an IBF constructed to send the peers in an endless loop. | 2887 | to generate an IBF constructed to send the peers in an endless loop. |
2877 | To prevent an endless loop in decoding, a loop detection should be implemented. | 2888 | To prevent an endless loop in decoding, loop detection MUST be implemented. |
2878 | The simplest solution would be to prevent decoding of more than a given amount of elements. | 2889 | The simplest solution is to prevent decoding of more than a given number of elements. |
2890 | <!-- FIXME: this description is awkward. Needs to be discussed. | ||
2891 | I think you also do not mean 'hashes' but 'element IDs'. --> | ||
2879 | A more robust solution is to implement a algorithm that detects a loop by | 2892 | A more robust solution is to implement a algorithm that detects a loop by |
2880 | analyzing past partially decoded IBFs. This can be achieved | 2893 | analyzing past partially decoded IBFs. This can be achieved |
2881 | by saving the hash of all prior partly decoded IBFs hashes in a hashmap and check | 2894 | by saving the hash of all prior partly decoded IBFs hashes in a hashmap and check |
2882 | for every inserted hash, if it is already in the hashmap. | 2895 | for every inserted hash, if it is already in the hashmap. |
2883 | </t> | 2896 | </t> |
2884 | <t> | 2897 | <t> |
2885 | If the IBF decodes more or less elements than are plausible, the | 2898 | If the IBF decodes more elements than are plausible, the |
2886 | operation MUST be terminated. The upper and lower threshold | 2899 | operation MUST be terminated.Furthermore, if the IBF |
2887 | for the decoded elements can be calculated with the peers set sizes | 2900 | decoding successfully terminates and fewer elements were |
2888 | and the other peer committed set sizes from the <strong>Expecting IBF</strong> | 2901 | decoded than plausible, the operation MUST also be terminated. |
2902 | The upper and lower thresholds | ||
2903 | for the number of decoded elements can be calculated with the peers set sizes | ||
2904 | and the other peer's committed set sizes from the <strong>Expecting IBF</strong> | ||
2889 | state. | 2905 | state. |
2906 | <!-- FIXME: be more precise about how to calculate those | ||
2907 | bounds from those inputs. --> | ||
2890 | </t> | 2908 | </t> |
2891 | 2909 | ||
2892 | <t>Security considerations for received messages:</t> | 2910 | <t>Security considerations for received messages:</t> |
@@ -2900,17 +2918,17 @@ END FUNCTION | |||
2900 | all sent inquiries and offers. When answering offers these lists MUST be checked. | 2918 | all sent inquiries and offers. When answering offers these lists MUST be checked. |
2901 | The sending and receiving of <xref target="messages_offer" format="title" /> messages should | 2919 | The sending and receiving of <xref target="messages_offer" format="title" /> messages should |
2902 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> | 2920 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> |
2903 | to secure the protocol against missing, doubled, not in order or unexpected messages. | 2921 | to secure the protocol against missing, duplicated, out-of-order or unexpected messages. |
2904 | </t> | 2922 | </t> |
2905 | </dd> | 2923 | </dd> |
2906 | <dt><xref target="messages_elements" format="title" /></dt> | 2924 | <dt><xref target="messages_elements" format="title" /></dt> |
2907 | <dd> | 2925 | <dd> |
2908 | <t> | 2926 | <t> |
2909 | If an element that never has been requested by | 2927 | If an element that never has been requested by |
2910 | a demand or is received double, the operation MUST be terminated. | 2928 | a demand or is received twice, the operation MUST be terminated. |
2911 | The sending and receiving of <xref target="messages_elements" format="title" /> messages should | 2929 | The sending and receiving of <xref target="messages_elements" format="title" /> messages should |
2912 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> | 2930 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> |
2913 | to secure the protocol against missing, doubled, not in order or unexpected messages. | 2931 | to secure the protocol against missing, duplicated, out-of-order or unexpected messages. |
2914 | </t> | 2932 | </t> |
2915 | </dd> | 2933 | </dd> |
2916 | <dt><xref target="messages_demand" format="title" /></dt> | 2934 | <dt><xref target="messages_demand" format="title" /></dt> |
@@ -2922,18 +2940,23 @@ END FUNCTION | |||
2922 | a list which keeps track of the state of all sent offers and received demands. | 2940 | a list which keeps track of the state of all sent offers and received demands. |
2923 | The sending and receiving of <em><xref target="messages_demand" format="title" /></em> messages should | 2941 | The sending and receiving of <em><xref target="messages_demand" format="title" /></em> messages should |
2924 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> | 2942 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> |
2925 | to secure the protocol against missing, doubled, not in order or unexpected messages. | 2943 | to secure the protocol against missing, duplicated, out-of-order or unexpected messages. |
2926 | </t> | 2944 | </t> |
2927 | </dd> | 2945 | </dd> |
2928 | <dt><xref target="messages_done" format="title" /></dt> | 2946 | <dt><xref target="messages_done" format="title" /></dt> |
2929 | <dd> | 2947 | <dd> |
2930 | <t> | 2948 | <t> |
2931 | The <em><xref target="messages_done" format="title" /></em> message is only received, if the IBF has been finished | 2949 | The <em><xref target="messages_done" format="title" /></em> message is only received if the IBF has finished |
2932 | decoding and all offers have been sent. If the <em><xref target="messages_done" format="title" /></em> message is received before | 2950 | decoding and all offers have been sent. If the <em><xref target="messages_done" format="title" /></em> message is received before |
2933 | the decoding of the IBF is finished or all open offers and demands | 2951 | the decoding of the IBF is finished or all open offers and demands |
2934 | have been answered, the operation MUST be terminated. If | 2952 | have been answered, the operation MUST be terminated. |
2953 | <!-- FIXME: it is legitimate to not respond to an offer, right? Otherwise | ||
2954 | we would not need demands; hence, the above should only be | ||
2955 | for 'open demands', right? --> | ||
2956 | If | ||
2935 | the sets differ, a resynchronisation is required. The number of possible | 2957 | the sets differ, a resynchronisation is required. The number of possible |
2936 | resynchronisation MUST be limited to prevent resource exhaustion attacks. | 2958 | resynchronisation MUST be limited to prevent resource exhaustion attacks. |
2959 | <!-- FIXME: again, how can this happen? Why should we really allow this? --> | ||
2937 | </t> | 2960 | </t> |
2938 | <t> | 2961 | <t> |
2939 | When a <em><xref target="messages_done" format="title" /></em> message is received the | 2962 | When a <em><xref target="messages_done" format="title" /></em> message is received the |
@@ -2959,7 +2982,7 @@ END FUNCTION | |||
2959 | <dd> | 2982 | <dd> |
2960 | When receiving <xref target="messages_elements" format="title" /> messages it is important | 2983 | When receiving <xref target="messages_elements" format="title" /> messages it is important |
2961 | to always check the <xref target="security_generic_functions_mfc" format="title" /> | 2984 | to always check the <xref target="security_generic_functions_mfc" format="title" /> |
2962 | to secure the protocol against missing, doubled, not in order or unexpected messages. | 2985 | to secure the protocol against missing, duplicated, out-of-order or unexpected messages. |
2963 | </dd> | 2986 | </dd> |
2964 | </dl> | 2987 | </dl> |
2965 | </section> | 2988 | </section> |
@@ -2982,6 +3005,10 @@ END FUNCTION | |||
2982 | which means within the byzantine boundaries described in section <xref target="security_generic_functions_check_byzantine_boundaries" format="title" />. | 3005 | which means within the byzantine boundaries described in section <xref target="security_generic_functions_check_byzantine_boundaries" format="title" />. |
2983 | </t> | 3006 | </t> |
2984 | <t> | 3007 | <t> |
3008 | <!-- FIXME: I do not think this kind of consideration | ||
3009 | belongs into an RFC... Besides, you can have memory | ||
3010 | corruption at most steps of the algorithm if the code is sufficiently | ||
3011 | careless... --> | ||
2985 | In case of compressed strata estimators the unpacking algorithm needs to | 3012 | In case of compressed strata estimators the unpacking algorithm needs to |
2986 | be protected against unpacking memory corruption (memory overflow). | 3013 | be protected against unpacking memory corruption (memory overflow). |
2987 | </t> | 3014 | </t> |
@@ -2997,18 +3024,23 @@ END FUNCTION | |||
2997 | <t> | 3024 | <t> |
2998 | When receiving full elements there needs to be checked, that every | 3025 | When receiving full elements there needs to be checked, that every |
2999 | element is a valid element, no element has been received more than once and | 3026 | element is a valid element, no element has been received more than once and |
3000 | not more or less elements are received, as the other peer has committed | 3027 | not more elements are received than the other peer committed |
3001 | to in the beginning of the operation. The plausibility should also be checked | 3028 | to sending at the beginning of the operation. The plausibility should also be checked |
3002 | with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>. | 3029 | with an algorithm as described in <xref target="security_generic_functions_full_plausibility_check" format="default"/>. |
3003 | </t> | 3030 | </t> |
3004 | </dd> | 3031 | </dd> |
3005 | <dt><xref target="messages_full_done" format="title" /></dt> | 3032 | <dt><xref target="messages_full_done" format="title" /></dt> |
3006 | <dd> | 3033 | <dd> |
3007 | <t> | 3034 | <t> |
3008 | When the <em><xref target="messages_full_done" format="title" /></em> message is received from the remote peer, all | 3035 | 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 |
3009 | elements, that the remote peer has committed to, need to be received, | 3036 | elements received matches the number that the remote peer |
3010 | otherwise the operation MUST be terminated. After receiving the | 3037 | originally committed to transmitting, |
3011 | <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted. If | 3038 | otherwise the operation MUST be terminated. |
3039 | <!-- FIXME: this is redundant, already covered by the new state, right? --> | ||
3040 | After receiving the | ||
3041 | <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted. | ||
3042 | <!-- FIXME: again, how can this happen? Why should we really allow this? --> | ||
3043 | If | ||
3012 | the sets differ, a resynchronisation is required. The number of possible | 3044 | the sets differ, a resynchronisation is required. The number of possible |
3013 | resynchronisation MUST be limited to prevent resource exhaustion attacks. | 3045 | resynchronisation MUST be limited to prevent resource exhaustion attacks. |
3014 | </t> | 3046 | </t> |
@@ -3023,7 +3055,14 @@ END FUNCTION | |||
3023 | <dd> | 3055 | <dd> |
3024 | <t> | 3056 | <t> |
3025 | In case an <xref target="messages_ibf" format="title" /> message is received by the peer a active/passive role switch | 3057 | In case an <xref target="messages_ibf" format="title" /> message is received by the peer a active/passive role switch |
3026 | is initiated by the active decoding remote peer. In this moment the peer MUST | 3058 | is initiated by the active decoding remote peer. |
3059 | <!-- FIXME: is this a good choice? I thought we do NOT do this, | ||
3060 | if we do, the round-trip calculations are totally WRONG as | ||
3061 | then the swap will no longer just add 0.5 RTT! I think | ||
3062 | we MUST instead permit that an IBF decodes to an element | ||
3063 | that was offered/demanded (only in the previous iteration?) and then | ||
3064 | simply SKIP that element ID! --> | ||
3065 | In this moment the peer MUST | ||
3027 | wait for all open offers and demands to be fulfilled, to prevent | 3066 | wait for all open offers and demands to be fulfilled, to prevent |
3028 | retransmission before switching into active decoding operation mode. | 3067 | retransmission before switching into active decoding operation mode. |
3029 | A switch into active decoding mode MUST only be permitted for | 3068 | A switch into active decoding mode MUST only be permitted for |
@@ -3035,9 +3074,12 @@ END FUNCTION | |||
3035 | <t> | 3074 | <t> |
3036 | A check needs to be in place that prevents receiving an inquiry | 3075 | A check needs to be in place that prevents receiving an inquiry |
3037 | for an element multiple times or more inquiries than are plausible. | 3076 | for an element multiple times or more inquiries than are plausible. |
3077 | <!-- FIXME: how again does one determine how many inquiries are plausible? | ||
3078 | Be precise! I can see several options (overall set sizes, but also | ||
3079 | SE, or even IBF size). --> | ||
3038 | The sending and receiving of <em><xref target="messages_inquiry" format="title" /></em> messages should | 3080 | The sending and receiving of <em><xref target="messages_inquiry" format="title" /></em> messages should |
3039 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> | 3081 | always be protected with an <xref target="security_generic_functions_mfc" format="title" /> |
3040 | to secure the protocol against missing, doubled, not in order or unexpected messages. | 3082 | to secure the protocol against missing, duplicated, out-of-order or unexpected messages. |
3041 | </t> | 3083 | </t> |
3042 | </dd> | 3084 | </dd> |
3043 | <dt><xref target="messages_demand" format="title" /></dt> | 3085 | <dt><xref target="messages_demand" format="title" /></dt> |
@@ -3067,11 +3109,11 @@ END FUNCTION | |||
3067 | <name>Finish Waiting</name> | 3109 | <name>Finish Waiting</name> |
3068 | <t> | 3110 | <t> |
3069 | In the <strong>Finish Waiting</strong> state the protocol waits for | 3111 | In the <strong>Finish Waiting</strong> state the protocol waits for |
3070 | all sent demands to be fulfilled. | 3112 | all transmitted demands to be fulfilled. |
3071 | </t> | 3113 | </t> |
3072 | <t> | 3114 | <t> |
3073 | In case not all sent demands have been answered in time, the operation | 3115 | In case not all transmitted demands have been answered at this time, the operation |
3074 | has failed and MUST be terminated. | 3116 | has failed and the protocol MUST be terminated with an error. |
3075 | </t> | 3117 | </t> |
3076 | <t>Security considerations for received messages:</t> | 3118 | <t>Security considerations for received messages:</t> |
3077 | <dl> | 3119 | <dl> |
@@ -3079,7 +3121,7 @@ END FUNCTION | |||
3079 | <dd> | 3121 | <dd> |
3080 | When receiving <xref target="messages_elements" format="title" /> messages it is important | 3122 | When receiving <xref target="messages_elements" format="title" /> messages it is important |
3081 | to always check the <xref target="security_generic_functions_mfc" format="title" /> | 3123 | to always check the <xref target="security_generic_functions_mfc" format="title" /> |
3082 | to secure the protocol against missing, doubled, not in order or unexpected messages. | 3124 | to secure the protocol against missing, duplicated, out-of-order or unexpected messages. |
3083 | </dd> | 3125 | </dd> |
3084 | </dl> | 3126 | </dl> |
3085 | </section> | 3127 | </section> |