Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic (fwd)

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Oct 2021 17:58:15 -0400 (EDT)

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2021 13:35:26 -0400

> I think because it contains IANA actions, it should be Standards Track.

Agreed.
(It would be funny for it to be Historic, but actually that's wrong)

    > list to make it more informal and not look like it is claiming a

Great.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide