Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Mališa Vučinić <[e-mail]>]

I’ve just published -15 incorporating the remaining feedback from your COMMENT points. I also moved RFC5869 to normative references, we forgot to do this in the previous revision. Take a look and let me know if you see anything out of the ordinary.

Mališa

> On 9 Dec 2019, at 19:21, Benjamin Kaduk <[e-mail]> wrote:
> 
> Whoops, this got lost in my inbox; thanks for the (out-of-band) reminder.
> Luckily, basically all of it is include in the -14 and looks good, so I
> have very little left to say :)
> 
> On Thu, Nov 07, 2019 at 05:23:37PM +0100, Mališa Vučinić wrote:
>> 
>> Many thanks for the in-depth review. In this email I am responding inline to most of the COMMENT points, in order to converge on those first. For the rest, I created bitbucket issues that we will discuss as part of the WG meeting in Singapore and get back to you.
>> 
>> The resulting changes discussed here can be found at:
>> 
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6>
>> 
>> The list of remaining issues is available at:
>> 
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open>
>> 
>> Mališa
>> 
>> 
>>> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
>> …
>> 
>>> Section 10
>>> 
>>>  scanning and device-specific vulnerability exploitation.  Since the
>>>  join process occurs rarely compared to the network lifetime, long-
>>>  term threats that arise from using EUI-64 as the pledge identifier
>>>  are minimal.  In addition, the Join Response message contains a short
>>> 
>>> I suspect I just failed to internalize things properly, but isn't the
>>> pledge identifier used with the network IPv6 prefix to form the global
>>> IPv6 address of the joined node?  So in that sense, using the EUI-64 as
>>> the pledge ID transfers into the long-lived address and the privacy
>>> threats are long-term as well.
>> 
>> Not necessarily. If the short identifier is returned as part of the join, the pledge can configure its IPv6 address using that. 
> 
> But it might happen sometimes?  We could probably still mention the privacy
> consideration for that case.
> 
>> 
>>> 
>>>  Once the join process completes, the new node uses the short
>>>  addresses for all further layer 2 (and layer-3) operations.  This
>>> 
>>> My understanding is that this is the usual case but not strictly
>>> required by any protocol spec.
>> 
>> That’s correct, we don’t go into this sort of configuration description in minimal-security.
> 
> (I was trying to say that "the new node uses the short address for all
> further" is declarative, but may not be 100% true.  That said, this is only
> a COMMENT, so I'm not going to follow up on anything.)
> 
>>> 
>>>  reduces the aforementioned privacy risks as the short layer-2 address
>>>  (visible even when the network is encrypted) is not traceable between
>>>  locations and does not disclose the manufacturer, as is the case of
>>> 
>>> Why is it not traceable between locations?
>> 
>> Because the assumption is that each network will assign a different short identifier to the pledge, with the identifiers being uncorrelated among networks and therefore not traceable. Does that make sense?
> 
> Ah, I was reading this as being different locations within the same
> network.  If different locations necessitate different networks, then I
> agree.
> 
>>> Section 13.2
>>> 
>>> I agree with Barry that RFC 8505 is probably more appropriately
>>> categorized as a normative reference, and further suggest doing so for
>>> draft-ietf-core-stateless, IEEE802.15.4, and RFC 5869.
>> 
>> 
>> Done by Michael on another thread.
> 
> (I didn't find discussion of RFC 5869, but may have been sloppy in my
> search.)
> 
> Thanks!
> 
> -Ben