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

Mirja Kuehlewind <> Wed, 26 June 2019 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 556E412013A; Wed, 26 Jun 2019 05:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id srdLFn6VRRmf; Wed, 26 Jun 2019 05:27:21 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0B241200FA; Wed, 26 Jun 2019 05:27:20 -0700 (PDT)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hg71C-0005By-Hv; Wed, 26 Jun 2019 14:27:18 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Wed, 26 Jun 2019 14:27:17 +0200
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Miika Komu <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1hg71C-0005By-Hv
Archived-At: <>
Subject: Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jun 2019 12:27:24 -0000

Hi Miika,

Thanks for addressing these comments. Spencer is not serving in the AD role anymore, so I had a quick look at your feedback and believe this all looks good!

Regarding the question about SHOULDs: I don’t think it is necessary to go back and compare to RFC7401, however, a less time consuming effort could be to grab for all SHOULDs and shoulds and double-check if a) normative or non normative language should be used and b) if any clarification can or should be added to why this is a SHOULD and not a MUST. However I leave it to you (and the responsible AD) to make the final decision here!


> On 19. Jun 2019, at 14:14, Miika Komu <> wrote:
> 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 
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> -------------------------------------------------------------------
>> ---
>> -------------------------------------------------------------------
>> ---
>> 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
>>   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]).