Deprecate 3DES and RC4 in Kerberos
draft-ietf-curdle-des-des-des-die-die-die-05

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Mirja K├╝hlewind Discuss

Discuss (2017-09-04 for -04)
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.

Ben Campbell Yes

Comment (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.

Alexey Melnikov Yes

Kathleen Moriarty Yes

Comment (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.

Eric Rescorla Yes

Adam Roach Yes

Alia Atlas No Objection

Deborah Brungard No Objection

Benoit Claise No Objection

Spencer Dawkins No Objection

Comment (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 No Objection

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.

Terry Manderson No Objection

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.

Alissa Cooper No Record