> On Feb 5, 2020, at 8:13 AM, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello Alissa > > Many thanks for your review ! > > I committed the proposed changes as -18 so you can review them in the final > version, but we can certainly adapt and do more, see > https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18 . Note that the > commit also adds text to answer a DISCUSS by Benjamin. > > Please see below for the discussion: > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 4.4: >> >> "If it is >> not present, it can be found in an abstract table that was created by >> a previous message and indexed by the hash." >> >> Reading the document top to bottom, I was confused about what this was >> referencing when I first came across it. Given that this is explained later, >> a >> forward section reference might help. > > Probably a lack of clarity in the first sentence of that section. Added "as > hash" in: > > " > As opposed to the RSA Signature Option (RSAO) defined in section 5.2. > of SEND [RFC3971], the NDPSO does not have a key hash field. > Instead, the leftmost 128 bits of the ROVR field in the EARO are used > as hash to retrieve the CIPO that contains the key material used for > signature verification, left-padded if needed. > " > > I shared that impression when rereading but moving the sentence you quote up > right below the above would have cut another logical chain and created the > same problem.
Ok. > > > ------------------- > >> Section 7: >> >> I think somewhere in here there should be a brief discussion about how use of >> this specification could facilitate correlation attacks by providing an >> identifier >> that allows traffic from multiple source addresses to be tied back to the >> same >> node via the Crypto-ID. That is, if a node intends to use multiple addresses >> to >> defend against the 6LR or being able to correlate traffic originating with >> each >> address, it should not use the mechanism specified in this document. (I'm >> assuming this is a corner case for these kinds of deployments but it's worth >> saying anyway. Also, if there is some other cross-address identifier that >> the 6LR >> always has anyway, this isn't actually a >> problem.) > > I believe I see your point, and there's more to it: > > If you look at the definition of the Modifier in section 4.3, this is > explicitly why we introduced it. > See also the thread with Benjamin about selecting the right size for that > information. > > " > Modifier: 8-bit unsigned integer. Set to an arbitrary value by the > creator of the Crypto-ID. The role of the modifier is to enable > the formation of multiple Crypto-IDs from a same key pair, which > reduces the traceability and thus improves the privacy of a > constrained node that could not maintain many key-pairs. > " > > Proposal is to add: > " > 7.7. Correlating Registrations > > The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 > field of the ARO defined in [RFC6775]. One of the drawbacks of using > an EUI-64 as ROVR is that an attacker that is aware of the > registrations can correlate traffic for a same 6LN across multiple > addresses. Section 3 of [RFC8505] indicates that the ROVR and the > address being registered are decoupled. A 6LN may use a same ROVR > for multiple registrations or a different ROVR per registration, and > the IID must not derive from the ROVR. In theory different 6LNs > could use a same ROVR as long as they do not attempt to register the > same address. > > The Modifier used in the computation of the Crypto-ID enables a 6LN > to build different Crypto-IDs for different addresses with a same > keypair. Using that facility improves the privacy of the 6LN as the > expense of storage in the 6LR, which will need to store multiple > CIPOs that contain the same private key. Note that if the attacker > is the 6LR, then the Modifier alone does not provide a protection, > and the 6LN would need to use different keys and MAC addresses in an > attempt to obfuscate its multiple ownership. > > “ Sounds good. > >> >> Section 8.3: >> >> Are there protocol-specific reasons why "IESG Approval" is a valid >> registration >> policy for this registry? Specification Required on its own seems >> appropriate to >> me. >> > > See also the discussion with IANA and Benjamin. The idea is that if someone > wants to add a curve or a hash function, but following the method in this > draft. Do we really need an RFC or is the IANA registry the reference? The > idea is that the IESG should be able to determine that the new curve provides > benefits without the need for an RFC. Do we have it wrong? I see. Perhaps adding a few words to the document to indicate the circumstances under which each registration policy might be expected to be used would help. Thanks, Alissa > > Again, many thanks for your time and your review! > > Pascal > > > >> >> _______________________________________________ >> 6lo mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
