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

[Miika Komu <[e-mail]>]

Hi,

ma, 2018-05-21 kello 17:52 -0700, Spencer Dawkins kirjoitti:
> 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 agree that "similar" is very ambiguous. I have removed the sentence
"In doing so, the main goal is to still deliver similar security
properties to HIPv2" from the abstract (as suggested offline by Eric
Vyncke). I hope this resolves your comment?

> 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.

the sentence has been removed from the abstract, I hope this point is
also moot now.

> 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".

you are correct, fixed.

> 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.

many of the SHOULDs are inherited from the text in RFC7401. If you
really want to, I can do a side by side comparison and check which ones
are really new, and then improve the new ones? With my current
priorities at work, this will unfortunately take a lot of time. Another
way to resolve your comment is to add some general statement about the
SHOULDs in the specification.

> 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 removed the second sentence (I think it was a bit redundant anyways).
I hope this resolves your comment.

I also changed "computation" to "computational".

> 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?

I agree, off-path attacker is more relevant here. Changed the text as
follows:

As an off-path adversary could also send such
   an ICMP packet with the aim to prevent the HIP DEX handshake from
   completing, the Initiator SHOULD NOT react to an ICMP message before
   retransmission counter reaches I1_RETRIES_MAX in its state machine
   (see Table 3 in [RFC7401]).