HIP Diet EXchange (DEX)
draft-ietf-hip-dex-24

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

I support Roman's Discuss.

I don't understand how the responder's HOST_ID is supposed to be
authenticated in the handshake.  In HIP-BEX, the HOST_ID is in R1 and
covered by the HIP_SIGNATURE_2, and it is *also* used as input to the
calculation of the HIP_MAC_2 in R2.  In HIP-DEX as currently specified,
the responder's HOST_ID is present in R1 (which has no cryptographic
protection applied) but not present in R2 at all (R2 being the only
message from the responder that is authenticated).  Since we are already
replicating most of R1 in R2 in order to allow the HIP_MAC on R2 to
substitute for the HIP_SIGNATURE_2 in the HIP-BEX version of R1, it
seems like it would be most straightforward to just include a copy of
the responder HOST_ID in R2 as well (thus covered by the main HIP_MAC),
but other options including HIP_MAC_2 are available.

Furthermore, that the lack of authentication for the responder's HOST_ID
could remain in the document for so long, even after multiple rounds of
review, causes me to question whether the cryptographic mechanisms of
this document have really seen an adequate level of review for the
Proposed Standard maturity level.

I also have concerns about the cryptographic analysis of the particular
CKDF construction that is given.  While the previous rounds of review
and response have convinced me that a CMAC-based analogue to HKDF is
safe and well-grounded, the current construction is not fully analogous
to HKDF and also uses a non-injective mapping for convering the
exchanged protocol parameters into CKDF inputs:

- My understanding of the principles behind HKDF is that there is no
  need for the "info" argument to the CKDF-Extract stage, and that using
  that data only in the CKDF-Expand stage is both safe and the expected
  usage.  (The Random #I provided by the responder matches to the HKDF
  salt as a random but non-secret value, and helps to churn the
  extraction of entropy from the IKM.  Adding the I_NONCE along with the
  Diffie-Hellman output allows for an additional source of contributory
  behavior for the initiator, but the Diffie-Hellman exchange itself is
  also supposed to give contributory behavior and the I_NONCE does not
  protect against attacks where the initiator might choose a key share
  that produces a DH output with particular properties, since the
  I_NONCE and initiator key share are produced at the same time.  I
  think we need to be more clear about what the I_NONCE actually does,
  which is to ensure that we get a new key if we have to repeat the
  static-static DH exchange due to (e.g.) state loss, etc.)

- Since we are using Kij | I_NONCE for both IKMm and IKMp, we need to
  ensure that the produced IKM<x> values are distinct by construction.
  The requirement that the encrypted values be at least 64 bits provides
  this property, however, we do not have injectivity because a given
  IKMp could be produced by dividing the "concatenated random values"
  between initiator and responder in different ways.  This introduces a
  risk of attack when the encrypted value of one party is chosen
  maliciously (the attack is easiest when it can be chosen after the
  other party's value is known, but this is not a strict requirement for
  enabling attacks).  So, I think we should either introduce length
  prefixes into the IKMp encoding or require a fixed length (i.e.,
  exactly 64 bits) for the random values.

- The description of the PRK input to CKDF-Expand() includes mention of
  a "case of no extract".  When does this case occur?  I think we need
  to have a clear procedure for when it is (and is not) used, or ideally
  to just always use extract.

- The intermediates T(n) used to generate the CKDF OKM appear to be an
  attempt to use the SP 800-108 "KDF in feedback mode" with optional
  counter, but the NIST version puts the counter directly after the
  previous iteration's output, i.e., before the additional data.  So in
  that sense we are not in a state that "follows the CMAC usage
  guidance" provided by the NIST references.

- The additional information passed to CKDF-Expand() does not provide
  for key separation of the output keys used for the pair-wise key SA
  based on what transport format the keys will be used for.
  (Including the selected transport format in the 'info' should be
  straightforward and resolves this issue.)

I do not see any justification for deviating from the existing RFC 7401
semantics of ECHO_RESPONSE_UNSIGNED in the I2 packet (Appendix B
suggests to use content other than the "unmodified opaque data copied
from the corresponding echo request").  If a two-factor authentication
method is desired, it seems like defining a new TLV pair to convey it is
straightforward and does not confuse the semantics of existing protocol
elements.

There is some text in Section 5.3 that indicates that the "UPDATE,
NOTIFY, CLOSE, and CLOSE_ACK packets are not covered by a signature and
purely rely on the HIP_MAC parameter for packet authentication".
However, the RFC 7401 NOTIFY packet contains only a HIP_SIGNATURE and
not a HIP_MAC.  I think we need to specify a complete NOTIFY message
structure that includes HIP_MAC, rather than attempting to rely on a
delta from RFC 7401 that just removes the HIP_SIGNATURE, most notably so
that we can clearly state what the MAC covers.

Section 6.3 suggests that the CKDF-Expand phase can be skipped for the
Pair-wise Key SA when the needed key is less than or equal to 128 bits,
but I don't see anything in [NIST.SP.800-56C] to suggest that such a
procedure follows the referenced guidance.  In particular, it removes
the opportunity to use the label/context data (known as the "info" in
the RFC 5869 terminology).

We have text in 5.3.2 that I managed to read as saying that the
initiator's (DH_GROUP_LIST) preference takes priority, but there is text
in Section 6.6 that I read as saying that the responder's preference
takes priority.  (See COMMENT for specific locations.)  It can only be
one of those, and we should be clear about which one it is, across the
board.

Section 9.3 discusses the risk of key extraction attack and the need to
validate the peer's public key.  But we say to enforce this in
processing I2 and R2 packets, when the responder's HOST_ID is present in
R1 (and not R2) and is used in the preparation of I2.  If we only
validate the peer's key when processing R2, it is too late and the
damage has already been done.

I think we need greater clarity on whether we are using X25519, or doing
ECDH on Curve25519.  Section 9.3 suggests that we are using X25519, but
only by implicit reference to "the corresponding functions defined in
[RFC7748]"; the rest of the document only discusses Curve25519.
ECDH-on-Curve25519 (or the related curve Wei25519) and X25519 are not
compatible operations; we must pick one.

Section 5.2.2

   The counter for AES-128-CTR MUST have a length of 128 bits.  The
   puzzle value #I and the puzzle solution #J (see Section 4.1.2 in
   [RFC7401]) are used to construct the initialization vector (IV) as
   FOLD(I | J, 112) which are the high-order bits of the CTR counter.  A
   16 bit value as a block counter, which is initialized to zero on
   first use, is appended to the IV in order to guarantee that a non-
   repeating nonce is fed to the AES-CTR encryption algorithm.

   This counter is incremented as it is used for all encrypted HIP
   parameters.  That is a single AES-129-CTR counter associated with the
   Master Key SA.

Is the FOLD output just the initial value of the counter (so that we can
use the full 128-bit space) or do we only get the 16 bits of usable
counter?

Relatedly, I still don't have much clarity on how the counter is
incremented/mnaged for the master key SA.

Section 5.2.3

   HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see
   Section 5.2.9. of [RFC7401]).  The Group ID of the HIP DEX HI is
   encoded in the "ECC curve" field of the HOST_ID parameter.  The
   supported DH Group IDs are defined in Section 5.2.1.

I don't think RFC 7401 actually specifies the serialization for the ECC
public keys (whether ECDSA or ECDH); that is deferred to the
corresponding references (and, furthermore, RFC 4754 seems to be
covering random groups, not the specific NIST groups).  We need an
actual reference for the serialization of the public key in order for
this to be implementable.  (If we're using X25519, this is very easy and
RFC 7748 does the hard work for us.)

Section 5.3.1

   Regarding the Responder's HIT, the Initiator may receive this HIT
   either from a DNS lookup of the Responder's FQDN (see [RFC8005]),
   from some other repository, or from a local table.  The Responder's
   HIT also MUST be of a HIP DEX type.  If the Initiator does not know
   the Responder's HIT, it may attempt to use opportunistic mode by
   using NULL (all zeros) as the Responder's HIT.  [...]

The "may attempt" seems in conflict with "MUST be of a HIP DEX type".