Subject: [Curdle] Adoption of rc4-die-die-die document

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Aug 2017 19:48:28 +0000

We have adopted draft-ietf-curdle-rc4-die-die-die.  Full doc details are at https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/

There are concerns that this document is over-reaching our charter, and that a document to remove RC4 from all protocols is beyond our scope.  It is hard to argue with that ☺

Should we ask to expand the charter?  Daniel suggested maybe a crypto policy document, but that probably belongs in SAAG or even IESG.

So what should be taken out of this document so that we can move forward?   Or should we ask for the ability to condemn RC4 for all of the IETF?

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 16 Aug 2017 12:56:59 -0700

Salz, Rich <[email-masked]> writes:

> We have adopted draft-ietf-curdle-rc4-die-die-die. Full doc details
> are at
> https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/
> 
> There are concerns that this document is over-reaching our charter,
> and that a document to remove RC4 from all protocols is beyond our
> scope. It is hard to argue with that ☺
> 
> Should we ask to expand the charter? Daniel suggested maybe a crypto
> policy document, but that probably belongs in SAAG or even IESG.
> 
> So what should be taken out of this document so that we can move
> forward? Or should we ask for the ability to condemn RC4 for all of
> the IETF?

Yes, this is probably technically an IESG issue.

I think that means it is up to our ADs if they want to shepherd this
document to the general IESG, or split it into multiple RFCs for each
area. I am just not sure.

That said, I believe RC4 should be condemned for all of the IETF. So,
who do we need to ask for the ability to speak for all of the IETF about
the insecurity of RC4?

	-- Mark

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 17 Aug 2017 10:12:37 +0400

On Wed, Aug 16, 2017 at 11:48 PM, Salz, Rich <[email-masked]> wrote:
> We have adopted draft-ietf-curdle-rc4-die-die-die.  Full doc details are at
> There are concerns that this document is over-reaching our charter, and that
> a document to remove RC4 from all protocols is beyond our scope.  It is hard
> to argue with that J
>
>
>
> Should we ask to expand the charter?  Daniel suggested maybe a crypto policy
> document, but that probably belongs in SAAG or even IESG.
>
>
>
> So what should be taken out of this document so that we can move forward?
> Or should we ask for the ability to condemn RC4 for all of the IETF?
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

I think that it's better that the document is broken up into smaller
documents for each protocol that uses RC4. It appears to overlaps with
other drafts that are targetting specific documents.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Aug 2017 15:32:00 +0000

➢ That said, I believe RC4 should be condemned for all of the IETF. So,
➢ who do we need to ask for the ability to speak for all of the IETF about
➢ the insecurity of RC4?
    
It would start with our AD, Eric.  Ping Eric ☺

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Aug 2017 09:34:31 -0700

Kathleen and I are discussing how best to proceed and will get back to you
shortly.

Best,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Aug 2017 14:29:04 -0700

Hi Rich,

Given the cross-area nature of this work, we think it would be best if you
presented it at the SECDISPATCH meeting in Singapore (see my post
a few minutes ago at SAAG for context). Then we can use that process
to figure out the best approach.

Best,
-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Aug 2017 22:46:14 +0000

➢ Given the cross-area nature of this work, we think it would be best if you
presented it at the SECDISPATCH meeting in Singapore (see my post
a few minutes ago at SAAG for context). Then we can use that process
to figure out the best approach.

Happy to do so.