Re: [Last-Call] Last Call: <draft-ietf-hip-dex-24.txt> (HIP Diet EXchange (DEX)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I do not believe this document should be published in the standards track. We should be favoring FS where possible, and the evidence that it is prohibitive in this case is scant at best.

To recap, the original rationale for this protocol was the one Bob made in a recent message, 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 (e.g., sec160k1  to P-384), 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 as submitted to the IESG 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 merely removes the obvious inconsistency from the specification; it does not address the question of whether we need to abandon FS. Until we have done so, this protocol should not be standardized.

-Ekr

On Wed, Jan 20, 2021 at 7:10 AM Eric Vyncke (evyncke) <evyncke=40cisco.com@xxxxxxxxxxxxxx> wrote:
There have been several of *significant* changes  since the IETF last call in November 2019 on the -11 revision, so, as the responsible AD, I am asking the IETF community for 3rd review on the latest revision -24.

The changes include at least: applicability statement, use of the FOLD function, I_NONCE, input keying material for master/pair-wise key generation, security section, some deleted DH groups and ciphers.

For your convenience the diff between the two versions: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-24&url1=draft-ietf-hip-dex-11

Thank you in advance for your valuable comments before the 3rd of February 2021,

-éric vyncke

PS: thank you for the previous reviewers, your comments have helped the authors to improve the document. Thank you as well to the authors for listening to those comments.

-----Original Message-----
From: <iesg-secretary@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx>
Reply-To: "last-call@xxxxxxxx" <last-call@xxxxxxxx>
Date: Wednesday, 20 January 2021 at 15:48
To: IETF-Announce <ietf-announce@xxxxxxxx>
Cc: Gonzalo Camarillo <gonzalo.camarillo@xxxxxxxxxxxx>, "draft-ietf-hip-dex@xxxxxxxx" <draft-ietf-hip-dex@xxxxxxxx>, Eric Vyncke <evyncke@xxxxxxxxx>, "gonzalo.camarillo@xxxxxxxxxxxx" <gonzalo.camarillo@xxxxxxxxxxxx>, "hip-chairs@xxxxxxxx" <hip-chairs@xxxxxxxx>, "hipsec@xxxxxxxx" <hipsec@xxxxxxxx>
Subject: Last Call: <draft-ietf-hip-dex-24.txt> (HIP Diet EXchange (DEX)) to Proposed Standard


    The IESG has received a request from the Host Identity Protocol WG (hip) to
    consider the following document: - 'HIP Diet EXchange (DEX)'
      <draft-ietf-hip-dex-24.txt> as Proposed Standard

    The IESG plans to make a decision in the next few weeks, and solicits final
    comments on this action. Please send substantive comments to the
    last-call@xxxxxxxx mailing lists by 2021-02-03. Exceptionally, comments may
    be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
    of the Subject line to allow automated sorting.

    Abstract


       This document specifies the Host Identity Protocol Diet EXchange (HIP
       DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and
       specifically developed for use on low end processors.  The HIP DEX
       protocol design aims at reducing the overhead of the employed
       cryptographic primitives by omitting public-key signatures and
       cryptographic hash functions.

       The HIP DEX protocol is primarily designed for computation or memory-
       constrained sensor/actuator devices.  Like HIPv2, it is expected to
       be used together with a suitable security protocol such as the
       Encapsulated Security Payload (ESP) for the protection of upper layer
       protocol data.  Unlike HIPv2, HIP DEX does not support Forward
       Secrecy (FS), and MUST only be used on devices where FS is
       prohibitively expensive.  In addition, HIP DEX can also be used as a
       keying mechanism for security primitives at the MAC layer, e.g., for
       IEEE 802.15.4 networks.





    The file can be obtained via
    https://datatracker.ietf.org/doc/draft-ietf-hip-dex/



    No IPR declarations have been submitted directly on this I-D.


    The document contains these normative downward references.
    See RFC 3967 for additional information:
        rfc6261: Encrypted Signaling Transport Modes for the Host Identity Protocol (Experimental - IETF stream)





--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux