[secdir] Secdir last call review of draft-ietf-hip-dex-06

[David Waltermire <[e-mail]>]

Reviewer: David Waltermire
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is Ready with issues.

In general this document is clearly-written and well-organized. It was a fun
read overall.

I have the following concerns with the draft:
-----------------------------------------------------------

Section 2.1:

You should use text from RFC8174 to indicate that lowercase versions of the
keywords are not normative.

Something like the following would work:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Section 4.1.3.1:

"it can be long-lived with no need for rekeying" Small is open to
interpretation. It would be useful to include some guidance on the expected
amount of data to be exchanged before rekeying would be needed, or why this is
a practical impossibility.

Section 5.3.2 and 5.3.3:

In the paragraph on TRANSPORT_FORMAT_LIST, it would be good to document the
specific ESP parameter value to be used from:
https://www.iana.org/assignments/hip-parameters/hip-parameters.xml#transport-modes.
This will remove any ambiguity.

Section 6.6:

In items #5 and #6, what is "an acceptable time span"? Some guidance here would
be helpful. I believe this is discussed earlier in the draft. Perhaps a
reference back may provide some clarity?

Section 6.9:

In #1, under what circumstances would the NOTIFY packet not be dropped
silently? Why is this not a MUST? Some explanation would be useful here. In
general, many of the SHOULDs in the section 6 subsections, could use further
justification.

Section 8:

What is "a reasonable delta time"? Some guidance here would be useful.

Section 9 (Security Considerations):

"The puzzle mechanism using CMAC may need further study regarding the level of
difficulty." Study of what? Is the concern here that the impact on constrained
devices at a higher level of difficulty is not well understood? Or is this
concern around identifying best practices around raising the difficulty under
specific conditions? A sentence or two on this would be helpful for the reader
to better understand the issue.

I don't see a mention of the non-protected Host Identity issue from section 1.1
here.

With regards to the 4th bullet, the text in section 3 should be referenced
regarding HIT collisions. (nit)-> Referencing back to the relevant sections for
the other bullets may also be useful.

>From section 5.3.1, I don't see a mention of the issues around dealing with I1
storms addressed here.

Section 10:

It can be useful for IANA to reference the specific registry by name and URL in
the IANA considerations. It can also be useful to include the actual table in
the IANA considerations section. These are embedded in section 5 in the current
document. Suggest moving these tables to the IANA consideration section.

I found the following nits in the draft:
-------------------------------------------------

Section 1.1:

In the text "any signaling that indicates such anonymity should be ignored" it
would be useful to provide an example of such signaling.

/may carry data payload/may carry a data payload/

The packets are referred to as 1st, 2nd, 3rd, and 4th here, and as I1, R1, I2,
and R2 in section 4. Consider use a consistent naming approach throughout this
document to improve clarity.

Section 1.2:

Section 8 is not included in this summary. Suggest adding a sentence about it.

(nit) Section 10 is not linked as well.

Section 2:

/Terms and Definitions/Terms, Notation, and Definitions/

Section 3:

"other methods are used to map the data packets to the corresponding HIs" What
are these other methods? What if ESP is not used and the SPI is not an option?

Section 4.1.2.3:

In the diagram, I think there is a missing arrow between I2-SENT and R2-SENT.
Please double check. Also, this diagram is far from simple. Maybe name this
section "HIP State Diagram"?

Section 4.1.3.2:

"Even though this input" Please clarify the "this" indefinite article.

Section 4.1.4:

/This will limit state/Using non-volatile storage will limit state/

This section should reference section 6.11, since some of the content is
duplicated there.

Section 5.2.3:

/It is defined in/The HOST_ID parameter is defined in/

Section 5.2.5:

/at least 64 bit/at least 64 bits/

Update the reference "#I and the puzzle solution #J (see [RFC7401])" to point
to section 4.1.2 in RFC7401.

Section 5.3.2:

The discussion of difficulty K touches on a local policy issue that is
discussed in section 7. It could be useful to reference section 7 from here.

Update "(see [RFC7401])" to point to section 4.1.2 in RFC7401.

/based on which it chose the ECDH/based on which the Responder chose the ECDH/

Regards,
David Waltermire