On Mon, 28 Jun 2021, Dan Harkins wrote:
On 6/28/21 1:23 AM, Valery Smyslov wrote:
- Is it OK that the intended status is Standards Track? Shouldn't it be BCP?
I think because it contains IANA actions, it should be Standards Track.
- The draft states that it updates RFC 7296, 8221, 8247. What in particular is being updated?
From the abstract:
A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. This document adds a Status column to the IANA IKEv2 Transform Type registries.
I believe the recent IESG directives require a short explanation of what is being updated to be present in Abstract. In any case, it should be clearly indicated in the body of the document. Have I missed it?
I think you did? :)
- Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every aspect." is a bit too vague.You know, that was bugging me too. "in every aspect" is laying it on a bit thick. IKEv1 has a security proof. The much maligned PSK mode authenticates the key as well as the exchange which is better than what IKEv2 does (and why IKEv1 did not need an update to do PQC). So saying it's less secure "in every aspect" just isn't true. But I couldn't figure out a better way to say it....
I have removed "in every aspect", as the text was proposed by Dan, and now proposed for removal by Dan.
I believe it's better to list security aspects where we believe IKEv2 is superior: * IKEv2 supports modern cryptographic primitives, including AEAD ciphers * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS (puzzles, RFC 8019) attacks * support for post-quantum crypto in IKEv2 is being developed (draft-ietf-ipsecme-ikev2-multiple-ke) * IKEv2 supports various authentication methods via integration with EAP (core spec) * an extension that allows build PAKE methods in IKEv2 exists (RFC 6467) * did I forget something?But this is great! I agree that such a brief summary of the superior features would be better than a factually challenged "in every aspect" statement.
Listing the good new stuff does not really put the focus on the deployed old bad stuff. I believe it is better to focus on why IKEv1 is bad. But I have added a paragraph paraphrasing this text. I did not use a bullet list to make it more informal and not look like it is claiming a complete list of items. I also removed DH 5 from mentioned as some indicated it is probably still pretty safe, so I changed "2 and 5" to "1 and 2". And I incorporated Valery's earlier comments. Diff available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-02.txt Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
