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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 12 Jan 2021 11:19:23 +0000

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 <[email-masked]> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]>
Date: Friday, 13 November 2020 at 15:32
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Robert Moskowitz <[email-masked]>, Miika Komu <[email-masked]>
Cc: Roman Danyliw <[email-masked]>, Eric Rescorla <[email-masked]>, Gonzalo Camarillo <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>, Erik Kline <[email-masked]>
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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 14 Jan 2021 10:07:09 -0500

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:
> 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 <[email-masked]> on behalf of "Eric Vyncke 
> (evyncke)" <evyncke=[email-masked]>
> *Date: *Friday, 13 November 2020 at 15:32
> *To: *"[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Robert 
> Moskowitz <[email-masked]>, Miika Komu <[email-masked]>
> *Cc: *Roman Danyliw <[email-masked]>, Eric Rescorla <[email-masked]>, 
> Gonzalo Camarillo <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Benjamin Kaduk 
> <[email-masked]>, Erik Kline <[email-masked]>
> *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...
>
> 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.
>
> <https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/>
>
> <https://www.rfc-editor.org/cluster_info.php?cid=C386>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 18 Jan 2021 14:12:24 +0000

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 <[email-masked]>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <[email-masked]>, "Eric Vyncke (evyncke)" <evyncke=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Miika Komu <[email-masked]>

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.

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.

Regards

-éric

From: Hipsec mailto:[email-masked] on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=[email-masked]

To: mailto:[email-masked] mailto:[email-masked], mailto:[email-masked] mailto:[email-masked], Robert Moskowitz mailto:[email-masked], Miika Komu mailto:[email-masked]

Cc: Roman Danyliw mailto:[email-masked], Eric Rescorla mailto:[email-masked], Gonzalo Camarillo mailto:[email-masked], mailto:[email-masked] mailto:[email-masked], Benjamin Kaduk mailto:[email-masked], Erik Kline mailto:[email-masked]

Dear HIP, dear authors,

Regards

-éric

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

E:      mailto:[email-masked]

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 18 Jan 2021 11:06:01 -0500

On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:
> Standard
> 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>):
>
>       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
>       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
>       o EVY> still light on the ACL but the above should clear it
>

Sec 7.1 is referenced.

>      o
>       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

See sec 9.1

>  *

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.

>  *
>       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
> 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
>
> To: Eric Vyncke <[email-masked]>, "Eric Vyncke (evyncke)" 
> <evyncke=[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Miika Komu <[email-masked]>
>
> Cc: Roman Danyliw <[email-masked]>, Eric Rescorla <[email-masked]>, 
> 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.
>
> From: Hipsec mailto:[email-masked] on behalf of "Eric Vyncke 
> (evyncke)" mailto:evyncke=[email-masked]
>
> To: mailto:[email-masked] mailto:[email-masked], 
> mailto:[email-masked] mailto:[email-masked], 
> Robert Moskowitz mailto:[email-masked], Miika Komu 
> mailto:[email-masked]
>
> Cc: Roman Danyliw mailto:[email-masked], Eric Rescorla 
> mailto:[email-masked], Gonzalo Camarillo 
> mailto:[email-masked], mailto:[email-masked] 
> mailto:[email-masked], Benjamin Kaduk mailto:[email-masked], 
> Erik Kline mailto:[email-masked]
>
> points + Ekr’s ones is not uploaded within 2 months (13th of January

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 18 Jan 2021 11:13:11 -0500

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:
>>   * Roman: “Section 6.3.  Per the definition of IKM, when should
>>     these two different derivations be used? "
> privately held by Adam and I.  If called on, we can find some 
> permanent home for it.
>
>>      o
>>
>>
>>       o EVY> partially addressed in section 1.2 but should be
>>         repeated in the security section
>>
>
> 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
>>
>>
>>
>>
>> As written in November (see below), the situation has lingered for 
>> too long and is blocking the HIP-NAT and rfc4423-bis documents.
>>
>> 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. ***
>>
>
>> mailto:[email-masked] 
>> mailto:[email-masked], Robert Moskowitz 
>> mailto:[email-masked], Miika Komu 
>> again through IESG evaluation in July 2020 and there are still 
>> DISCUSS points to be addressed even after a couple of revised I-D...
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 18 Jan 2021 11:34:45 -0500

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:
>>> 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>):
>>>
>>>   * 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.”
>> 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.
>>
>>> *** 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 
>>> 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 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.
>>>
>>> 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.”
>>>
>>> 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.
>>>
>>> From: Hipsec mailto:[email-masked] on behalf of "Eric 
>>> Vyncke (evyncke)" mailto:evyncke=[email-masked]
>>>
>>> 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 
>>> 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.
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jan 2021 05:51:49 -0800

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-masked]>
wrote:

> paper.  All else is still ok, but let me dig a big more on that paper for
> non-IACR members.
>
> 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
>       - EVY> this really pleads for experimental status
>
>
>    -
>       - 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
>
>
>    -
>       - 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"
>
>
>    -
>    - 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.
>
>
> 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.
>
> 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...
>
>
>
>
>    -
>
>
>
> 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
> ), so, another IETF Last Call is required but should not be a real problem.
>
>
>
>
>
> -éric
>
>
>
>
>
>
>
> <[email-masked]>
>
> To: Eric Vyncke <[email-masked]> <[email-masked]>, "Eric Vyncke
> <evyncke=[email-masked]>, "[email-masked]" <[email-masked]>
> <[email-masked]> <[email-masked]>, "[email-masked]"
> <[email-masked]> <[email-masked]>
> <[email-masked]>
>
> Cc: Roman Danyliw <[email-masked]> <[email-masked]>, Eric Rescorla
> <[email-masked]> <[email-masked]>, Gonzalo Camarillo
> <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]>
> <[email-masked]>, Benjamin Kaduk <[email-masked]> <[email-masked]>,
> Erik Kline <[email-masked]> <[email-masked]>
>
> now in IACR's Real World Crypto, where I have gotten a couple pointers for
> DRIP work.
>
>
>
> generation, on an 8 bit process and the numbers are big.  But I think that
> part belongs in an Appendix.
>
>
>
> 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.
>
>
>
> experimental or declare the document dead by lack of energy. The latter
> does not have my preference obviously.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> From: Hipsec mailto:[email-masked] <[email-masked]> on
> behalf of "Eric Vyncke (evyncke)"
> mailto:evyncke=[email-masked]
> <evyncke=[email-masked]>
>
> To: mailto:[email-masked] <[email-masked]> mailto:[email-masked]
> <[email-masked]>, mailto:[email-masked]
> <[email-masked]> mailto:[email-masked]
> <[email-masked]>, Robert Moskowitz
> mailto:[email-masked] <[email-masked]>, Miika Komu
> mailto:[email-masked] <[email-masked]>
>
> Cc: Roman Danyliw mailto:[email-masked] <[email-masked]>, Eric Rescorla
> mailto:[email-masked] <[email-masked]>, Gonzalo Camarillo
> mailto:[email-masked] <[email-masked]>,
> mailto:[email-masked] <[email-masked]>
> mailto:[email-masked] <[email-masked]>, Benjamin Kaduk
> mailto:[email-masked] <[email-masked]>, Erik Kline mailto:[email-masked]
> <[email-masked]>
>
> 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...
>
>
>
> 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].
>
>
>
> 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.
>
>
>
> E:      mailto:[email-masked] <[email-masked]>
>
>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 19 Jan 2021 09:28:26 -0500

X25519 (and x448) is the only curve remaining in HIP DEX.

In checking on this, I see I do need to remove text from 9.3 which is 
the only remaining reference.

Of course there is the valid question of why x448 is still there. 
Probably should remove it as well.

So looking into p384:

If you follow this link:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwi0_P_ZlKjuAhVGHc0KHSyyDdgQFjAEegQIBRAC&url=https%3A%2F%2Fcryptobook.nakov.com%2Fasymmetric-key-ciphers%2Felliptic-curve-cryptography-ecc&usg=AOvVaw3i71pEYmIH0HT9pwbTca4j

you get a very recent paper on P-256 and it is slower than X25519.

Then there is this:

https://cockrum.net/Implementation_of_ECC_on_an_8-bit_microcontroller.pdf

https://arxiv.org/pdf/1902.10313.pdf

If you want to roll your own test:

https://github.com/kmackay/micro-ecc

But again, on your recommendation (and a good one!), I removed the NIST 
curves due to their poorer performance over x25519.

On 1/19/21 8:51 AM, Eric Rescorla wrote:
> 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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <https://www.researchgate.net/publication/300253314_Efficient_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers>
>
>>     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.
>>
>>>>     Thank you for the -23 (and Adam W for the footwork)and I
>>>>     understand that you are quite busy.
>>>>
>>>>       * 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.
>>>>
>>>
>>>     Seems clear that IKMm is for the Master Key SA and IKMp is for
>>>     the Pair-wise Key SA.
>>>
>>>>         non-blocking) about "further implementation experience
>>>>         provides better guidance" in sections 6 and 9.
>>>     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
>>>>
>>>>
>>>     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.
>>>
>>>     <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. ***
>>>>
>>>
>>>>     <mailto:[email-masked]>
>>>>
>>>>     To: Eric Vyncke <[email-masked]> <mailto:[email-masked]>,
>>>>     "Eric Vyncke (evyncke)" <evyncke=[email-masked]>
>>>>     <mailto:evyncke=[email-masked]>, "[email-masked]"
>>>>     <mailto:[email-masked]> <[email-masked]>
>>>>     <mailto:[email-masked]>, "[email-masked]"
>>>>     <mailto:[email-masked]>
>>>>     <[email-masked]>
>>>>     <mailto:[email-masked]>, Miika Komu
>>>>     <[email-masked]> <mailto:[email-masked]>
>>>>
>>>>     Cc: Roman Danyliw <[email-masked]> <mailto:[email-masked]>, Eric
>>>>     Rescorla <[email-masked]> <mailto:[email-masked]>, Gonzalo
>>>>     Camarillo <[email-masked]>
>>>>     <mailto:[email-masked]>,
>>>>     "[email-masked]" <mailto:[email-masked]>
>>>>     <[email-masked]> <mailto:[email-masked]>,
>>>>     Benjamin Kaduk <[email-masked]> <mailto:[email-masked]>, Erik
>>>>     Kline <[email-masked]> <mailto:[email-masked]>
>>>>
>>>>     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.
>>>>
>>>>     keypair generation, on an 8 bit process and the numbers are
>>>>     big.  But I think that part belongs in an Appendix.
>>>>
>>>>     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
>>>>     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-masked]
>>>>     <mailto:[email-masked]> on behalf of "Eric Vyncke
>>>>     <mailto:evyncke=[email-masked]>
>>>>
>>>>     To: mailto:[email-masked] <mailto:[email-masked]>
>>>>     mailto:[email-masked] <mailto:[email-masked]>,
>>>>     <mailto:[email-masked]>
>>>>     <mailto:[email-masked]>, Robert Moskowitz
>>>>     mailto:[email-masked]
>>>>     <mailto:[email-masked]>, Miika Komu
>>>>     mailto:[email-masked] <mailto:[email-masked]>
>>>>
>>>>     Cc: Roman Danyliw mailto:[email-masked] <mailto:[email-masked]>,
>>>>     Eric Rescorla mailto:[email-masked] <mailto:[email-masked]>,
>>>>     Gonzalo Camarillo mailto:[email-masked]
>>>>     <mailto:[email-masked]>,
>>>>     mailto:[email-masked] <mailto:[email-masked]>
>>>>     mailto:[email-masked] <mailto:[email-masked]>,
>>>>     Benjamin Kaduk mailto:[email-masked] <mailto:[email-masked]>,
>>>>     Erik Kline mailto:[email-masked] <mailto:[email-masked]>
>>>>
>>>>     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...
>>>>
>>>>     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.
>>>>
>>>>     [1]
>>>>     https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/
>>>>     <mailto:[email-masked]>
>>>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 19 Jan 2021 14:44:29 +0000

Bob,

Thank you for your reply. I took some time to review the points. Look for EVY2> below but at first sight, this looks really good to me now. Of course, Roman and Ben will have a final say.

About Ekr’s comment, I am reading your latest email sent minutes ago, and I am still unclear where, in the text, it is shown that FS is not achievable.

Action plan: please apply the changes you have proposed below, post a revised I-D, then on my side:

  *   Launching an IETF Last Call for 2 weeks (as written below some important changes have been made but I expect the LC eventless)
  *   Probing Ben & Roman to review whether their DISCUSS still hold

Regards, it seems that the conclusion is near ;-)

-éric

From: Robert Moskowitz <[email-masked]>
Date: Monday, 18 January 2021 at 17:06
To: Eric Vyncke <[email-masked]>, Robert Moskowitz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Miika Komu <[email-masked]>
Cc: Roman Danyliw <[email-masked]>, Eric Rescorla <[email-masked]>, Gonzalo Camarillo <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>, Erik Kline <[email-masked]>, Adam Wiethuechter <[email-masked]>
Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

Bob,

1.       Roman: “Section 6.3.  Per the definition of IKM, when should these two different derivations be used? "

1.       EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.

       IKMm      Kij | I_NONCE

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

EVY2> Suggest to add a pointer to section 2.3 (definitions) and possibly create entries for the master key SA and pair-wise key SA (perhaps a little extreme though)

2.       Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.

1.       EVY> this really pleads for experimental status

The only place this text exists anymore is in Appendix C:  iESG Considerations

EVY2> you can keep it the appendix, I guess this fixes Roman’s “discuss-discuss”

2.

3.       Benjamin on FOLD collisions

1.       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.

2.

4.       Benjamin on ACL to counter FOLD collisions in section 3.2.1

1.       EVY> still light on the ACL but the above should clear it

Sec 7.1 is referenced.

2.

5.       Benjamin "how is it known that the peer should be using DEX vs. BEX"

1.       EVY> partially addressed in section 1.2 but should be repeated in the security section

Will this work?

EVY2>  it works for me and hopefully for Ben as well

2.

6.       Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR

See sec 9.1

EVY2> Indeed, Ben’s ballot is dated March 2020 on the revision -13. It seems to be fixed to me in the latest revisions.

7.

8.       Benjamin "presence of a CSPRNG in order to obtain secure session keys"

....

EVY2> indeed, I should have detected that Ben was not using the -21 but the -13 😉 Now, please expand CSPRNG at first use.

9.

10.   Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm

1.       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.

EVY2> if Ben was happy, then I am happy. Thank you for the information.

2.

11.   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.”

1.       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.

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...

2.

-éric

From: Robert Moskowitz <[email-masked]><mailto:[email-masked]>

To: Eric Vyncke <[email-masked]><mailto:[email-masked]>, "Eric Vyncke (evyncke)" <evyncke=[email-masked]><mailto:evyncke=[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Miika Komu <[email-masked]><mailto:[email-masked]>

Cc: Roman Danyliw <[email-masked]><mailto:[email-masked]>, Eric Rescorla <[email-masked]><mailto:[email-masked]>, Gonzalo Camarillo <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Benjamin Kaduk <[email-masked]><mailto:[email-masked]>, Erik Kline <[email-masked]><mailto:[email-masked]>

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

DEX is:

1 DH secret derivation.

Regards

-éric

Dear HIP, dear authors,

Regards

-éric

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 19 Jan 2021 10:29:06 -0500

On 1/19/21 9:44 AM, Eric Vyncke (evyncke) wrote:
> Standard
>
> Bob,
>
> Thank you for your reply. I took some time to review the points. Look 
> for EVY2> below but at first sight, this looks really good to me now. 
> Of course, Roman and Ben will have a final say.
>
> About Ekr’s comment, I am reading your latest email sent minutes ago, 
> and I am still unclear where, in the text, it is shown that FS is not 
> achievable.
>

1.2 (and 1.2.1) cover it.  the cost of FS is beyond what 8-bit CPUs are 
reasonably able to handle.

If some vendor is willing to pay the cost of BEX, it is always an 
option.  Time and battery (and code) are against vendors going that 
route (choosing BEX for FS over DEX).

>   * Launching an IETF Last Call for 2 weeks (as written below some
>     important changes have been made but I expect the LC eventless)

I am ready with the changes.  I have an ICAO call I really need to get 
ready for, then a DR appt.  After that I will submit what I have if no 
new comments.

> *From: *Robert Moskowitz <[email-masked]>
> *Date: *Monday, 18 January 2021 at 17:06
> *To: *Eric Vyncke <[email-masked]>, Robert Moskowitz 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Miika 
> Komu <[email-masked]>
> <[email-masked]>, Erik Kline <[email-masked]>, Adam Wiethuechter 
> <[email-masked]>
> *Subject: *Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 
> pending issues... before 2021-Jan-13...
>
>     1.Roman: “Section 6.3.  Per the definition of IKM, when should
>     1.EVY> indeed, IKMm and IKMp are both defined but nothing is said
> EVY2> Suggest to add a pointer to section 2.3 (definitions) and 
> possibly create entries for the master key SA and pair-wise key SA 
> (perhaps a little extreme though)
>
>
>
>
>     2.Roman "discuss-discuss" (read this as request for reply and
>     1.EVY> this really pleads for experimental status
>
>
>     3.Benjamin on FOLD collisions
>
>     1.EVY> IMHO addressed in the new section 3.2.1
>
>
>     4.Benjamin on ACL to counter FOLD collisions in section 3.2.1
>
>     1.EVY> still light on the ACL but the above should clear it
>
>
> Sec 7.1 is referenced.
>
>
>     2.
>
>     5.Benjamin "how is it known that the peer should be using DEX vs. BEX"
>
>     1.EVY> partially addressed in section 1.2 but should be repeated
>     in the security section
>
>
>     6.Benjamin lack of discussion on the security consequences of
> EVY2> Indeed, Ben’s ballot is dated March 2020 on the revision -13. It 
> seems to be fixed to me in the latest revisions.
>
>     7.
>
>     8.Benjamin "presence of a CSPRNG in order to obtain secure session
>     keys"
>
>
> EVY2> indeed, I should have detected that Ben was not using the -21 
> but the -13 😉Now, please expand CSPRNG at first use.
>
>     9.
>
>     10.Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm
>
>     1.EVY> new reference to NIST papers seems to address this concern
>
>
>     11.Ekr’s one about why forfeiting FS when some algorithm could do
>     1.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.
>
>
> may be to some cookie I have on this system.  Or the DOI has the wrong 
> URL.
>
>     <mailto:[email-masked]> <[email-masked]>
>     Rescorla <[email-masked]> <mailto:[email-masked]>, Gonzalo Camarillo
>     <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>, Benjamin Kaduk <[email-masked]>
>     <mailto:[email-masked]>, Erik Kline <[email-masked]>
>     <mailto:[email-masked]>
>
>     cutoff.  I am now in IACR's Real World Crypto, where I have gotten
>     a couple pointers for DRIP work.
>
>     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.”
>
>     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
>
>     mailto:[email-masked] <mailto:[email-masked]>,
>     Miika Komu mailto:[email-masked]
>     <mailto:[email-masked]>
>
>     Cc: Roman Danyliw mailto:[email-masked] <mailto:[email-masked]>, Eric
>     Rescorla mailto:[email-masked] <mailto:[email-masked]>, Gonzalo
>     Camarillo mailto:[email-masked]
>     Benjamin Kaduk mailto:[email-masked] <mailto:[email-masked]>, Erik
>     Kline mailto:[email-masked] <mailto:[email-masked]>
>
>     (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...
>
>     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.
>
>     E: mailto:[email-masked] <mailto:[email-masked]>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jan 2021 09:33:29 -0800

On Tue, Jan 19, 2021 at 7:29 AM Robert Moskowitz <[email-masked]>
wrote:

> Thank you for your reply. I took some time to review the points. Look for
> EVY2> below but at first sight, this looks really good to me now. Of
> course, Roman and Ben will have a final say.
>
>
>
> About Ekr’s comment, I am reading your latest email sent minutes ago, and
> I am still unclear where, in the text, it is shown that FS is not
> achievable.
>
>
> If some vendor is willing to pay the cost of BEX, it is always an option.
> Time and battery (and code) are against vendors going that route (choosing
> BEX for FS over DEX).
>

I must say, I find this whole discussion baffling.

To recap, the original rationale for this protocol was the one Bob makes
above, namely that "the cost of FS is beyond what 8-bit CPUs are reasonably
able to handle." However, this claim was presented without any actual
requirements for what an acceptable cost was and the protocol as sent by
the WGLC to the IESG included a wide range of cryptographic primitives,
some of which would be comparable if not slower to a forward secure
exchange with the best available algorithms (i.e., X25519)  This implies
one of three things:

1. The requirements are not known.
2. The requirements have quite a bit of headroom above a non-FS exchange
with the best available algorithms and potentially could accommodate FS.
3. The original protocol did not in fact meet the requirements.

The proper conclusion, in any case, is that we don't know whether we can
fit a FS exchange into the requirements and we won't until a proper
requirements analysis is done. Removing the NIST curves, as Bob proposes to
do, merely removes the obvious inconsistency from the specification; it
does not address the question of whether we need to abandon FS.

-Ekr

>    - Launching an IETF Last Call for 2 weeks (as written below some
>    - Probing Ben & Roman to review whether their DISCUSS still hold
>
>
> ready for, then a DR appt.  After that I will submit what I have if no new
> comments.
>
>
>    -
>
>
>
> *From: *Robert Moskowitz <[email-masked]> <[email-masked]>
> *To: *Eric Vyncke <[email-masked]> <[email-masked]>, Robert
> Moskowitz <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]>
> <[email-masked]> <[email-masked]>, Miika Komu
> <[email-masked]> <[email-masked]>
> *Cc: *Roman Danyliw <[email-masked]> <[email-masked]>, Eric Rescorla
> Erik Kline <[email-masked]> <[email-masked]>, Adam Wiethuechter
> <[email-masked]> <[email-masked]>
> *Subject: *Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending
> 1.       Roman: “Section 6.3.  Per the definition of IKM, when should
> EVY2> Suggest to add a pointer to section 2.3 (definitions) and possibly
> create entries for the master key SA and pair-wise key SA (perhaps a little
> extreme though)
>
>
>
>
>
>
> 2.       Roman "discuss-discuss" (read this as request for reply and
> non-blocking) about " further implementation experience provides better
> guidance" in sections 6 and 9.
>
> EVY2> indeed, I should have detected that Ben was not using the -21 but
> the -13 😉 Now, please expand CSPRNG at first use.
>
> 9.
>
> 11.   Ekr’s one about why forfeiting FS when some algorithm could do it
> 1.       EVY> the additional section 1.2.1 and the reference to a paywall