Re: [Drip] 64bit comments on draft-moskowitz-drip-uas-rid-06.txt

[Robert Moskowitz <[e-mail]>]

On 9/16/20 4:42 AM, Alexandre Petrescu wrote:
>
>
> Le 15/09/2020 à 18:21, Card, Stu a écrit :
>> Musings...
>>
>> I actually worry about driving the probability of hash collision too 
>> low:
>
> We can drive the probability of hash collisions up by reducing the 
> prefix size, and implicitly increasing the IID size, from 64 to 65 for 
> example.

The hash size will most likely be on nibble boundaries.  So 64 or 68 or 72.

>
> Alex
>
>  having dealt with too many software development managers, I am
>> certain that some of them will dismiss very low probability 
>> collisions as not worth costly programmer time to address. :-(
>>
>> I am more interested in expanding the HIT Suite / OGA ID to provide 
>> greater crypto agility, to deal with future actual or feared 
>> compromise (inc. by quantum methods) of current cryptosystems.
>>
>> We could also consider a 3 level or flexible hierarchy, although this 
>> would be more challenging WRT parsing structure w/variable length 
>> fields.
>>
>> On Tue, Sep 15, 2020, 9:59 AM Robert Moskowitz 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     On 9/13/20 7:39 PM, Stuart W. Card wrote:
>>>     Although I know how variable encodings create work for programmers,
>>>     which means more opportunities for error, I would love to be 
>>> able to
>>>     expand some of these fields if IANA were to give us a shorter 
>>> prefix =>
>>>     larger space.
>>
>>     I did some sketches and then some calculations.
>>
>>     Prefix size    Hash size    .01% coll.    1% coll.
>>
>>     28            64            63M        663M
>>     24           68            250M       2.5B
>>     20           72            1B          10B
>>
>>     And remember, this is for a single HDA.
>>
>>     A /28 is OK, but that would mean expect collisions for some HDAs and
>>     reuse over time.
>>
>>     With a /20, it will be the exceptional HDA that needs to deal with
>>     collisions unless HHITs are never removed.  FedEx and UPS could
>>     easily re-ID each of their UAs everyday for years.  even for each
>>     delivery.
>>
>>     I don't think I will have time to rework the draft before the
>>     Interim.  I have too much to do for ICAO as well.  Plus the Holidays
>>     start this weekend.  But I will look at how to rework the draft for
>>     differing prefix and hash sizes.
>>
>>>     On 9/9/2020 9:20 AM, Robert Moskowitz wrote:
>>>>     Alex,
>>>>
>>>>     Interesting recommendation.  I am going to 'park' this comment 
>>>> and see
>>>>     what others say.  For now I will leave things as is. Variable 
>>>> encoding
>>>>     has to be decoded.  How do I designate that in the HHIT?  Needs 
>>>> lots of
>>>>     thought.
>>>>
>>>>     Bob
>>>>
>>>>     On 9/9/20 9:14 AM, Alexandre Petrescu wrote:
>>>>>     I would like to suggest that the draft uses a variable-length 
>>>>> stance
>>>>>     when needing to talk about limits within addresses.
>>>>>
>>>>>     E.g. instead of hardcoding a 64bit limit in an ORCHID hash, 
>>>>> rather
>>>>>     make it variable: be it 65, or 35bit hash.
>>>>>
>>>>>     'Pre-image' - yes, attacks.  I must say that I do not know 
>>>>> what it
>>>>>     means.  Maybe one knows that better.
>>>>>
>>>>>>       A HHIT is built from the following fields:
>>>>>>
>>>>>>         *  28 bit IANA prefix
>>>>>>
>>>>>>         *  4 bit HIT Suite ID
>>>>>>
>>>>>>         *  32 bit Hierarchy ID (HID)
>>>>>>
>>>>>>         *  64 bit ORCHID hash
>>>>>     Consider that SLAAC might put a 65 plen in an RA, at which 
>>>>> point the
>>>>>     Drone might need to form an IID of length different than 64, 
>>>>> which
>>>>>     might need to contain an ORCHID.  That ORCHID is probably not of
>>>>>     length 64.
>>>>>
>>>>>     This is what I think I am suggesting.
>>>>>
>>>>>     I am aware that if one wants to do this non-64 ORCHID then it 
>>>>> might
>>>>>     probably need to modify many other Identity and ORCHID RFCs, 
>>>>> and that
>>>>>     other parts of this I-D might also contain 64bit limits (that 
>>>>> I think
>>>>>     of as artificial).  Still, I think I am suggesting it that way...
>>>>>
>>>>>     Alex
>>>>>
>>>>>
>>>
>>
>>     --     Robert Moskowitz
>>     Owner
>>     HTT Consulting
>>     C:__ __248-219-2059
>>     F:__ __248-968-2824
>>     E:__ [e-mail] <mailto:[e-mail]>
>>
>>     There's no limit to what can be accomplished if it doesn't matter
>>     who gets the credit
>>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit