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

From: Yoav Nir <[email-masked]>
Date: Sat, 26 Jun 2021 11:38:12 +0300

Hi, all.

Although this draft is really new, having been submitted in April of this year, its predecessor draft has been under discussion since March of 2019.

This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new, short messages in the vein of “Yeah, this is good. Ship it”, but substantive comments are, of course, even more welcome.

The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.

Thanks

---

From: Yoav Nir <[email-masked]>
Date: Sat, 26 Jun 2021 11:41:59 +0300

Forgot to add a link to the draft:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/>

> On 26 Jun 2021, at 11:38, Yoav Nir <[email-masked]> wrote:
> 
> Hi, all.
>

---

From: Dan Harkins <[email-masked]>
Date: Sun, 27 Jun 2021 00:27:10 -0700

I sent substantive comments on this draft to the list on May 6th of this
year. They were not addressed so they apply to this WGLC.

   Dan.

On 6/26/21 1:38 AM, Yoav Nir wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
"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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 27 Jun 2021 11:23:38 -0400

Yoav Nir <[email-masked]> wrote:
    > Although this draft is really new, having been submitted in April of
    > this year, its predecessor draft has been under discussion since March
    > of 2019.

Agreed.

    > This begins a 2-week WGLC. Please read the draft and post comments to
    > the list. Since this is rather new, short messages in the vein of
    > “Yeah, this is good. Ship it”, but substantive comments are, of course,
    > even more welcome.

Re-read to be sure.
Ship it.

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 Jun 2021 21:32:13 +0300

To facilitate this discussion:

The comments are in this message: https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/ <https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/>

Paul repled with this: https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/ <https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/>

Dan replied with this: https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/ <https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/>

Tero: https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/ <https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/>

And finally, Dan: https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/ <https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/>

If I read this correctly, the last two messages are about some of decision-making process in IKEv2 drafts, so it’s not relevant to the draft now in WGLC.

Can I assume the unaddressed points are those in the third message?

Yoav

> On 27 Jun 2021, at 10:27, Dan Harkins <[email-masked]> wrote:
> 
>

---

From: Dan Harkins <[email-masked]>
Date: Sun, 27 Jun 2021 12:24:50 -0700

Hi Yoav,

   Thanks for facilitating this discussion (especially given the 
editor's issues with
interacting with me). Yes, the unaddressed points are in the 3rd email. 
Everything
above the "there is another IKEv1 feature not available in IKEv2" line 
are my
unresolved comments, everything below that is further discussed in the 
final 2 emails
and is not relevant to the comments I made on the draft.

   Basically, I want to get rid of the speculative language and the 
guesswork language
which is  not really even necessary to make the case. I also provided 2 
reworded
paragraphs which I think improve the draft and are more clear. Of 
course, that's my
opinion, it's open to debate and disagreement, but if others agree with 
me then I
think these changes should be adopted by the editor.

   regards,

   Dan.

On 6/27/21 11:32 AM, Yoav Nir wrote:
> The comments are in this message: 
> https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/
>
> Paul repled with this: 
> https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/
>
> Dan replied with this: 
> https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/
>
> Tero: 
> https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/
>
> And finally, Dan: 
> https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/
>
> If I read this correctly, the last two messages are about some of 
> decision-making process in IKEv2 drafts, so it’s not relevant to the 
> draft now in WGLC.
>
>> On 27 Jun 2021, at 10:27, Dan Harkins <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>> this year, its predecessor draft has been under discussion since 
>>> March of 2019.
>>>
>>> This begins a 2-week WGLC. Please read the draft and post comments 
>>> to the list. Since this is rather new, short messages in the vein of 
>>> “Yeah, this is good. Ship it”, but substantive comments are, of 
>>> course, even more welcome.
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Jun 2021 22:02:22 -0400 (EDT)

On Sun, 27 Jun 2021, Dan Harkins wrote:

>   Thanks for facilitating this discussion (especially given the editor's issues with
> interacting with me).

I don't want to keep focussing on this, but again I need to
defense myself. I have no issues with interacting with you on public
mailing lists. I have a personal opinion that your behaviour has been
inappropriate enough towards me and other groups of people that I wish
no longer interact with you via non-public emails. I believe that is
within my rights. This does not interfere with me responding to on topic
discussion where I am acting in an official IETF capacity, such as
Document Author or Working Group Chair.

> Yes, the unaddressed points are in the 3rd email. Everything
> above the "there is another IKEv1 feature not available in IKEv2" line are my
> unresolved comments, everything below that is further discussed in the final 2 emails
>   Basically, I want to get rid of the speculative language and the guesswork language
> which is  not really even necessary to make the case. I also provided 2 reworded
> paragraphs which I think improve the draft and are more clear. Of course, that's my
> opinion, it's open to debate and disagreement, but if others agree with me then I

At the time, I was waiting for more comments before updating the
document. I have now pushed these changes. I've taken in some text of Dan,
although I did not remove everything he suggested removing because I deem
those bits have value to bring across. If other people wish to chime in,
that would be useful to determine consensus.

The changes to the document are minor, so I think this can be evaluated as
part of this WGLC, but the final decision on that rests with the chairs.

https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-01

Paul

---

From: Dan Harkins <[email-masked]>
Date: Sun, 27 Jun 2021 20:33:23 -0700

On 6/27/21 7:02 PM, Paul Wouters wrote:
> no longer interact with you via non-public emails. 

   Yet all these problematic non-public email interactions seem to have been
initiated by you! (I have the receipts).

> I believe that is within my rights. 

   If only you would give that accommodation ("my rights") to me.

   But whatever, it's not really an IPsecme issue.

> This does not interfere with me responding to on topic

   Or document *editor*, as is the case here.

> that would be useful to determine consensus.

   I still think there is a problem in providing speculative text about 
some vendors
and their potentially "unmaintained code". Unless you're prepared to 
state which
vendors are not maintaining their code to the detriment of their 
customers I don't
think you should allude to such a situation. And I really don't think an 
RFC is the
appropriate vehicle to describe such vendor behavior even if you were gonna
describe it.

   The draft does not need to engage in such speculation. There are 
plenty of other
concrete, definitive reasons to send IKEv1 to historic. This 
coulda/shoulda/woulda
stuff is not necessary and actually detracts from the draft.

> part of this WGLC, but the final decision on that rests with the chairs.

   Actually it rests with the group. This is a document of the working 
group.

   Dan.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 28 Jun 2021 11:23:32 +0300

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.
  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?
   
- Section 4.3. Formally RFC 6407 is not directly concerned with IKEv1.
   This is an independent protocol developed by msec WG that was based on IKEv1.
   I think more accurate language should be used to make this clear. For example:

       Group Domain of Interpretation (GDOI, RFC 6407) protocol based on IKEv1
       defines the support for Multicast Group SAs.

   I also think that reference to RFC 3740 should be remove (it doesn't even mention IKE
   in any substantial way). I'm not so sure about RFC 5374, but I'm inclining 
   to remove it too - it's mostly concerned with MCAS architecture and doesn't
   define any concrete IKEv1 changes to support it. So, leave only RFC 6407.

- Section 5 lists deprecated algorithms. In my reading this list
   is inconsistent with Section 7 (IANA Considerations) which lists
   many more deprecated algorithms... So, I'm a bit puzzled
   how to read this section.

- The draft currently has all its references as Normative.
   I have no problems with this (except that RFC 3740 is Informational,
   so should not be referenced as Normative in Standards Track and BCP documents,
   but I suggested to remove it anyway). My concern is that 
   referencing active drafts as Normative will lead to slow down
   publication of this document until those drafts are published.
   I don't think it's a major problem (we will have an incentive 
   to work harder on these drafts :-)), just should be noted.

Regards,
Valery.

> This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new,
> short messages in the vein of “Yeah, this is good. Ship it”, but substantive comments are, of course, even
> more welcome.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Jun 2021 10:56:03 -0400 (EDT)

>   are valid and should be reflected in the document.

I did change the wording to remove the quantifiers, eg from "a number
of vendors" to "There are vendors that".

> - Is it OK that the intended status is Standards Track? Shouldn't it be BCP?

We are deprecating a few algorithms and adding an IANA column. That is
not really BCP work.

>   to be present in Abstract. In any case, it should be clearly indicated in the body of the document.

It updates the IANA registries and deprecates a number of algorithms
defined. It is really updating RFC 4306 section 6 IANA Considerations,
but 4306 is obsoleted by 5996 which is obsoleted by 7296.

https://datatracker.ietf.org/doc/html/rfc4306#section-6

The 8221/8247 RFC's state non-mentioned algorithms remain in their MAY
state, and this draft updates some of those "unmentioned therefor MAY"
to DEPRECATED.

>  * did I forget something?

I'm okay either way. Originally, I didn't want to go into too much
detail, but if the WG wants to add these, we can do that.

>   define any concrete IKEv1 changes to support it. So, leave only RFC 6407.

I'm fine with this change. Queued up for next version.

>   how to read this section.

There was one error.  AUTH_HMAC_SHA1_160 should be added to 4.3.
The other "additional" entries are those that have been deprecated
already by RFC 8247, but are listed here so that IANA will add the
deprecated keyword in the new column.

>   to work harder on these drafts :-)), just should be noted.

You are right, they should be changed to Informative.

I'll wait another day or so for further feedback, then push another
update.

Thanks,

Paul

---

From: Dan Harkins <[email-masked]>
Date: Mon, 28 Jun 2021 16:17:13 -0700

Hi,

> - 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....

>    * 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.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 29 Jun 2021 10:21:38 -0400

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 <[email-masked]> wrote:

> > - Section3: I think that phrase "IKEv2 is a more secure protocol than
> IKEv1 in every aspect." is a bit too vague.
>

-- 
Daniel Migault
Ericsson

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Jun 2021 21:00:30 +0300

[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 <[email-masked]> wrote:
> 
> 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). 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>    Hi,
> 
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> 
> -- 
> Daniel Migault
> Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Tue, 29 Jun 2021 14:17:02 -0400

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 <[email-masked]> 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
>

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Jun 2021 15:19:25 -0400

On Jun 29, 2021, at 14:17, Daniel Migault <[email-masked]> wrote:
> 
> 
> 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. 

I agree with Yoav, the RFC 2119 language is for code implementations, not humans.

People outside the IETF may see the whole document as a MUST for compliance, which is good for us :)

Paul

---

From: Dan Harkins <[email-masked]>
Date: Tue, 29 Jun 2021 12:25:19 -0700

Hi Daniel,

   That seems to be part of the problem. The IETF isn't in the business 
of dictating
administrative behavior through normative language. Protocols comply. 
People can use
compliant protocols or not, and if they decide to use protocols which 
are non-compliant,
or if they use proprietary protocols, it doesn't make them somehow 
"non-compliant".

   This effort seems to have gained steam due to developers being told 
by their project
management co-workers to do things to their IKEv1 code which they did 
not think was
appropriate given the state of IKEv2. I can certainly relate to such 
difficult interactions.
That said, the give-and-take of engineering and project/product 
management is not really in
the IETF's bailiwick. If people want to take an RFC to the 
project/product management
team and say, "look, the IETF has spoken!" then good luck, but that is a 
misuse of the
imprimatur of the IETF and don't try and standardize _that_ behavior.

   We can move a standard to historic. We can decide not to do any more 
development on it.
We can't force people to do anything and we can't declare they are 
"non-compliant" if
they decide to use a protocol we don't approve of.

   It's interesting how SCEP has survived and actually thrived despite 
its restricted
use and it's well-known security problems when EST, an IETF standard, 
exists. People
strung the SCEP draft through multiple dozens of versions, dragging it 
out, it was made
historic as a sop to this effort yet people still want to use it. I 
don't understand but
a very large vendor of tablet and phone hardware/software (who 
ironically stole their OS
name from the company that developed SCEP) decided to use it in their 
BYOD offering
and so product/project management teams all say we must continue to use 
SCEP and update
our SCEP code in order to work with these products that we can't avoid 
due to their
massive market share. Sure, continued use of IKEv1 is a problem but it's 
a molehill
compared to the mountain of today's use of SCEP. Yet here we are.

   Dan.

On 6/29/21 11:17 AM, Daniel Migault wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     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).
>>         >     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.
>>
>>         >    * 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)
>>         <https://www.ietf.org/mailman/listinfo/ipsec>
>>
>>
>>
>>     -- 
>>     Daniel Migault
>>     Ericsson
>>     <https://www.ietf.org/mailman/listinfo/ipsec>
>
>
>
> -- 
> Daniel Migault
> Ericsson