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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 14:10:47 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ 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?

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 :-)

----------------------------------------------------------------------
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.... :-)

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 19:54:54 +0100

Warren Kumari via Datatracker <[email-masked]> 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.

    > 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.

    > 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.

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Feb 2020 08:46:00 -0500

> which has some useful questions / nits.

I have read this, and I believe that I have dealt with all issues raised.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 22 Feb 2020 03:31:33 +1100

> 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...

W

>     > (
> https://datatracker.ietf.org/doc/review-ietf-6tisch-enrollment-enhanced-beacon-08-opsdir-lc-wu-2020-01-21/
> ),
-- 
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

---

From: Warren Kumari <[email-masked]>
Date: Sat, 22 Feb 2020 03:35:12 +1100

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

> 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 found some bits, and cleared.
Thank you,
W

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.