[Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-hip-dex-06: 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-hip-dex/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?