Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

I thought the purpose of the draft was to be able to say "look at this
document it says you MUST switch to IKEv2 if you want to remain IPsec
interoperable. I am suprised I do not see the MUST in question. I am fine
whatever chair/co-authors are fine with.

Yours,
Daniel

On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir <ynir.ietf@gmail.com> wrote:

> [no hats]
> I don’t want to start (or resume) a religious holy war about uppercase
> MUSTs, but they’re usually about protocol compliance. What people should
> (not SHOULD) do with their systems is not subject to requirements language,
> because the IETF does not engineer administrators. What? You are not
> compliant with RFC xxxx if you didn’t upgrade your systems already?
>
> I could understand a statement that Product yyyy is not compliant with RFC
> xxxx because it still offers IKEv1, but I don’t like non-compliant
> administrators. Not that I’m advocating to add that statement to the draft.
> I think it’s fine as it is: just offering advice that systems should be
> upgraded.
>
> Yoav
>
> On 29 Jun 2021, at 17:21, Daniel Migault <mglt.ietf@gmail.com> wrote:
>
> I believe that the first sentence of section 3 says it all. ship it!
>
> I still have some minor comments, though these may have already been
> discussed. There are no normative MUST to upgrade ( and in general very
> little normative language).
> Shouldn't we have for example:
> Systems running IKEv1 should be upgraded and reconfigured to run IKEv2.
>
> moved to :
>
> Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2.
>
>
> There are overall very little number of SHOULD/MUST but maybe that is an
> editorial choice.
>
> Yours,
> Daniel
>
>
>
>
>
> Yours,
> Daniel
>
> On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>>    Hi,
>>
>> On 6/28/21 1:23 AM, Valery Smyslov wrote:
>> > Hi,
>> >
>> > I think document is mostly ready. Few observations:
>> >
>> > - FWIW I think that Dan's efforts to make draft's language less
>> speculative and more concrete
>> >     are valid and should be reflected in the document.
>> >
>> > - Is it OK that the intended status is Standards Track? Shouldn't it be
>> BCP?
>> >
>> > - The draft states that it updates RFC 7296, 8221, 8247. What in
>> particular is being updated?
>> >     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?
>> >
>> > - 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 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.
>>
>>    regards,
>>
>>    Dan.
>>
>> --
>> "The object of life is not to be on the side of the majority, but to
>> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>
> --
> Daniel Migault
> Ericsson
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>

-- 
Daniel Migault
Ericsson