Skip to main content

Deprecate Triple-DES (3DES) and RC4 in Kerberos
RFC 8429

Yes

(Adam Roach)
(Alexey Melnikov)
(Eric Rescorla)

No Objection

(Alia Atlas)
(Benoît Claise)
(Deborah Brungard)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

Comment (2017-09-13 for -04)
This document should formally Update rfc4120: Section 7 includes text which removes encryption/checksum mechanisms from it.

Warren Kumari No Objection

Comment (2017-09-11 for -04)
Thanks to Joel for his OpsDir review.

I have a few comments / readability suggestions:
1: Section 5.1.  Statistical Biases
"These attacks seem to rely on repeated encryptions of thousands of copies of the same plaintext; " -- for a document which deprecates rc4-hmac the "seem to rely on" feels very weak. I'd suggest s/seem// or "At least some of these attacks rely on..." or similar.

2: Section 6.  3DES Weakness
"Additionally, the 3DES encryption types were never implemented in all Kerberos implementations..."
s/never/not/

3:  Section 6.3.  Interoperability
"The triple-DES encryption types were implemented by MIT Kerberos
   early in its development (ca. 1999) and present in the 1.2 release,
   but encryption types 17 and 18 (AES) were implemented by 2003 and
   present in the 1.3 release."
I'm a bit confused by the "but" - should this be "and"? Otherwise it sounds like it it trying to contrast something.

(Adam Roach; former steering group member) Yes

Yes (for -04)

                            

(Alexey Melnikov; former steering group member) Yes

Yes (for -04)

                            

(Ben Campbell; former steering group member) Yes

Yes (2017-09-13 for -04)
Although there is precedent for obsoleting a spec and making it historical at the same time, I agree with Mirja that it doesn't seem to make sense in most cases.

(Eric Rescorla; former steering group member) Yes

Yes (for -04)

                            

(Kathleen Moriarty; former steering group member) Yes

Yes (2017-09-12 for -04)
I agree with Mirja that is seems more appropriate to move RFC4757 to historic.  I'm guessing the choice for obsolete was because of deprecating the algorithms used in the implementation.  Thanks for your work on this draft.

(Alia Atlas; former steering group member) No Objection

No Objection (for -04)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -04)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Mirja Kühlewind; former steering group member) (was Discuss) No Objection

No Objection (2018-05-18)
Sorry, for the late response!

(Spencer Dawkins; former steering group member) No Objection

No Objection (2017-09-12 for -04)
I agree with Mirja's points about Obsoletes vs. Historic, and I didn't think we required a status change document for *all* move-to-Historic status changes, but https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html says that we do.

On the brighter side, that may be the best draft filename I've seen as an AD ...

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -04)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -04)