[IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT)

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]