Re: [Hipsec] RFC5201-bis and RFC5202-bis status
Hi, On 09/16/2014 08:20 AM, Tom Henderson wrote: On 09/15/2014 04:37 AM, Gonzalo Camarillo wrote: Hi Tom (Henderson), Jari, Brian, and Ted still have discusses on this document. Could you please summarize for each of them the status of this draft with respect to their particular comments? Thanks, Gonzalo Gonzalo, the most recent status on this draft was posted to the HIP list in this message: http://www.ietf.org/mail-archive/web/hipsec/current/msg03942.html Since then, it seems that Jari and Brian have cleared their discusses. I believe that the IANA issues have been mostly resolved (Ted's discuss). Ted's discuss was against version -14 of the draft, while we are at version -17 now. There is a lingering comment that I haven't picked up from Barry (item 5 in the above email) that pertains to IANA text; I plan to publish those in version -18. I could probably put out a version -18 shortly that may resolve all of the open issues, but it just requires that I generate a new Appendix C example packet. I'll try to get to that in the next day or two. I wrote a checksum generator, and I have independently verified that the checksums in RFC5201-bis are correct. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] RFC5201-bis and RFC5202-bis status
On 10/28/2014 07:00 AM, Miika Komu wrote: I wrote a checksum generator, and I have independently verified that the checksums in RFC5201-bis are correct. Miika, thank you for checking this. This leaves one open issue, regarding the clarifications to HIT_SUITE_LIST. I originally put a diff proposal here: http://trac.tools.ietf.org/wg/hip/trac/attachment/ticket/51/rfc5201-bis-19-to-20-pre.diff This proposal drew one review on the list from Rene, who suggested the following: 1) swap the encoding of the HIT Suite IDs to use the lower four-order bits instead of the higher four-order bits 2) fix an editorial reference to “HMAC parameter” - “HIP_MAC and HIP_MAC_2 parameters” (or RHASH function). 3) change one of the proposed 'should' words to 'SHOULD' While I am sympathetic to Rene's argument in 1), no one else has supported this change on the list, so given the late stage of this document, I would suggest to keep the encoding as is. The changes proposed in 2) and 3) are editorial, in my view, so I don't see a problem to accept them. I regenerated the diff according to Rene's suggestions, and posted it here: http://trac.tools.ietf.org/wg/hip/trac/attachment/ticket/51/rfc5201-bis-19-to-20-pre-2.diff So in summary, I would like to now convey to our AD that we have a diff to the version -19 draft that is editorial/clarification in nature, and ask whether and how it can be handled procedurally, such as: - publish a -20 and revisit some of the reviews (since version -19 was officially reviewed and approved, I don't know what it means to now post a -20 version) - avoid publishing a -20 and handle these changes similar to AUTH48 changes - scrap the diff and just publish version -19 Our AD can let us know how he prefers to handle it. - Tom ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] RFC5201-bis and RFC5202-bis status
Hi Tom (Henderson), Jari, Brian, and Ted still have discusses on this document. Could you please summarize for each of them the status of this draft with respect to their particular comments? Thanks, Gonzalo On 07/09/2014 2:17 PM, Tom Taylor wrote: I'm happy with the outcome. The list discussion addressed the issue. I believe the outcome is: The plaintext attack is resistible, not a real problem, and need not be addressed in the document. Tom Taylor On 06/09/2014 11:37 AM, Tom Henderson wrote: On 09/06/2014 08:25 AM, Ted Lemon wrote: It looks like the latest rev of 5201-bis does not address the gen-art review comments nor Francis Dupont's comments, and I haven't seen any follow-up discussion on Francis' comments. What do the authors believe the status of these two comment threads is? Ted, I believe that there is only one open issue left from the Gen-Art review, regarding possible plaintext attacks: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 The list discussion on this issue leans against making any change; see the last message of this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html I think I previously handled all of the other comments; if I missed any, please point them out. I have tried to contact Francis a couple of times regarding clarification of his comments and have not seen a reply. This is tracked in issue: http://trac.tools.ietf.org/wg/hip/trac/ticket/49 I'm cc'ing both Tom Taylor and Francis for any further clarifications. - Tom ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] RFC5201-bis and RFC5202-bis status
On 09/15/2014 04:37 AM, Gonzalo Camarillo wrote: Hi Tom (Henderson), Jari, Brian, and Ted still have discusses on this document. Could you please summarize for each of them the status of this draft with respect to their particular comments? Thanks, Gonzalo Gonzalo, the most recent status on this draft was posted to the HIP list in this message: http://www.ietf.org/mail-archive/web/hipsec/current/msg03942.html Since then, it seems that Jari and Brian have cleared their discusses. I believe that the IANA issues have been mostly resolved (Ted's discuss). Ted's discuss was against version -14 of the draft, while we are at version -17 now. There is a lingering comment that I haven't picked up from Barry (item 5 in the above email) that pertains to IANA text; I plan to publish those in version -18. I could probably put out a version -18 shortly that may resolve all of the open issues, but it just requires that I generate a new Appendix C example packet. I'll try to get to that in the next day or two. - Tom ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] RFC5201-bis and RFC5202-bis status
I'm happy with the outcome. The list discussion addressed the issue. I believe the outcome is: The plaintext attack is resistible, not a real problem, and need not be addressed in the document. Tom Taylor On 06/09/2014 11:37 AM, Tom Henderson wrote: On 09/06/2014 08:25 AM, Ted Lemon wrote: It looks like the latest rev of 5201-bis does not address the gen-art review comments nor Francis Dupont's comments, and I haven't seen any follow-up discussion on Francis' comments. What do the authors believe the status of these two comment threads is? Ted, I believe that there is only one open issue left from the Gen-Art review, regarding possible plaintext attacks: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 The list discussion on this issue leans against making any change; see the last message of this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html I think I previously handled all of the other comments; if I missed any, please point them out. I have tried to contact Francis a couple of times regarding clarification of his comments and have not seen a reply. This is tracked in issue: http://trac.tools.ietf.org/wg/hip/trac/ticket/49 I'm cc'ing both Tom Taylor and Francis for any further clarifications. - Tom ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] RFC5201-bis and RFC5202-bis status
It looks like the latest rev of 5201-bis does not address the gen-art review comments nor Francis Dupont's comments, and I haven't seen any follow-up discussion on Francis' comments. What do the authors believe the status of these two comment threads is? ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] RFC5201-bis and RFC5202-bis status
On 09/06/2014 08:25 AM, Ted Lemon wrote: It looks like the latest rev of 5201-bis does not address the gen-art review comments nor Francis Dupont's comments, and I haven't seen any follow-up discussion on Francis' comments. What do the authors believe the status of these two comment threads is? Ted, I believe that there is only one open issue left from the Gen-Art review, regarding possible plaintext attacks: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 The list discussion on this issue leans against making any change; see the last message of this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html I think I previously handled all of the other comments; if I missed any, please point them out. I have tried to contact Francis a couple of times regarding clarification of his comments and have not seen a reply. This is tracked in issue: http://trac.tools.ietf.org/wg/hip/trac/ticket/49 I'm cc'ing both Tom Taylor and Francis for any further clarifications. - Tom ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] RFC5201-bis and RFC5202-bis status
The new RFC5201-bis [1] draft implements the following changes, discussed on the list: o Clarify that receipt of user data in state CLOSING (Table 7) results in transition to I1-SENT o Add academic reference for the first mention of the RSA algorithm o As part of comment resolution on use of NULL encryption, note that use of a NULL HIP CIPHER is only to be used when debugging and testing the HIP protocol. This only pertains to the ENCRYPTED parameter, which is optional; in practice, if encryption is not desired, better to just not encrypt the Host ID. I believe that the open issue on NULL encryption as a MTI (DISCUSS) on RFC5202-bis [2] (also updated today) is closed now, and the following items remain on RFC5201-bis: 1) proposal to address possibility of a plaintext attack: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 I am not sure whether there is support or a concrete text proposal to change this? 2) proposal to add support for 2048-bit DHE (discussed on the list this week) http://trac.tools.ietf.org/wg/hip/trac/ticket/46 The current proposal is to add support for this in the next version, unless further comments are received. 3) update Appendix C example packet http://trac.tools.ietf.org/wg/hip/trac/ticket/50 4) tracking considerations for HIP http://trac.tools.ietf.org/wg/hip/trac/ticket/47 Stephen most recently said: However, I won't press this if you don't wanna go there now - it'd be a large enough change and would probably take time. I'll clear this one and if the WG want they can decide to pursue that goal. So perhaps this should serve as a last call on this issue--does anyone in the WG want to pursue a change in this area? 5) I just noticed this suggestion from Barry Leiba and will pick this up in version 18:. In the IANA Considerations, similar to what was done for R1_COUNTER, I suggest this: OLD A new value (579) for a new Parameter Type HIP_CIPHER should be added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577) which can be left in the table with existing reference to [RFC5201]. NEW A new value (579) for a new Parameter Type HIP_CIPHER should be added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577) which can be left in the table with existing reference to [RFC5201]. For clarity, we recommend that the name for the value 577 be changed from HIP_TRANSFORM to HIP_TRANSFORM (v1 only). END - Tom [1] http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-17.txt [2] http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5202-bis-07.txt ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
