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

Robert Moskowitz <rgm@htt-consult.com> Mon, 18 January 2021 16:35 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA23A09E1; Mon, 18 Jan 2021 08:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.16
X-Spam-Level:
X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7cNExEMPV4f; Mon, 18 Jan 2021 08:35:14 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC07F3A09E0; Mon, 18 Jan 2021 08:35:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 81463623C1; Mon, 18 Jan 2021 11:35:10 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dNmykgZOGjfU; Mon, 18 Jan 2021 11:34:49 -0500 (EST)
Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7DDB4622C2; Mon, 18 Jan 2021 11:34:48 -0500 (EST)
From: Robert Moskowitz <rgm@htt-consult.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>
Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com>
Message-ID: <eb82ead5-9f73-0be0-acdd-a3c52f216d32@htt-consult.com>
Date: Mon, 18 Jan 2021 11:34:45 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com>
Content-Type: multipart/alternative; boundary="------------D232E518A53AC87D15E7FCD4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/RXMLR_PzzUWviu-aNMQo_facX90>
X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800
Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jan 2021 16:35:18 -0000

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:
>>> 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 <rgm@labs.htt-consult.com>
>>>
>>> Date: Thursday, 14 January 2021 at 16:08
>>>
>>> To: Eric Vyncke <evyncke@cisco.com>om>, "Eric Vyncke (evyncke)" 
>>> <evyncke=40cisco.com@dmarc.ietf.org>rg>, "hipsec@ietf.org" 
>>> <hipsec@ietf.org>rg>, "draft-ietf-hip-dex@ietf.org" 
>>> <draft-ietf-hip-dex@ietf.org>rg>, Miika Komu <miika.komu@ericsson.com>
>>>
>>> Cc: Roman Danyliw <rdd@cert.org>rg>, Eric Rescorla <ekr@rtfm.com>om>, 
>>> Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>om>, 
>>> "rene.hummen@belden.com" <rene.hummen@belden.com>om>, Benjamin Kaduk 
>>> <kaduk@mit.edu>du>, Erik Kline <ek.ietf@gmail.com>
>>>
>>> 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:hipsec-bounces@ietf.org on behalf of "Eric 
>>> Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org
>>>
>>> Date: Friday, 13 November 2020 at 15:32
>>>
>>> To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, 
>>> mailto:draft-ietf-hip-dex@ietf.org 
>>> mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz 
>>> mailto:rgm@labs.htt-consult.com, Miika Komu 
>>> mailto:miika.komu@ericsson.com
>>>
>>> Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla 
>>> mailto:ekr@rtfm.com, Gonzalo Camarillo 
>>> mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com 
>>> mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, 
>>> Erik Kline mailto:ek.ietf@gmail.com
>>>
>>> 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:rgm@labs.htt-consult.com
>>>
>>> There's no limit to what can be accomplished if it doesn't matter 
>>> who gets the credit
>>>
>>
>