Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)
Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 26 June 2019 12:27 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556E412013A; Wed, 26 Jun 2019 05:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srdLFn6VRRmf; Wed, 26 Jun 2019 05:27:21 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [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 ietfa.amsl.com (Postfix) with ESMTPS id C0B241200FA; Wed, 26 Jun 2019 05:27:20 -0700 (PDT)
Received: from [129.192.10.2] (helo=[164.48.135.199]); authenticated by wp513.webpack.hosteurope.de 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 <ietf@kuehlewind.net>
In-Reply-To: <7934deefa772f778146bc401006c5635afdfaf75.camel@ericsson.com>
Date: Wed, 26 Jun 2019 14:27:17 +0200
Cc: "iesg@ietf.org" <iesg@ietf.org>, "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, "hip-chairs@ietf.org" <hip-chairs@ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B08DCA9-B1B1-4EAF-9A7A-04DE2C6600A2@kuehlewind.net>
References: <152695036709.7650.1412062169882723188.idtracker@ietfa.amsl.com> <7934deefa772f778146bc401006c5635afdfaf75.camel@ericsson.com>
To: Miika Komu <miika.komu@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1561552040;57c71b6d;
X-HE-SMSGID: 1hg71C-0005By-Hv
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/NNBVjhUhJcmnsTyBq1yVrJwXXug>
Subject: Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=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! Mirja > On 19. Jun 2019, at 14:14, Miika Komu <miika.komu@ericsson.com> 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 >> 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]).
- [Hipsec] Spencer Dawkins' No Objection on draft-i… Spencer Dawkins
- Re: [Hipsec] Spencer Dawkins' No Objection on dra… Miika Komu
- Re: [Hipsec] Spencer Dawkins' No Objection on dra… Mirja Kuehlewind