Subject: [6lo] Alissa Cooper's No Objection on draft-ietf-6lo-ap-nd-17: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Tue, 04 Feb 2020 08:33:17 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-6lo-ap-nd-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

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

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

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Feb 2020 13:13:43 +0000

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.

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.

-------------------

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

"

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

 Again, many thanks for your time and your review!

Pascal

> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 6 Feb 2020 08:42:14 -0500

> On Feb 5, 2020, at 8:13 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Alissa
> 

Ok.

> “

Sounds good.

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 14:59:49 +0000

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

 I came to the same conclusion; please consider the text I added in v-19, cf. my response to Roman, quoting below:

----------

This seems to match Benjamin's direction as well. Maybe:

"
   Crypto-Type:  8-bit unsigned integer.  The type of cryptographic
      algorithm used in calculation Crypto-ID indexed by IANA in the
      "Crypto-Type Subregistry" in the "Internet Control Message
      Protocol version 6 (ICMPv6) Parameters" (see Section 8.3).
"

This discussion is related to the points Benjamin and Alissa made on "IESG Approval" in the IANA section "
   Assignment of new values for new Crypto-Type MUST be done through
   IANA with either "Specification Required" or "IESG Approval" as
   defined in BCP 26 [RFC8126].
"
The goal behind that is to enable the addition of Crypto-Types without the need of an RFC as long as the IANA registry contains enough information to use this specification as is for the new crypto type.
Suggestion to add after the text cited above:

"
   The "Defining specification" column indicates the document that
   defines the length and computation of the digital signature, which
   could be this for values defined through "IESG Approval".
"

-------------------

Does that help? 

Pascal