[Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-24: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-hip-dex-24: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-dex/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** I’d like to discuss the maturity of the proposal through the lens of
publishing as PS vs. experimental.  With the latter, one would expect the
current best practice of forward secrecy (FS) to be used unless there was a
demonstrated need.  With an experimental or even informational, the bar would
be lower.  In response to earlier ballots and WG/IETF last call discussion
[1][2] this document has clearly documented the design differences between BEX
and DEX (this document),  the impact of removing FS, and added additional text
on the motivating constrained environment.

After reviewing all of this new text, I was looking for and couldn’t find a
clear narrative on the proposed DEX operational environment that would motivate
the loss of FS.  What I found was the following:

(a) Section 1.2 cites execution times of 8-bit 8051-based ZWAVE ZW0500
microprocessor doing ECDH and DEX-specific operations

(b) Section 1.2.1 enumerates the crypto operations that BEX and DEX needs to
perform

(c) Section 1.2.1 also points to [EfficientECC] that documents the clock cycles
needed for relevant crypto operations on a class 0 platform

All are helpful to show discrete analyses, but I need help connecting them into
a simple, tangible narrative of roughly the following form -- “current BEX
protocol (or a FS preserving approach) is too expensive, per some measure, on a
particular constrained hardware given real-world use cases that wanted to use.”
 For example:

-- (a) seemed to describe wall-clock time execution of a class-1 system using
DEX.  What would have been the equivalent execution time use BEX or an approach
with FS?  Would those execution numbers have been unacceptable?

-- (c) provides concrete clock cycle numbers.  Like with (a), a bit more
context would be helpful.  What’s the equivalent on BEX or with a scheme that
uses FS?

I didn’t follow all of the WG discussion that produced the document.  If this
analysis was done somewhere, can it please be shared.

My concern is that if the analysis hasn’t been done to show that BEX or a
FS-preserving approach is inadequate, it seems difficult to publish a PS with
intentionally weakened security properties as an alternative.

** Section 5.2.1.  The DH_GROUP_LIST has been significantly pruned (removal of
NIST P-256, P-384, P-521, SECP160R1) in sequential revisions.  However, despite
these reconsiderations, Curve448 remain despite “[i]]t is not [being] known if
Curve448 Diffie Hellman can meet the performance requirements on 8-bit CPUs.” 
If the whole point of HIP-DEX is to operate on constrained devices of a
particular class, why would a proposed standard document be published with a
recommendation which is acknowledged to have unvalidated suitability for the
problem domain.

[1] https://mailarchive.ietf.org/arch/msg/hipsec/AO3C6Ol2S-i5obJ4msbCp1KDVmQ/

[2] https://mailarchive.ietf.org/arch/msg/last-call/ATU2rfUkX6aPWSC4ZwhSedSJIds/


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing  my preliminary DISCUSS points from the earlier
telechat.

I support Lars's DISCUSS position.

** Section 1.  Per “This is based on actual implementation efforts on 8-bit CPU
sensors with 16KB memory and 64KB flash for code”, is there an informational
pointer to this effort?  Is this the same work as the ZW0500 noted in Section
1.2?

** Section 1.2.  Please clarify the intended application.  Currently text reads
– “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]).” 8-bit CPUs
comes in up Section  1.2, 1.2.1 and 5.2.1 as the framing of the device.  If
that’s an important characteristics, please reflect that in the text.

** Section 1.2.1.  Thanks for the pointers to [EfficientECC] and [ATmega328P]. 
It would be useful to clarify that the ATmega328P is a class 0 device since
that’s the framework used in Section 1.2