Thanks for the link. However, this paper appears only to cover X25519. We'd need a comparison of this to P384, etc. in order to assess the relative performance of SIGMA-style protocols with NIST curves with HIP-DEX with X25519
On Mon, Jan 18, 2021 at 8:35 AM Robert Moskowitz <[email protected]> wrote: > Ah, found the paper 'free' from: > > > https://www.researchgate.net/publication/300253314_Efficient_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers > > pg 13 is the table I am using. Please check that you can access this URL. > > On 1/18/21 11:13 AM, Robert Moskowitz wrote: > > Oops hold it on that paywall URL issue. I responded with a different > paper. All else is still ok, but let me dig a big more on that paper for > non-IACR members. > > On 1/18/21 11:06 AM, Robert Moskowitz wrote: > > > > On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: > > 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. > > > IKM IKMm for Master Key SA Input keying material > or > IKMp for Pair-wise Key SA Input keying material > > IKMm Kij | I_NONCE > IKMp Kij | I_NONCE | (concatenated random values of the > ENCRYPTED_KEY parameters in the same order as > the HITs with sort(HIT-I | HIT-R)) > > Seems clear that IKMm is for the Master Key SA and IKMp is for the > Pair-wise Key SA. > > > - 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 > > > The only place this text exists anymore is in Appendix C: iESG > Considerations > > Perhaps I should delete it from there. > > > - > - Benjamin on FOLD collisions > - EVY> IMHO addressed in the new section 3.2.1 > > > I believe I have this covered. We have the Python scripts for tests, but > this is a lot of code to put into the document. Right now it is privately > held by Adam and I. If called on, we can find some permanent home for it. > > > - > - Benjamin on ACL to counter FOLD collisions in section 3.2.1 > - EVY> still light on the ACL but the above should clear it > > > Sec 7.1 is referenced. > > > - > - 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 > > > I can create a sec 9.1 (pushing down the current 9.1): > > 9.1 Caution on using HIP DEX rather than HIP BEX > > Due to the substantially reduced security guarantees of HIP DEX > compared to HIP BEX, HIP DEX MUST only be used when at least one of > the two endpoints is a class 0 or 1 constrained device defined in > Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both > endpoints are class 2 devices or unconstrained. > > > Will this work? > > > - > - Benjamin lack of discussion on the security consequences of > inadvertent counter reuse in AES-CTR > > > See sec 9.1 > > > - > - Benjamin "presence of a CSPRNG in order to obtain secure session > keys" > > > 9. Security Considerations > > .... > > * The strength of the keys for both the Master and Pair-wise Key SAs > is based on the quality of the random keying material generated by > the Initiator and the Responder. As either peer may be a sensor > or an actuator device, there is a natural concern about the > quality of its random number generator. Thus at least a CSPRNG > SHOULD be used. > > > > - > - Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm > - EVY> new reference to NIST papers seems to address this concern > > > Ben did agree in an email that the SP800-56C and 108 addressed the > concern. I did not need to go further. > > > - > - 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. > > > Paywall? Hmm. I got it free. I will have to check into this. It may be > to some cookie I have on this system. Or the DOI has the wrong URL. > > Ah, that URL works for me because I am an IACR member. For all else: > > https://link.springer.com/article/10.1007/s10623-015-0087-1 > > So I will change the reference. But please check this out. I tried it on > another machine that should not have my IACR cookies, but... > > > > > - > > > > ***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. *** > > > Does the above address the open items? > > > > 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 <[email protected]> > <[email protected]> > > Date: Thursday, 14 January 2021 at 16:08 > > To: Eric Vyncke <[email protected]> <[email protected]>, "Eric Vyncke > (evyncke)" <[email protected]> > <[email protected]>, "[email protected]" <[email protected]> > <[email protected]> <[email protected]>, "[email protected]" > <[email protected]> <[email protected]> > <[email protected]>, Miika Komu <[email protected]> > <[email protected]> > > Cc: Roman Danyliw <[email protected]> <[email protected]>, Eric Rescorla > <[email protected]> <[email protected]>, Gonzalo Camarillo > <[email protected]> <[email protected]>, > "[email protected]" <[email protected]> <[email protected]> > <[email protected]>, Benjamin Kaduk <[email protected]> <[email protected]>, > Erik Kline <[email protected]> <[email protected]> > > 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:[email protected] <[email protected]> on > behalf of "Eric Vyncke (evyncke)" > mailto:[email protected] > <[email protected]> > > Date: Friday, 13 November 2020 at 15:32 > > To: mailto:[email protected] <[email protected]> mailto:[email protected] > <[email protected]>, mailto:[email protected] > <[email protected]> mailto:[email protected] > <[email protected]>, Robert Moskowitz > mailto:[email protected] <[email protected]>, Miika Komu > mailto:[email protected] <[email protected]> > > Cc: Roman Danyliw mailto:[email protected] <[email protected]>, Eric Rescorla > mailto:[email protected] <[email protected]>, Gonzalo Camarillo > mailto:[email protected] <[email protected]>, > mailto:[email protected] <[email protected]> > mailto:[email protected] <[email protected]>, Benjamin Kaduk > mailto:[email protected] <[email protected]>, Erik Kline mailto:[email protected] > <[email protected]> > > 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:[email protected] <[email protected]> > > > > There's no limit to what can be accomplished if it doesn't matter who gets > the credit > > > > >
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
