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

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> <[e-mail]>
>
> Date: Thursday, 14 January 2021 at 16:08
>
> To: Eric Vyncke <[e-mail]> <[e-mail]>, "Eric Vyncke
> (evyncke)" <evyncke=[e-mail]>
> <evyncke=[e-mail]>, "[e-mail]" <[e-mail]>
> <[e-mail]> <[e-mail]>, "[e-mail]"
> <[e-mail]> <[e-mail]>
> <[e-mail]>, Miika Komu <[e-mail]>
> <[e-mail]>
>
> Cc: Roman Danyliw <[e-mail]> <[e-mail]>, Eric Rescorla
> <[e-mail]> <[e-mail]>, Gonzalo Camarillo
> <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]> <[e-mail]>
> <[e-mail]>, Benjamin Kaduk <[e-mail]> <[e-mail]>,
> Erik Kline <[e-mail]> <[e-mail]>
>
> 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:[e-mail] <[e-mail]> on
> behalf of "Eric Vyncke (evyncke)"
> mailto:evyncke=[e-mail]
> <evyncke=[e-mail]>
>
> Date: Friday, 13 November 2020 at 15:32
>
> To: mailto:[e-mail] <[e-mail]> mailto:[e-mail]
> <[e-mail]>, mailto:[e-mail]
> <[e-mail]> mailto:[e-mail]
> <[e-mail]>, Robert Moskowitz
> mailto:[e-mail] <[e-mail]>, Miika Komu
> mailto:[e-mail] <[e-mail]>
>
> Cc: Roman Danyliw mailto:[e-mail] <[e-mail]>, Eric Rescorla
> mailto:[e-mail] <[e-mail]>, Gonzalo Camarillo
> mailto:[e-mail] <[e-mail]>,
> mailto:[e-mail] <[e-mail]>
> mailto:[e-mail] <[e-mail]>, Benjamin Kaduk
> mailto:[e-mail] <[e-mail]>, Erik Kline mailto:[e-mail]
> <[e-mail]>
>
> 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:[e-mail] <[e-mail]>
>
>
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
>
>
>
>
>