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

[Robert Moskowitz <[e-mail]>]

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:
>> Standard
>>
>> 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 
>> <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? "
>>       o 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.
>>       o 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.
>
>>      o
>>
>>
>>   * Benjamin on FOLD collisions
>>       o 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.
>
>>      o
>>
>>
>>   * Benjamin on ACL to counter FOLD collisions in section 3.2.1
>>       o EVY> still light on the ACL but the above should clear it
>>
>
> Sec 7.1 is referenced.
>
>>      o
>>
>>
>>   * Benjamin "how is it known that the peer should be using DEX vs. BEX"
>>       o 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?
>
>>      o
>>
>>
>>   * 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
>>       o 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.
>
>>      o
>>
>>
>>   * 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.”
>>       o 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...
>
>
>
>>      o
>>
>>
>>
>>
>> ***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 
>> <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]>
>>
>> Date: Thursday, 14 January 2021 at 16:08
>>
>> To: Eric Vyncke <[e-mail]>, "Eric Vyncke (evyncke)" 
>> <evyncke=[e-mail]>, "[e-mail]" 
>> <[e-mail]>, "[e-mail]" 
>> <[e-mail]>, Miika Komu <[e-mail]>
>>
>> Cc: Roman Danyliw <[e-mail]>, Eric Rescorla <[e-mail]>, 
>> Gonzalo Camarillo <[e-mail]>, 
>> "[e-mail]" <[e-mail]>, Benjamin Kaduk 
>> <[e-mail]>, Erik Kline <[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] on behalf of "Eric Vyncke 
>> (evyncke)" mailto:evyncke=[e-mail]
>>
>> Date: Friday, 13 November 2020 at 15:32
>>
>> To: mailto:[e-mail] mailto:[e-mail], 
>> mailto:[e-mail] 
>> mailto:[e-mail], Robert Moskowitz 
>> mailto:[e-mail], Miika Komu 
>> mailto:[e-mail]
>>
>> Cc: Roman Danyliw mailto:[e-mail], Eric Rescorla 
>> mailto:[e-mail], Gonzalo Camarillo 
>> mailto:[e-mail], mailto:[e-mail] 
>> mailto:[e-mail], Benjamin Kaduk mailto:[e-mail], 
>> Erik Kline mailto:[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]
>>
>> There's no limit to what can be accomplished if it doesn't matter who 
>> gets the credit
>>
>