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

[Dan Harkins <[e-mail]>]

   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:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>>     <mailto:[e-mail]>> 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 <[e-mail]
>>     <mailto:[e-mail]>> 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
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/ipsec
>>         <https://www.ietf.org/mailman/listinfo/ipsec>
>>
>>
>>
>>     -- 
>>     Daniel Migault
>>     Ericsson
>>     _______________________________________________
>>     IPsec mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/ipsec
>>     <https://www.ietf.org/mailman/listinfo/ipsec>
>
>
>
> -- 
> Daniel Migault
> Ericsson

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