I seem to have missed this email somehow.
Alissa Cooper writes: > Alissa Cooper has entered the following ballot position for > charter-ietf-ipsecme-11-01: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive comments: > > (1) I don't see the value in having an expiration date in a WG charter because > it's not enforced in practice. This has been the way we have been working in the IPsecME WG for long time (I think it was since from the beginning). Most people in the IETF seem to work better if they do have deadline that they need to meet. > The previous version of this charter said the WG would close if the > charter wasn't updated by Dec 2017, but the WG continued to exist > without the charter being updated. This charter seems tightly scoped > enough to just get the work done according to the milestone dates or > close sooner if people lose interest. We did start charter discussion in the November 2017 meeting [1], and did have the charter proposal ready early 2018 (February 2016 [2]). Then we added two more hanging items to it and forwarded it to the ADs on March 19... So from our point of view we were 3 months late... [1] https://datatracker.ietf.org/doc/agenda-100-ipsecme/ [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg11820.html If you feel this is something that we cannot have in charter, we can remove it, but we rather keep it there to make sure we keep charter up to date, and update it every few years. > (2) I think it might be worth a few words to state the reason why the goal was > for the new IKEv2 mode to have the same quantum resistant properties as > existed > in IKEv1, rather than better/fuller quantum resistance. If you are refering to this item: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. Then that is part of the already accepted agenda and the work there is already done, and should be ready to go out very soon (most likely after Montreal IETF). There is another item later in the charter: Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Direct using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. Which goes further protecting against protection against quantum computers, and also explaines what are the issues with it (i.e., why this items is much bigger than the first item). > Nits: > > Based on the number of grammar and wording errors I found in this charter, I > would strongly suggest doing a clean-up pass to make sure all of the text > reads > properly. Here is what I found: > > (1) > s/to have similar quantum resistant properties than IKEv1 had/to have similar > quantum resistant properties that IKEv1 had/ Agree. > (2) > s/in form of counter/in the form of a counter/ Agree. > (3) > I can't parse this sentence: > > "A growing number of use cases for constrained network - but not > limited to - have shown interest in reducing ESP (resp. IKEv2) > overhead by compressing ESP (resp IKEv2) fields." Unfortunately I have no problem parsing the sentence, so I do not know what should be done to fix it. For me it is clear. I.e., there are constrained networks, which want to reduce ESP overhead and because of that want to compress ESP fields. Same for IKEv2. And those needs are not only limited to constrained networks, also other use cases needs them. If you think the text is unclear I would need to have proposal for better text. > (4) > OLD > Currently IKE peers have no explicit way > to indicate each other which signature format(s) the support, that > leads to ineroperability problems. > > NEW > Currently IKE peers have no explicit way > to indicate to each other which signature format(s) they support. That > leads to ineroperability problems. Agreed. > (5) The milestones need to be updated. Some of the dates and draft names are > wrong. I would have assumed the datatracker would have known how to follow replaced drafts automatically, but that does not seem to happen. This means that the draft-mglt-ipsecme-implicit-iv needs to be replaced with draft-ietf-ipsecme-implicit-iv, and draft-pauly-ipsecme-split-dns with draft-ietf-ipsecme-split-dns. Note, all of these draft names are from the old charter, and they have not been updated when the drafts were replaced year ago. All of the dates which are in past are for old chatered drafts, and one of them is already sent to the AD 3 months ago (i.e., before the April deadline), and another two should be ready go out to AD after Montreal. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
