TD ;LR : more work to be done, deadline this Thursday 21st
Bob, Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy. Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one) After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>): * Roman: “Section 6.3. Per the definition of IKM, when should these two different derivations be used? " * EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case. * Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9. * EVY> this really pleads for experimental status * Benjamin on FOLD collisions * EVY> IMHO addressed in the new section 3.2.1 * Benjamin on ACL to counter FOLD collisions in section 3.2.1 * EVY> still light on the ACL but the above should clear it * Benjamin "how is it known that the peer should be using DEX vs. BEX" * EVY> partially addressed in section 1.2 but should be repeated in the security section * Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR * Benjamin "presence of a CSPRNG in order to obtain secure session keys" * Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm * EVY> new reference to NIST papers seems to address this concern * 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.” * EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS. ***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made) As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents. *** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to ‘experimental’ – as there are no deployed implementations – could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. *** All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem. -éric From: Robert Moskowitz <r...@labs.htt-consult.com> Date: Thursday, 14 January 2021 at 16:08 To: Eric Vyncke <evyn...@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco....@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-...@ietf.org" <draft-ietf-hip-...@ietf.org>, Miika Komu <miika.k...@ericsson.com> Cc: Roman Danyliw <r...@cert.org>, Eric Rescorla <e...@rtfm.com>, Gonzalo Camarillo <gonzalo.camari...@ericsson.com>, "rene.hum...@belden.com" <rene.hum...@belden.com>, Benjamin Kaduk <ka...@mit.edu>, Erik Kline <ek.i...@gmail.com> Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... 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 mailto:hipsec-boun...@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=40cisco....@dmarc.ietf.org Date: Friday, 13 November 2020 at 15:32 To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-...@ietf.org mailto:draft-ietf-hip-...@ietf.org, Robert Moskowitz mailto:r...@labs.htt-consult.com, Miika Komu mailto:miika.k...@ericsson.com Cc: Roman Danyliw mailto:r...@cert.org, Eric Rescorla mailto:e...@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camari...@ericsson.com, mailto:rene.hum...@belden.com mailto:rene.hum...@belden.com, Benjamin Kaduk mailto:ka...@mit.edu, Erik Kline mailto:ek.i...@gmail.com 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 (13th 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] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker -- Robert Moskowitz Owner HTT Consulting C: 248-219-2059 F: 248-968-2824 E: mailto:r...@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit
_______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
