Re: [6tisch] Warren Kumari's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

On Sat, Feb 22, 2020 at 3:31 AM Warren Kumari <[e-mail]> wrote:

>
>
> On Fri, Feb 21, 2020 at 11:39 PM Michael Richardson <[e-mail]>
> wrote:
>
>> Warren Kumari via Datatracker <[e-mail]> wrote:
>>     > [ Be ye not afraid - this should be easy to answer / address ] The
>>     > Privacy Considerations says: "The use of a network ID may reveal
>>     > information about the network."  Good point - but it also goes on to
>>     > say: "The use of a SHA256 hash of the DODAGID, rather than using the
>>     > DODAGID (which is usually derived from the LLN prefix) directly
>>     > provides some privacy for the the addresses used within the
>> network, as
>>     > the DODAGID is usually the IPv6 address of the root of the RPL
>> mesh."
>>
>>     > I don't know if this is an issue, but how much entropy is in a
>> DODAGID?
>>     > From what I could find, the DODAGID is often just an IP address -
>> and
>>     > subnets are not randomly distributed, nor are L2 addresses (inputs
>> to
>>     > address generation) - if I know that many of the nodes come from
>>     > vendor_A, and I know their L2 / MAC range, can I enumerate this,
>> and by
>>     > extension the DODAGID, and so the hash?
>>
>> The point of a good hash is to spread whatever entropy there is in the
>> input
>> all over the output.   If there are a very few number of inputs, then
>> akin to
>> the /etc/passwd dictionary attacks, an attacker can just pre-calculate a
>> bunch of things.
>>
>> So, can you enumerate the DODAGIDs?  Maybe.
>>
>> The 6LBR address which is usually used as the DODAGID is an IPv6 address.
>> So there is some ~32-bits of space assuming that the RIR assigned prefix
>> (e.g. 2001:db8::/32) is discoverable by looking up www.example.com
>> This assumes that you know who you are trying learn about.
>> The next 32-bits will be operator or DHCPv6-PD assigned, and maybe not
>> guess
>> that part.  And then the IID could be assigned via any number of our
>> RFC8064,
>> or might be ::1.
>>
>> So if you know what network you are looking for, you can probably find it.
>> The operator is allowed to generate the NetworkID with a random number
>> generator, btw.
>>
>> But, if you observe ten LLNs the hash makes it hard to trivially map them
>> back to a specific operator.
>>
>> Do you feel that I need to add this to the document?
>> I feel that it distracts: SHA256 is just a suggestion.
>
>
> Fair ‘enough; I just wanted to make sure y’all had considered it. I think
> a single sentence noting the above would be helpful, but that’s just an
> opinion.
>
> I’m at an airport, will clear my position when I have more bits...
>


I found some bits, and cleared.
Thank you,
W


> W
>
>
>
>>
>>     > I will happily admit that I haven't fully researched this / thought
>> it
>>     > through, so "Nah, won't work" or "Yes, will work, but we did say
>>     > 'provides some privacy', not 'absolute privacy'" or all acceptable
>>     > answers :-)
>>
>> Some privacy.
>>
>>     >
>> ----------------------------------------------------------------------
>>     > COMMENT:
>>     >
>> ----------------------------------------------------------------------
>>
>>     > I found this document to be well written, and helpfully explained
>> the
>>     > background, issue, etc. Thank you!
>>
>>     > Question: "Pledges which have not yet enrolled are unable to
>>     > authenticate the beacons, and will be forced to temporarily take the
>>     > contents on faith. After enrollment, a newly enrolled node will be
>> able
>>     > to return to the beacon and validate it."  Yes, this is true - a
>> newly
>>     > enrolled node will be able to do this -- but I don't see a
>> suggestion /
>>     > requirement that they actually *do* so. I'm perfectly capable of
>>     > picking up my socks, but.... :-)
>>
>> You want to read draft-ietf-6tisch-minimal-security section 5 and section
>> 9,
>> last paragraph.
>> Doing so is somewhat optional: if the pledge doesn't verify the beacon it
>> saw
>> then it will verify the next beacon.
>> If the beacon was bogus, then the 6tisch-CoJP likely also failed, or the
>> pledge won't get to the Join Proxy at all, since it will not have a
>> workable
>> TSCH schedule.
>>
>>     > Nit: "Although However, even in this case, a" - typo / redundancy.
>>
>>     > Please also see Qin Wu's Opsdir review
>>     > (
>> https://datatracker.ietf.org/doc/review-ietf-6tisch-enrollment-enhanced-beacon-08-opsdir-lc-wu-2020-01-21/
>> ),
>>     > which has some useful questions / nits.
>>
>> I thought I had, but I don't have anything in my outbox, so I'll grab it
>> when
>> I land.
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf