Hi Francis, thanks for detailed comments! My comments below.
> Gonzalo Camarillo <[email protected]> Tue, 10 April 2018 > 11:39 UTCShow header > > Bob, Rene, could you please get back to Francis (see below)? > > Gonzalo > > On 05/03/2018 1:14 PM, Gonzalo Camarillo wrote: > > Bob, Rene, > > > > could you please look into the review below and get back to > > Francis? > > Thanks! > > > > Cheers, > > > > Gonzalo > > > > On 26/02/2018 7:30 PM, Francis Dupont wrote: > > > I am the assigned Gen-ART reviewer for this draft. The General > > > Area > > > Review Team (Gen-ART) reviews all IETF documents being processed > > > by the IESG for the IETF Chair. Please treat these comments just > > > like any other last call comments. > > > > > > For more information, please see the FAQ at > > > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. > > > > > > Document: draft-ietf-hip-dex-06.txt > > > Reviewer: Francis Dupont > > > Review Date: 20180224 > > > IETF LC End Date: 20180226 > > > IESG Telechat date: unknown > > > > > > Summary: Ready > > > > > > Major issues: None > > > > > > Minor issues: None > > > > > > Nits/editorial comments: > > > - ToC page 3: you use the US spelling of Acknowledgments in the > > > ToC > > > and the English one (acknowledgements) in the technical body. > > > Even when it is not very consistent I believe this follows RFC > > 7401 > > > choice so I am fine with this. changed to U.S. spelling. > > > - 2.1 page 6: please add/move to RFC 8174 which updates RFC 2119 > > fixing > > > the keyword case silly issue. done > > > - 2.2 page 6: perhaps "sort" should be added here? I replicated the "sort" defition that appears later in the text to here as well > > > - 2.3 page 7 (twice): (c.f. Section 3) -> (see Section 3) or > > > simply (Section 3) thanks, fixed using the first expression > > > - 4.1.3.2 page 16 (at end of line): e.g. -> e.g., fixed > > > - 5.3.3 page 25: I don't believe the critical property for > > > random value is to be "uniformly distributed" (for instance > > > I could have put "unpredictable"). I leave this to the security > > > directorate who should propose a better wording if they don't > > > like > > > the current one... I think this refers to that the probability of each output value from the random value generator is the same, i.e., no value is "favored" more than others, which should be a fair assumption for a randomly generated values > > > - 5.3.4 page 26: same comment. (see above) > > > - 6.1 page 27: this section does not really explain what is the > > puzzle > > > (it only stands the equation to verify) but I remember the > > explaination > > > was before with a reference to 6.1 so I have no concern. (it was mentioned in section 1.1) > > > - 6.2.1 sender 3 page 27: hidden dependency on the sort > > > definition > > > for HOST_g/HOST_l so gl/lg keys. Yes it is in 6.3 but 6.3 is > > after. Added extra sentence to the third sender step: 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers to host with greater HIT value and HIP-lg refers to the host with smaller HIT value. > > > - 6.3 pages and 30: sort is used page 29 and defined after page > > > 30, > > > this is why IMHO the question to move the definition to 2.2 > > notation > > > is a good one... I replicated to section 2.2. > > > - 6.3 page 30: / is not associative so ceil(L/RHASH_len/8) is > > > bad. > > > The text shows it must be ceil(L/(RHASH_len/8)) (vs > > ceil((L/RHASH_len)/8)) good catch, now it is: N = ceil(L/(RHASH_len/8)) > > > - 6.5 1. page 31: Otherwise, it must drop the packet. -> MUST fixed as suggested > > > - 6.6 1. page 33: the system should process the R1 packet -> or > > SHOULD > > > or (I prefer) the system processes the R1 packet used the latter expression > > > - 6.6 8. page 34: The R1 packet may have the A-bit set -> can > > > (not better from a language point of view but clearer and BTW > > > used for instance in 6.10...) fixed > > > - 6.6 13. page 34: it may either resend an I1 packet -> MAY? (cf > > 11.) fixed as suggested > > > - 6.7 5. page 36: Otherwise, the system should process the > > > received > > I2 -> > > > or SHOULD or (better) processes (and drop -> drops) used the latter expression > > > - 6.7 15. page 37: > > > If the A-bit is set, the Initiator's HIT is anonymous and > > should > > > not be stored permanently. -> IMHO SHOULD NOT or directly > > > MUST > > NOT used the latter wording > > > - 6.9 page 39: If a NOTIFY packet is received in state I2-SENT, > > this > > > packet may be an I2 reception acknowledgement of the optional > > > -> replace "may be" by "can be" or (better) "is" used the latter > > > - 7 page 40: Please put "If a Responder is not under high load, > > > #K > > > SHOULD be 0." in its own paragraph (i.e. add a break before > > "If"). > > > It makes clearer this sentence is a requirement when the text > > before > > > is the rationale. done > > > - 8 page 40: " either supports HIP DEX or HIPv2 must be able to > > detect" > > > -> MUST or "has to" used the latter > > > - 8 pages 40 and 41: I think that the first and last paragraphs > > > of > > > section 8 say the same thing. Should you keep both? deleted the last paragraph > > > - 9 page 41: I'd like to see a formal proof of the DEX protocol. > > > I believe you share this wish as you cite SIGMA. hmm, I don't see the problem here. The text refers HIP BEX as SIGMA, and tells why HIP DEX is *not* SIGMA compliant: "HIP DEX, however, replaces the SIGMA-based authenticated Diffie-Hellman key exchange of HIPv2 with an exchange of random keying material that is encrypted with a Diffie-Hellman derived key." > > > - 9 page 42: I'd like to go further and recommend (lower case) > > > the > > > use of a RNG (vs PRNG) when available (hopefully no longer an > > exception). I did not find "RNG" from the document > > > - 9 page 42: Hence, HIP DEX HITs should not be use -> SHOULD or > > > ought to? I took the liberty to change this to MUST NOT be used _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
