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:14 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 934FC3A0983; Mon, 18 Jan 2021 08:14:08 -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 uJmV5UFXk4RR; Mon, 18 Jan 2021 08:14:02 -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 A3F6A3A096C; Mon, 18 Jan 2021 08:14:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0B57E623C1; Mon, 18 Jan 2021 11:13:59 -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 coZr9B8K8cYW; Mon, 18 Jan 2021 11:13:20 -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 439EC622C2; Mon, 18 Jan 2021 11:13:20 -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>
Message-ID: <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com>
Date: Mon, 18 Jan 2021 11:13:11 -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: <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com>
Content-Type: multipart/alternative; boundary="------------456236479009BEE58656548A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/oKt9l5wZ2xYXc0lqAIrq-PNabsE>
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:14:09 -0000

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