[Hipsec] Francesca Palombini's No Objection on draft-ietf-hip-dex-24: (with COMMENT)
Francesca Palombini via Datatracker <firstname.lastname@example.org> Wed, 24 March 2021 16:40 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 121E53A306A; Wed, 24 Mar 2021 09:40:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Francesca Palombini via Datatracker <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com, Gonzalo Camarillo <firstname.lastname@example.org>, email@example.com
Reply-To: Francesca Palombini <firstname.lastname@example.org>
Date: Wed, 24 Mar 2021 09:40:40 -0700
Subject: [Hipsec] Francesca Palombini's No Objection on draft-ietf-hip-dex-24: (with COMMENT)
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:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2021 16:40:40 -0000
Francesca Palombini has entered the following ballot position for draft-ietf-hip-dex-24: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
- [Hipsec] Francesca Palombini's No Objection on dr… Francesca Palombini via Datatracker