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

Eric Rescorla <ekr@rtfm.com> Tue, 19 January 2021 13:52 UTC

Return-Path: <ekr@rtfm.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 ACE633A14FC for <hipsec@ietfa.amsl.com>; Tue, 19 Jan 2021 05:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 DrwVvG3h9I0R for <hipsec@ietfa.amsl.com>; Tue, 19 Jan 2021 05:52:28 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9143A14FD for <hipsec@ietf.org>; Tue, 19 Jan 2021 05:52:27 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id e7so21983811ljg.10 for <hipsec@ietf.org>; Tue, 19 Jan 2021 05:52:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jNZEINnOKjNKbba/b+NE7lgxTawLRksLxukIk2j10e4=; b=ez5ev9rvgHtCgh687nq3ZdmXB/3rzDnLiUr3wsQcUwb7txHMeVKOc9mE1jPhffaqq6 pBMt64AuGgono4MRcC/KzQS5RJli98VoQswCnxG/gpvYe3f2oszzUkqjCMy9klCk/ArO aIdACdTo01uolmcL1fvw18pY1poT0nQlwgabb2xqSDMfIyJiHjodl0AgR3xkYY/tqdfP FA6jfQF8v+6KvmgeGfEowy+7kS8D16X3v3yJHzzUFFk4gX9twNDyovAC0ACtnuj3/p5y YiuWggXVQY3Y6VghsRd48j3ZmRLlq9bDqkJCWeWoTjVtMoCwOr++gyW8GG9mrkdAFAY1 FY9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jNZEINnOKjNKbba/b+NE7lgxTawLRksLxukIk2j10e4=; b=iFsD9p9uBsEe3apkUKkLfnr2IIEvOJJ31/I8rvWtEcCcBXCmQ5Wl2lxhxYnWIKC97/ i1fStzbLh/LdFIyWw5pfsdYI5zxvkFMsFQ0rLjlgUTeGljl5fspR679hcDEET/9rwj9k mHwTdcFIx4YzMvpGdWA44wE4dqcSUfyI3L8GpgtXZuNV121ry4jJFHVnlhRS7XOGjdVp eMFzDEsAEpCJPsZI+yt82NL+tGAtZd/izBdvfROhfGhhF59VRR6k92elws9vum4kQlKP V7OoE7ObQOs9Gfa7bijRR6Y5Eti1xfaxGnUHQrWZol5sKQNpWH73e+p8X04/Gl17eupH FExw==
X-Gm-Message-State: AOAM533PfVsO1srMcDg8vO1y1IsLHem6k6KM3Ixw7p6uT5lfiuTNpNHw ZYfDkCWQj9zDR4AiwkyzA5IVN8clScpjd9wtzuTOYg==
X-Google-Smtp-Source: ABdhPJyex6PlbIBkYKvnQxJLkFdS9Cd4ri15hAhxA4MHlZsVOcL7Ep3D9WR+3yhOrIqp+Zpuj3w3Obvt3A+JCeZ0x2Q=
X-Received: by 2002:a2e:720c:: with SMTP id n12mr2103018ljc.2.1611064345899; Tue, 19 Jan 2021 05:52:25 -0800 (PST)
MIME-Version: 1.0
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> <eb82ead5-9f73-0be0-acdd-a3c52f216d32@htt-consult.com>
In-Reply-To: <eb82ead5-9f73-0be0-acdd-a3c52f216d32@htt-consult.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Jan 2021 05:51:49 -0800
Message-ID: <CABcZeBO6+GWeL5-9KppLiAgszgqABVLqzBMJZ6ywqSgBsDDxsw@mail.gmail.com>
To: Robert Moskowitz <rgm@htt-consult.com>
Cc: "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>, Roman Danyliw <rdd@cert.org>, 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>
Content-Type: multipart/alternative; boundary="0000000000000c4a5305b9412625"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/nqT9s13tzUnNAbTkB4H_C6BjMrY>
X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:35 -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: Tue, 19 Jan 2021 13:52:32 -0000

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 <rgm@htt-consult.com>
wrote:

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