HIP Diet EXchange (DEX)
draft-ietf-hip-dex-24
Discuss
Yes
No Objection
Erik Kline
(Alvaro Retana)
(Martin Vigoureux)
No Record
Deb Cooley
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Zaheduzzaman Sarker
Summary: Has a DISCUSS. Needs 6 more YES or NO OBJECTION positions to pass.
Roman Danyliw
Discuss
Discuss
(2021-03-24)
Sent
** 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
(2021-03-24)
Sent
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
Éric Vyncke
Yes
Comment
(2020-07-08 for -21)
Sent
This document was deferred by Terry Manderson in May 2018. The authors have taken into account all COMMENTs from the 2018 ballot, changing several parts of the document based on those COMMENTs. The document went successfully through a new IETF last call and the authors have addressed all points raised during this Last Call (including the SECDIR review by Don Eastlake). Security AD have currently some DISCUSSs based on the May 2020 telechat (that was cancelled pending the fix to those DISCUSS). Authors have addressed all DISCUSS (and some COMMENTs) points raised during the IESG review in revision -21. So I am balloting the approval again in front of the 2019 IESG members. -éric
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment
(2021-03-24)
Sent
Thank you for this document. Please find some minor comments below. Francesca 1. ----- Responder, if it is known. Moreover, the I1 packet initialises the negotiation of the Diffie-Hellman group that is used for generating FP: as this is the first time it appears in the text, I would have appreciated a reference to its definition in HIP BEX, or for it to be mentioned in the terminology section. 2. ----- When the Initiator receives the NOTIFY packet, it sets the I2 retransmission timeout to the I2 processing time indicated in the NOTIFICATION parameter plus half the RTT-based timeout value. In doing so, the Initiator MUST NOT set the retransmission timeout to a higher value than allowed by a local policy. This is to prevent unauthenticated NOTIFY packets from maliciously delaying the handshake beyond a well-defined upper bound in case of a lost R2 packet. At the same time, this extended retransmission timeout enables the Initiator to defer I2 retransmissions until the point in time when the Responder should have completed its I2 packet processing and the network should have delivered the R2 packet according to the employed worst-case estimates. FP: This paragraph (or Section 6.9, also talking about NOTIFY packets) does not mention the case where the Initiator receives 2 NOTIFY packets in sequence. Doing so would short circuit the existance of the local policy, and allow to delay the handshake indefinitely. I could not see this mentioned anywhere, is this covered in RFC 7401? 3. ----- In HIP packets, HIP parameters are ordered according to their numeric type number and encoded in TLV format. FP: Please add a reference to section 5.2.1 of RFC 7401. 4. ----- Group KDF Value Curve25519 [RFC7748] CKDF TBD7 (suggested value 12) Curve448 [RFC7748] CKDF TBD8 (suggested value 13) FP: I think it would be good to add a reference to CKDF next to it, in the KDF column, analogous to what RFC 7401 does with RFC 5869 for HKDF. 5. ----- results against the chosen ones. If the re-evaluated suites do not match the chosen ones, the Initiator acts based on its local policy. FP: I don't know if this is an addition to RFC 7401 policy or if this is defined there. If it is an addition, it would have been good to specify that, otherwise add a reference. 6. ----- CKDF-Extract(I, IKM, info) -> PRK FP: Although quite clear, since all other conventions are described in the terminology, it might be good to add "->" to it. 7. ----- The key derivation for the Master Key SA employs always both the Extract and Expand phases. The Pair-wise Key SA needs only the Extract phase when the key is smaller or equal to 128 bits, but otherwise requires also the Expand phase. (either the output from the extract step or the concatenation of the random values of the ENCRYPTED_KEY parameters in the same order as the HITs with sort(HIT-I | HIT-R) in case of no extract) FP: "in case of no extract" - from the paragraph above it seemed as the Extract phase is always executed, is that not so? 8. ----- N = ceil(L/(RHASH_len/8)) FP: Same as above, it might be good to mention or add to the terminology. 9. ----- 3. If the HIP association state is I1-SENT or I2-SENT, the received Initiator's HIT MUST correspond to the HIT used in the original I1 packet. Also, the Responder's HIT MUST correspond to the one used in the I1 packet, unless this packet contained a NULL HIT. FP: What if it doesn't correspond? Is this specified in RFC 7401 (or anywhere else I might have missed)? 10. ----- Section 7. HIP Policies FP: It would have been good here to highlight additional policies or differences with RFC 7401, if any. 11. ----- Appendix A. FP: I would have appreciated some explanation or references for this formula.
Warren Kumari
No Objection
Comment
(2021-03-22)
Not sent
Carrying my earlier (-06) ballot position forward... and then my -13 position forward again. I only reviewed the differences, and do not see any operational concerns. ... and carrying forward to -24. https://memegenerator.net/instance/85346752/matrix-architect-guy-this-is-the-3rd-time-we-are-balloting-hip-dex-and-we-are-becoming-exceedingly-e
Deb Cooley
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Zaheduzzaman Sarker
No Record
Benjamin Kaduk Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2021-03-25)
Sent
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".
Adam Roach Former IESG member
No Objection
No Objection
(2020-02-24 for -13)
Not sent
Trusting the sponsoring AD. Skimmed for ART problems, none found.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -13)
Not sent
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2021-03-24)
Sent for earlier
------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 5.2.6, paragraph 4, nit: - the Responder in I2 which echos it back to the Initiator in R2. + the Responder in I2 which echoes it back to the Initiator in R2. + +
Martin Duke Former IESG member
No Objection
No Objection
(2021-03-15)
Sent
Thanks for providing detailed data on why this sort of security compromise is necessary. I am not a crypto expert, but wonder if there is some way to leverage the potentially asymmetric capabilities of two HIP nodes to offload more of the computation onto one of them. - This is optional, but some suggest replacing the term "man in the middle" with "on-path attacker". Please do it if you are amenable. - Does HIP DEX always put version 2 in the version field, or is DEX somehow orthogonal to HIP version? - Thanks for the discussion of the I2 retransmission timeout in Sec 9. It addressed my concerns in reading Section 4. The "reported delay + 1/2 maximum RTT" formula seems like an odd heuristic for what ought to be "the reported delay plus a little more", but it *does* limit a spoofed NOTIFY to no more than doubling the retransmission rate.
Martin Vigoureux Former IESG member
No Objection
No Objection
()
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-02-26 for -13)
Sent
I only re-reviewed the changes, however, I don't see any transport issues there.
Robert Wilton Former IESG member
No Objection
No Objection
(2021-03-25)
Sent
Hi, Security and constrained devices are both outside my knowledge area, but I note that this document has been in development for a long time, and I wonder whether the axioms under which it was originally specified are still valid, and whether they will continue to hold to be valid in the short/medium term. For example, this document references the ZWAVE 500 chip, but it looks like that technology is already being replaced by the ZWAVE 700 chip that is smaller, faster, uses less power, and plausible looks like it has more hardware support for crypto. Hence, I just want to check that this specification still has value in being published now, but I have not formal objection. Regards, Rob
Suresh Krishnan Former IESG member
(was Discuss)
No Objection
No Objection
(2020-03-13 for -15)
Sent
Thanks for addressing my DISCUSS.