Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

Robert Moskowitz <> Thu, 14 January 2021 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CA943A1542; Thu, 14 Jan 2021 07:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.16
X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U_vKnNyAkecr; Thu, 14 Jan 2021 07:07:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D09973A1484; Thu, 14 Jan 2021 07:07:35 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDE00626FC; Thu, 14 Jan 2021 10:07:31 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id RfteQ3-N5eMw; Thu, 14 Jan 2021 10:07:19 -0500 (EST)
Received: from (unknown []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A7BB5622C2; Thu, 14 Jan 2021 10:07:18 -0500 (EST)
To: "Eric Vyncke (evyncke)" <>, "Eric Vyncke (evyncke)" <>, "" <>, "" <>, Miika Komu <>
Cc: Roman Danyliw <>, Eric Rescorla <>, Gonzalo Camarillo <>, "" <>, Benjamin Kaduk <>, Erik Kline <>
References: <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Thu, 14 Jan 2021 10:07:09 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6B155D0C911F05C831FC9912"
Content-Language: en-US
Archived-At: <>
X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:35 -0800
Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...
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: Thu, 14 Jan 2021 15:07:41 -0000

I had hoped to get -23 out end of last week, and missed my cutoff. I am 
now in IACR's Real World Crypto, where I have gotten a couple pointers 
for DRIP work.

I was waiting for two analyzes that I got Jan 4, and incorporating them 
in.  I believe these SHOULD address much of EKR's questions.

I will have a run of 1M DEX random HIs to HITs generated with no 
duplicates that I add in an Appendix along with the Python code.

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

For an Initiator, BEX is:

2 PK sig varifications.
1 PK sig generation.
1 DH keypair generation.
1 DH secret derivation.

DEX is:

1 DH secret derivation.

I have cycles for these and a paper to reference, except ECDH keypair 
generation, on an 8 bit process and the numbers are big. But I think 
that part belongs in an Appendix.

So unlikely Friday.  But early the following week.

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:
> Two months after the email below, I sending a kind reminder to authors 
> and WG.
> With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should 
> have been addressed.
> As far as I can tell, the other remaining issue was Ekr’s one about 
> why forfeiting FS when some algorithm could do it in a reasonable 
> time. In an email to authors and ADs, Eric R. wrote “it defines a set 
> of parameters (the NIST curves) which are slower w/o FS than other 
> parameters (X25519) are w/ FS. This fact calls into question the need 
> to dispense with FS.”
> While 2 months ago I put a deadline for tomorrow, I (as the 
> responsible AD) am flexible of course but we cannot linger anymore. I 
> know that a -23 is in the work for weeks => let’s publish it in the 
> coming days.
> Else, next week we will need to either change the intended status to 
> experimental or declare the document dead by lack of energy. The 
> latter does not have my preference obviously.
> Regards
> -éric
> *From: *Hipsec <> on behalf of "Eric Vyncke 
> (evyncke)" <>
> *Date: *Friday, 13 November 2020 at 15:32
> *To: *"" <>rg>, 
> "" <>rg>, Robert 
> Moskowitz <>om>, Miika Komu <>
> *Cc: *Roman Danyliw <>rg>, Eric Rescorla <>om>, 
> Gonzalo Camarillo <>om>, 
> "" <>om>, Benjamin Kaduk 
> <>du>, Erik Kline <>
> *Subject: *[Hipsec] Need to close all draft-ietf-hip-dex-21 pending 
> issues... before 2021-Jan-13...
> Dear HIP, dear authors,
> This document was requested for publication [1] in February 2018 (2.5 
> years ago), then its IESG evaluation has been deferred, then I took 
> over this document from Terry Manderson in March 2019, then it went 
> again through IESG evaluation in July 2020 and there are still DISCUSS 
> points to be addressed even after a couple of revised I-D...
> Difficult not to observe that this document does not progress very fast.
> Moreover, this document is a normative reference for rfc4423-bis 
> waiting in the RFC editor queue since March 2019... So, also blocking 
> the HIP-NAT document [2].
> After discussion with the HIP chair, Gonzalo in cc, we have taken the 
> following decision: if a revised I-D addressing remaining DISCUSS 
> points + Ekr’s ones is not uploaded within 2 months (13^th of January 
> 2021), then I will request the HIP WG to accept the complete removal 
> of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in 
> the appendix) + the reference to the HIP-DEX document [3]. This will 
> allow the immediate publication of the rfc4423-bis and HIP-NAT documents.
> The HIP DEX authors may also select to change the intended status of 
> the document to ‘experimental’ (if the HIP WG agrees) as this may 
> reduce the security requirements by the SEC AD and Ekr.
> Gonzalo and I are still hoping to get a revised HIP-DEX shortly,
> Regards
> -éric
> [1] 
> <>
> [2] 
> <>
> [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the 
> datatracker

Standard Robert Moskowitz
HTT Consulting

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit