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

Warren Kumari <warren@kumari.net> Fri, 21 February 2020 16:35 UTC

Return-Path: <warren@kumari.net>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C249A12089E for <6tisch@ietfa.amsl.com>; Fri, 21 Feb 2020 08:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NgywQ_PM4Nq for <6tisch@ietfa.amsl.com>; Fri, 21 Feb 2020 08:35:25 -0800 (PST)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92491208E3 for <6tisch@ietf.org>; Fri, 21 Feb 2020 08:35:24 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id 134so251587qkl.6 for <6tisch@ietf.org>; Fri, 21 Feb 2020 08:35:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JW9GkGuixoVH5c0bQHGrwhDToGzXhAjbiudIsHA0QSs=; b=i/ia0gu6YwPFLdLZySPI2QRyXaNvaO+jLEwsjIXgGrKu021oSiEc1EVx21ZSn/d+fw EJtp2rGt/jFvAAjUi4lpIyfIO97OOAC4HPcXcUjLgw3Qdlq1eE6zp6YUHGH7sTrbeVKC d6UWtQMcNwpzWTs1h3P4JKvoAQBXg8sRz5bAtbcLGPC//zZBLMDjndFu7r9o/bbK/QCh 97yNYCEkIiQP9rE+GuUVOnTKmtGZgh5b8YL3qf+z9QQbF/8++AtQ18pIfwS7J503or8v YnWwPk0/zN0qMhwMIGMdvW1bRMNdX2l5KmElwWV49pquFwtH9dEEUiWYCIhD/hVgZy+b YKCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JW9GkGuixoVH5c0bQHGrwhDToGzXhAjbiudIsHA0QSs=; b=gTRh6y4IHxRaO01xy/L26SD/mMAUp0VuZEUQS5PhEwBGTe08XLXKUpDzEwaSEQKrhr sAzfjXqcOeWs6CPfdYb52svJLFZBDHUfBDNAA2kl+oQAUHj4TqVWHyXP9iiZSNcuDOd+ Mw8ZtcUlUQzJOYtn0vZM1UIZRk0ndiwUdAYoRZ+B+tIwFcI0aKmUsbFjhj58NLHqM2QF M6M0s7i4T7Qe0HU1HlujUAVMWqNoDNua3fs76OqtviSEV/aL6nFG9HSy8mMUjl29anbE qSG3C1IP0mLII3hXMFnK0SiGh0pSqzxZA1R/lc1QI6OsfcTcAfO4VlCtN2QqhQJQsUsj Nmuw==
X-Gm-Message-State: APjAAAVZEoKoUtLWUeV/XovcJHhnCa1/KeQERF4b39yFcYkzJ9jSngEe Pqb/q4ETD1RGu0gx7m65e34tsU5Rdu0eQ/xkkz6S5w==
X-Google-Smtp-Source: APXvYqxYY3Hzj+4eY5ztyOrfS0dmRIisvF3nZnd4+0nbYXtx54L9Ue/X9dl5VUNgfplK08GfFIISFFYkMHIWL2vW+Hg=
X-Received: by 2002:a37:84e:: with SMTP id 75mr34912216qki.192.1582302923659; Fri, 21 Feb 2020 08:35:23 -0800 (PST)
MIME-Version: 1.0
References: <158215024778.17684.13698521401379090423.idtracker@ietfa.amsl.com> <2595.1582224894@dooku> <CAHw9_iJQS=p4u0vNsDg1XC4yKCBsAs15T2U38v9rcfxpN4VA-w@mail.gmail.com>
In-Reply-To: <CAHw9_iJQS=p4u0vNsDg1XC4yKCBsAs15T2U38v9rcfxpN4VA-w@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 22 Feb 2020 03:35:12 +1100
Message-ID: <CAHw9_iJ6qL-DPjXBLCkgdHLFr09Fu-JXZyZ-EPwbX1yYJ9V-Xw@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: 6tisch@ietf.org, 6tisch-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org, pthubert@cisco.com
Content-Type: multipart/alternative; boundary="000000000000b12999059f189b38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/RQQMbZHolCEHaWgRAUCgwGoMVIQ>
Subject: Re: [6tisch] Warren Kumari's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 16:35:32 -0000

On Sat, Feb 22, 2020 at 3:31 AM Warren Kumari <warren@kumari.net> wrote:

>
>
> On Fri, Feb 21, 2020 at 11:39 PM Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
>
>> Warren Kumari via Datatracker <noreply@ietf.org> 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 <mcr+IETF@sandelman.ca>ca>, 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