Ballot for draft-ietf-hip-dex
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
This document was deferred by Terry Manderson in May 2018. The authors have taken into account all COMMENTs from the 2018 ballot, changing several parts of the document based on those COMMENTs. The document went successfully through a new IETF last call so I am balloting the approval again in front of the 2019 IESG members. -éric
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?