Ballot deferred by Terry Manderson on 2018-05-09.
Summary: Needs 4 more YES or NO OBJECTION positions to pass.
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."
Just parking partial comments - I was reviewing this doc when it was deferred. I'll be back. 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?