Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)
Works for me, and thank you very much! W On Thu, Dec 15, 2022 at 5:01 PM, Paul Wouters wrote: > 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.txt 2022-12-15 > 16:31:35.171452645 -0500 > +++ draft-ietf-ipsecme-ikev1-algo-to-historic-09.txt 2022-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)
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)
Hi! From: IPsec On Behalf Of Warren Kumari Sent: Thursday, December 15, 2022 9:32 AM To: Paul Wouters Cc: The IESG ; draft-ietf-ipsecme-ikev1-algo-to-histo...@ietf.org; ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS) On Tue, Dec 13, 2022 at 12:51 PM, Warren Kumari mailto:war...@kumari.net>> wrote: On Tue, Dec 13, 2022 at 10:36 AM, Paul Wouters mailto:p...@nohats.ca>> 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. [Roman] Clarifying words can certainly be added here. The general practice of “deprecating” a protocol to signal IETF’s position on no longer using the protocol precedence as recently as last year: Deprecating TLS 1.0 and TLS 1.1 https://datatracker.ietf.org/doc/rfc8996/ Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 https://datatracker.ietf.org/doc/rfc9155/ Regards, Roman ___ 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)
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
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)
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. > 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
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)
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. 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. Note that the document itself does not deprecate anything. It cannot. Only the IESG can change a document static to historic. See your other work item on the telechat where this is requested. 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
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-ikev1-algo-to-historic-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ -- 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
