Subject: [Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 04 Sep 2017 06:47:46 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is mainly a processing question, so probably more for the IESG to discuss
than the authors:

I understand the intention of obsoleting RFC4757 to declare that the algorithms
described should not be used anymore, however, rfc4757 is an informational
implementation description which is probably still deployed. Obsoleting an
informational implementation description seems a bit weird. Just would like to
double-check with the rest of the IESG if that action appropriate...?

Also obsoleting and moving to historic is not the same thing. The document says:
"This document recommends the reclassification of [RFC4757] as Historic."
One of the two actions (obsoleting or moving to historic) is enough. While I
think moving to historic might actually be more appropriate than obsoleting an
implementation description, it should only be moved to historic if this is not
used and deployed anymore. Also moving to historic also requires a status
change action.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Sep 2017 05:16:22 -0700

The situation here is that the algorithms are still in use, but we want
people to stop using them.

Based on Mirja's comments, it seems like neither of these is exactly on
point. Personally, I'm happy with any, all, or none of these actions.

Given this situation, what do others think?

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Sep 2017 12:19:46 +0000

Isn’t the IESG free to take up the recommendation and state-change at any time?

I think this document clearly says DON’T DO THIS in big flashing letters and that all signals for this are needed.

From: Eric Rescorla <[email-masked]>
Date: Thursday, September 14, 2017 at 8:16 AM
To: Mirja Kuehlwind <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Daniel Migault <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS)

The situation here is that the algorithms are still in use, but we want people to stop using them.

Based on Mirja's comments, it seems like neither of these is exactly on point. Personally, I'm happy with any, all, or none of these actions.

-Ekr

On Mon, Sep 4, 2017 at 6:47 AM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:
Mirja Kühlewind has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=R9dQevG8PLVFbDTM8hYkD6F5vIKwSt2MlrQWljSDXUg&s=Hvoq5FlZrgHrvNKXRmo0X3TsQdN1lVCxgGySnepomGI&e=>
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle-2Ddes-2Ddes-2Ddes-2Ddie-2Ddie-2Ddie_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=R9dQevG8PLVFbDTM8hYkD6F5vIKwSt2MlrQWljSDXUg&s=fHroUSWth-UnDWMMvPdhnWbvMyG9CW9s5EKTBEfK7yI&e=>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Sep 2017 09:02:32 -0400

Thanks Mirja for raising this question. I agree that "Historic" may be
better than "Obsoleted" as far as the content of RFC4757 is concerned. I
believe that the "Obsolete" status is mostly motivated by the usage of
3DES. Maybe the ambiguity is that RFC4757 is both a protocol description as
well as reference to use the protocol. RFC4757 is referenced by the IANA
[1]. For that reason obsoleting the document would create a link between
the old reference and the new one. That is 1) RFC4757 clearly mentions the
current RFC is expected to be considered. This means that if you folllow
RFC4757 you cannot ignore teh new RFC which says do not use it.

A similar question could be what reference should be placed on the IANA
page. I discussed this aspect with the IANA say that implementation
description or the document obsoleting the code point can be used.

If a discussion happen I believe that would be good to provide guidance. I
am happy with any decision made by the IESG and happy to help providing
such guidance.

[1]
https://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.txt

On Thu, Sep 14, 2017 at 8:19 AM, Salz, Rich <[email-masked]> wrote:

> I think this document clearly says DON’T DO THIS in big flashing letters
> and that all signals for this are needed.
>
>
>
>
>
> *From: *Eric Rescorla <[email-masked]>
> *Date: *Thursday, September 14, 2017 at 8:16 AM
> *To: *Mirja Kuehlwind <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, Daniel Migault <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Curdle] Mirja Kühlewind's Discuss on
> draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS)
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=R9dQevG8PLVFbDTM8hYkD6F5vIKwSt2MlrQWljSDXUg&s=Hvoq5FlZrgHrvNKXRmo0X3TsQdN1lVCxgGySnepomGI&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle-2Ddes-2Ddes-2Ddes-2Ddie-2Ddie-2Ddie_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=R9dQevG8PLVFbDTM8hYkD6F5vIKwSt2MlrQWljSDXUg&s=fHroUSWth-UnDWMMvPdhnWbvMyG9CW9s5EKTBEfK7yI&e=>
>
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Sep 2017 15:46:29 +0200

On 9/4/2017 3:47 PM, Mirja Kühlewind wrote:
> implementation description,
Historical makes sense. So does it mean that 
draft-ietf-curdle-des-des-des-die-die-die is used as "status-change" 
document in 
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html?
> it should only be moved to historic if this is not
> used and deployed anymore.
Where does this condition come from?

Regards, B.
> Also moving to historic also requires a status
> change action.
>
>
>
>
> .
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Sep 2017 07:29:00 -0700

Per today's discussion on the IESG Call, the resolution is:

1. Move 4757 to Historic
2. Include a sentence saying that people still use these algorithms (both,
actually) but we are moving things to Historic to tell you not to.

OK?
-Ekr

On Thu, Sep 14, 2017 at 6:46 AM, Benoit Claise <[email-masked]> wrote:

> Historical makes sense. So does it mean that draft-ietf-curdle-des-des-des-die-die-die
> is used as "status-change" document in https://www.ietf.org/iesg/stat
> ement/designating-rfcs-as-historic.html?
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Sep 2017 07:30:23 -0700

Oh, and don't mark things as obsolete :)

On Thu, Sep 14, 2017 at 7:29 AM, Eric Rescorla <[email-masked]> wrote:

>> document in https://www.ietf.org/iesg/statement/designating-rfcs-as-hist
>> oric.html?
>>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Sep 2017 14:32:58 +0000

Works for me. Thanks.
Yours,
Daniel

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, September 14, 2017 10:30 AM
To: Benoit Claise <[email-masked]>
Cc: Mirja Kühlewind <[email-masked]>; The IESG <[email-masked]>; [email-masked]; Daniel Migault <[email-masked]>; curdle <[email-masked]>; curdle <[email-masked]>
Subject: Re: [Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS)

On Thu, Sep 14, 2017 at 7:29 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Per today's discussion on the IESG Call, the resolution is:

1. Move 4757 to Historic
2. Include a sentence saying that people still use these algorithms (both, actually) but we are moving things to Historic to tell you not to.

OK?
-Ekr

On Thu, Sep 14, 2017 at 6:46 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
On 9/4/2017 3:47 PM, Mirja Kühlewind wrote:
Mirja Kühlewind has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

Historical makes sense. So does it mean that draft-ietf-curdle-des-des-des-die-die-die is used as "status-change" document in https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html?

Regards, B.

.

_______________________________________________
Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 14 Sep 2017 09:55:04 -0500

> 2. Include a sentence saying that people still use these algorithms (both, actually) but we are moving things to Historic to tell you not to.

I'm currently looking at (in addition to the other changes prompted by
IESG evaluation):

diff --git a/draft-ietf-curdle-des-des-des-die-die-die.xml b/draft-ietf-curdle-des-des-des-die-die-die.xml
index 9db9438..0a853ae 100644
--- a/draft-ietf-curdle-des-des-des-die-die-die.xml
+++ b/draft-ietf-curdle-des-des-des-die-die-die.xml
@@ -10,7 +10,7 @@
 ]>
 <?rfc toc="yes"?>
 <?rfc tocdepth="2"?>
-<rfc category="bcp" ipr="trust200902" docName="draft-ietf-curdle-des-des-des-die-die-die-04" submissionType="IETF" obsoletes="4757" updates="3961,4120">
+<rfc category="bcp" ipr="trust200902" docName="draft-ietf-curdle-des-des-des-die-die-die-04" submissionType="IETF" updates="3961,4120">
   <front>
     <title>Deprecate 3DES and RC4 in Kerberos</title>
     <author initials="B." surname="Kaduk" fullname="Benjamin Kaduk">
@@ -30,7 +30,7 @@
       <t>The 3DES and RC4 encryption types are steadily weakening in
 	cryptographic strength, and the deprecation process should be
 	begun for their use in Kerberos.  Accordingly, RFC 4757 is moved
-	to Obsolete status, as none of the encryption types it specifies
+	to Historic status, as none of the encryption types it specifies
 	should be used, and RFC 3961 is updated to note the deprecation
 	of the triple-DES encryption types.
       </t>
@@ -41,7 +41,7 @@
       <t>The 3DES and RC4 encryption types are steadily weakening in
 	cryptographic strength, and the deprecation process should be
 	begun for their use in Kerberos.  Accordingly, RFC 4757 is moved
-	to Obsolete status, as none of the encryption types it specifies
+	to Historic status, as none of the encryption types it specifies
 	should be used, and RFC 3961 is updated to note the deprecation
 	of the triple-DES encryption types.
       </t>
@@ -61,6 +61,9 @@
 	are in use with no formal specification, in particular
 	des3-cbc-md5 and des3-cbc-sha1.  These unspecified encryption
 	types are also deprecated by this document.</t>
+      <t>Though the RC4 and 3DES encryption types are still in use in
+	some deployments, the above status changes are made to indicate
+	that these encryption types should no longer be used.</t>
     </section>
     <section title="Affected Encryption Types">
       <t>The following encryption types are deprecated.  The numbers

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Should I go ahead and upload with that?

Thanks,

Ben