Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)

2022-12-15 Thread Paul Wouters

On Thu, 15 Dec 2022, Warren Kumari wrote:


Subject: Re: [IPsec] Warren Kumari's Discuss on
draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)


Francesca / Warren: would these changes resolve your points? I kept
the word deprecated as Roman pointed out that is exactly what the TLS
1.0/1.1 document did. But clarified that the usage guidance for the
crypto algorithms is updated by this document. And I added a note for
IANA to add a Note to the registry pages as Francesca recommended:


--- draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt2022-12-15 
16:31:35.171452645 -0500
+++ draft-ietf-ipsecme-ikev1-algo-to-historic-09.txt2022-12-15 
16:36:34.171942102 -0500
@@ -16,11 +16,12 @@

Internet Key Exchange version 1 (IKEv1) has been deprecated and its
specification in RFC2407, RFC2408 and RFC2409 have been moved to
-   Historic status.  A number of old algorithms that are associated with
-   IKEv1, and not widely implemented for IKEv2 are deprecated as well.
-   This document updates RFC 8221 and RFC 8247 and adds a Status column
-   to the IANA IKEv2 Transform Type registries that shows the
-   deprecation status.
+   Historic status.  This document updates RFC 8221 and RFC 8247 to
+   reflect the usage guidelines of old algorithms that are associated
+   with IKEv1 and are not specified or commonly implemented for IKEv2.
+   This document further updates the IANA IKEv2 Transform Type
+   registries to add a Status column where deprecation status can be
+   listed.

 [...]

 7.  IANA Considerations

-   This document instructs IANA to add an additional Status column to
-   the IKEv2 Transform Type registries and mark the following entries as
-   DEPRECATED:
+   This document instructs IANA to insert the following line at the top
+   of the Notes section of the 'Internet Key Exchange (IKE) Attributes'
+   registry and the '"Magic Numbers" for ISAKMP Protocol' registry: All
+   registries listed below have been closed, see RFC.  [Note to RFC
+   Editor: change RFCxxx to this document's RFC number]
+
+   This document further instructs IANA to add an additional Status
+   column to the IKEv2 Transform Type registries and mark the following
+   entries as DEPRECATED:

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)

2022-12-15 Thread Warren Kumari
On Tue, Dec 13, 2022 at 12:51 PM, Warren Kumari  wrote:

> On Tue, Dec 13, 2022 at 10:36 AM, Paul Wouters  wrote:
>
>> On Tue, 13 Dec 2022, Warren Kumari via Datatracker wrote:
>>
>> [speaking with author hat on]
>>
>>
>> --
>> DISCUSS:
>> --
>>
>>
>>
>> Be ye not afraid -- see
>> https://www.ietf.org/about/groups/iesg/statements/
>> handling-ballot-positions/ on handling ballots, especially DISCUSS
>> ballots...
>>
>>
>>
>> Can the IETF actually deprecate / make a protocol historic? (as stated in
>> "Internet Key Exchange version 1 (IKEv1) has been deprecated" and "IKEv1
>> has been moved to Historic status.")
>>
>>
>> I agree that **making the documents that describe these** be historic is
>> the right thing to do, and also that the IETF can strongly recommend that
>> people don't use/deploy/whatever IKEv1, but I don't really know if we (or
>> anyone) have the power to deprecate a protocol. We are not the protocol
>> police, and we cannot instruct people to e.g deploy protocol foo, so I
>> don't know if we can deprecate a protocol either -- but I suspect that this
>> might be because I don't actually know what "IKEv1 has been deprecated"
>> actually *means*.
>>
>> Again, I'm not trying to block what this document is attempting to *do*,
>> but rather make it clear what it is actually doing.
>>
>> What it means is that the IETF has stopped maintaining it. It will not
>> allow any new registrations into the related IANA registries and no new
>> work will be started on this protocol version.
>>
>
>
> Perhaps you could add something to the document saying that (or, even
> better, drop in a reference to an RFC that says that)? From Rob's ballot:
> "I do wonder exactly how well understood "deprecated" is in the wider
> community." - it's not just "in the wider community", because it wasn't
> clear to me *exactly* what it meant.
>


Just following up before the telechat - if we agree to add a clarification
I can clear.

W



>
>> It does not make any recommendations to users or administrators on
>> whether they should stop running it and migrate, although it is a pretty
>> strong hint that this protocol is dying and it would be wise to move away
>> from it.
>>
>> It also means that other documents that want to depend on IKE, have to
>> ensure it works (and references) IKEv2, not IKEv1.
>>
>> The IETF does not tell you which protocols to use or not use. However,
>> other organizations that do, often base their requirements on IETF
>> recommendations. This is where the IETF and others (eg NIST, PCI-DSS) play
>> a careful balancing act. The IETF tries to nudge people in the right
>> direction. But it is indeed not the protocol police.
>>
>
> Yes, we have the BCP series, which "endorses" technical information and
> "define and ratify the community's best current thinking on a statement of
> principle or on what is believed to be the best way to perform some
> operations." That isn't the IETF telling someone what to do, but it is
> basically standing up, pointing, and saying "This thing over here! We think
> that this is a good thing to do!".
>
> Note that the document itself does not deprecate anything.
>>
>
> Well, now I'm confused:
> "This document deprecates those unmentioned algorithms that are no longer
> advised but for which there are no known attacks resulting in their earlier
> deprecation."
> and
> "5.  Deprecating obsolete algorithms
>
> This document deprecates the following algorithms: [...]"
>
> It cannot. Only the IESG can change a document static to historic.
>>
>
>
> I'm unclear if you are arguing that a document doesn't do anything until
> the IESG formally approves it", which feels like a very semantic point. We
> very commonly say that draft-ietf-foo-bar does X (e.g change registry
> policy), even if technically we mean "draft-ietf-foo-bar does X, but only
> after it has completed IETF LC and then IESG Eval and had all of the
> DISCUSSES addressed and then approved"
>
> Perhaps when you said "the document itself does not deprecate anything"
> you were meaning "does not make other documents historic, that is handled
> by the status-change document - https://datatracker.ietf.org/doc/
> status-change-ikev1-to-historic/  " ?
>
> See your other work item on the telechat where this is requested.
>>
>
> Yes. That is partly what drove me to this discussion — in that case, the
> document had originally said: "The document marks as historic…" and Pete
> Resnick (correctly) pointed out that document don't mark things as
> historic, and suggested the new text "The document deprecates the use of
> [..]"
>
> W
>
>>
>> Only after that request passes the IESG, can this document move further
>> and say that
>> "it has happened".
>>
>>
>> Paul
>>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec