[Hipsec] Francesca Palombini's No Objection on draft-ietf-hip-dex-24: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

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.