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