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:31 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 6837B1208BE for <6tisch@ietfa.amsl.com>; Fri, 21 Feb 2020 08:31:50 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 eM94xc-aeP89 for <6tisch@ietfa.amsl.com>; Fri, 21 Feb 2020 08:31:47 -0800 (PST)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 7B8381208C7 for <6tisch@ietf.org>; Fri, 21 Feb 2020 08:31:45 -0800 (PST)
Received: by mail-qv1-xf36.google.com with SMTP id ff2so1239402qvb.3 for <6tisch@ietf.org>; Fri, 21 Feb 2020 08:31:45 -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=E+lHKgt4KO7br6y2CW9Nf3kpsHzIYDSiu6Ub+XYZjNM=; b=Gq5Lm62UeHOTdoDBAIS3nWM5UCH/w7IeSSjoqMRUtQIehMedodiHuOghtQmzuerDJM ymrIcM0Ojum9eC6KPXDS4EKoNB0tUsl29vms9M64DHwRIWVzjGeuCz3o9VK398RCRXq3 caZlEFfEC/v0+01UWhSqt5E66CExy0fqNNQ5XvTDiVN08WXp9wpUQWHcydYatYrsDkNg F4uoqluepxdvdK04Fv9EGWuuETcZcCGql2L5Trx6A0sYMZnQkm+Wik4hVZC0pWEpnfHb bXpoW2tfa3pyc6oj8C42c3/fYRMNT2vX0DxpGXUzUPyQiAZaptjqf30i0eedkeYmMDkd EZyQ==
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=E+lHKgt4KO7br6y2CW9Nf3kpsHzIYDSiu6Ub+XYZjNM=; b=Yqczz9L+1xLIegoRSVVrPxlgUVfCKDpqgRhcp/A07sV+7QPkDAAFWTMHjFiBT+7iCh bvKoElryyFsjD8Q1yIWLgaGs1LfkG+jwh3AZ9zLqR29Cj8VtKEhDquclEVltSo7lvGf/ DxnbRBV0ehN3YQ7dH6GvV3AM1ZzWrZKs1lk1/sUcK9ShSwN2hjRNaVXID9cKiVpYqiHj CxR4rdo3Sq4cVpEj8U3DTi2ga0UqcO7kdqp3FvzlVvLA/En4ait/iN0vMHLGm8cbIgPM 7fww0LuKHEcU46+dYEhGaaETOrHnCRKBdgpI9wezMhgZcYT+a1y4fyZas6MhoULnLD6n VdiQ==
X-Gm-Message-State: APjAAAW1r7ScbaKUQGLnxLCiP14zSaDXsIMLIIpJy3oaxIxFMuyQ8pHt XBywNb0PyK4ixz+hlVb6vzGaxDExFobkH86bWEYb5Q==
X-Google-Smtp-Source: APXvYqwwSKeIOoqgeuMADO9g1+uuII1C49cOW8WwpZrLC8LZMLBUrML/DiEbYpLLRj3KYN1JnxJGBE1PqhJR4c+JEbc=
X-Received: by 2002:a0c:edc3:: with SMTP id i3mr31495537qvr.29.1582302704234; Fri, 21 Feb 2020 08:31:44 -0800 (PST)
MIME-Version: 1.0
References: <158215024778.17684.13698521401379090423.idtracker@ietfa.amsl.com> <2595.1582224894@dooku>
In-Reply-To: <2595.1582224894@dooku>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 22 Feb 2020 03:31:33 +1100
Message-ID: <CAHw9_iJQS=p4u0vNsDg1XC4yKCBsAs15T2U38v9rcfxpN4VA-w@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="0000000000009d0d4c059f188e5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/Zje7Hl_QCMjzK9_g8pmrRlQq-Gs>
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:31:53 -0000

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

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