HIP Diet EXchange (DEX)
draft-ietf-hip-dex-24

Please also see Qin Wu's OpsDir review at: https://datatracker.ietf.org/doc/review-ietf-hip-dex-06-opsdir-lc-wu-2018-02-23/

I only have one (minor) comment -- I found the last sentence of the Abstract jarring / incomplete.

I'd suggest:
"The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions, while still delivering similar security properties to HIPv2."

I'm not an expert on what people expect about security, but I'm wondering if there's a little too much distance between this text in the Abstract,

  This document specifies the Host Identity Protocol Diet EXchange (HIP
   DEX), a variant of the Host Identity Protocol Version 2 (HIPv2).  The
   HIP DEX protocol design aims at reducing the overhead of the employed
   cryptographic primitives by omitting public-key signatures and hash
   functions.  In doing so, the main goal is to still deliver similar
   security properties to HIPv2.

and this text in the Introduction,

  The main differences between HIP BEX and HIP DEX are:

(snip)

  2.  HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of
       HIPv2 due to the removal of the ephemeral Diffie-Hellman key
       agreement.

Would the average reader consider "no PFS" to be similar to PFS?

(Please note that I'm not questioning the choice made in DIX, only the way that choice is described in the Abstract)

I'm curious about whether a couple of other differences named in the Introduction would also qualify as similar, but let's start with PFS.

I'm also curious about whether 

1.1.  The HIP Diet EXchange (DEX)

(snip)

   HIP DEX does not have the option to encrypt the Host Identity of the
   Initiator in the 3rd packet.  The Responder's Host Identity also is
   not protected.  Thus, contrary to HIPv2, HIP DEX does not provide for
   end-point anonymity and any signaling that indicates such anonymity
   should be ignored.

qualifies as "similar", but I don't have a good sense of how much this matters in current and expected HIP deployments.

I'm hardly the smart one about this, but is 

  o  HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2.
      Consequently, if an HI is compromised, all HIP connections
      protected with that HI are compromised.

correct? I was expecting to see something like "if an HI is compromised, all previous HIP connections protected with that HI are compromised". 

The version of this draft I'm reviewing has 57 occurrences of the word "should". I'm not seeing very many cases where the surrounding text explains why an implementation would not do what it SHOULD do, and I'm not seeing many cases where the surrounding text explains what the peer implementation should do, if the other endpoint doesn't do what it SHOULD do, although many of those cases might be captured in the state diagrams in the document. 

In this text,

  By eliminating the need for public-key signatures and the ephemeral
   DH key agreement, HIP DEX reduces the computation, energy,
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   transmission, and memory requirements for public-key cryptography
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   (see [LN08]) in the HIPv2 protocol design.  Moreover, by dropping the
   cryptographic hash function, HIP DEX affords a more efficient
                                        ^^^^^^^^^^^^^^^^^^^^^^^^
   protocol implementation than HIP BEX with respect to the
   ^^^^^^^^^^^^^^^^^^^^^^^
   corresponding computation and memory requirements.

is "efficient" the right word, in the second sentence? This seems to mirror that "reducing requirements" effect from the first sentence - I'd assume that if you were comparing efficiencies, you'd be comparing two things with equivalent functionality.

I'm sure I'm not reading this correctly, but in this text

  In the second case, the HIP DEX implementation (Responder) inspects
   the Initiator's HIT on reception of an I1 packet.  If the OGA ID
   field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP
   DEX implementation cancels the handshake and sends an ICMP packet
   with type Parameter Problem, with the Pointer pointing to the source
   HIT, to the Initiator.  As an adversary could also send such an ICMP
   packet in a man-in-the-middle attack with the aim to prevent the HIP
               ^^^^^^^^^^^^^^^^^
   DEX handshake from completing, the Initiator SHOULD NOT react to an
   ICMP message after sending the I1 until a reasonable delta time to
   get the real Responder's R1 HIP packet.

I would have thought that this was a good plan to defend against an off-path attacker, because ICMP is helpfully unauthenticated, and if you were on-path (so, man-in-the-middle), you'd probably be doing things that were much more aggressive (like trying to impersonate the other end). Am I getting this wrong?