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 <nore...@ietf.org> > > 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 _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
