Skip to main content

Last Call Review of draft-ietf-curdle-des-des-des-die-die-die-05
review-ietf-curdle-des-des-des-die-die-die-05-secdir-lc-kivinen-2018-03-29-00

Request Review of draft-ietf-curdle-des-des-des-die-die-die
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-04-24
Requested 2018-03-27
Authors Benjamin Kaduk , Michiko Short
I-D last updated 2018-03-29
Completed reviews Opsdir Last Call review of -03 by Joel Jaeggli (diff)
Genart Last Call review of -04 by Meral Shirazipour (diff)
Secdir Last Call review of -05 by Tero Kivinen
Genart Last Call review of -05 by Meral Shirazipour
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-ietf-curdle-des-des-des-die-die-die by Security Area Directorate Assigned
Reviewed revision 05
Result Ready
Completed 2018-03-29
review-ietf-curdle-des-des-des-die-die-die-05-secdir-lc-kivinen-2018-03-29-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document deprecates 3DES and RC4 in Kerberos. This should have
been done several years ago, so the only problem I have with this
document is that it has year 2017 not 2012 in header :-)

This could go even further as it just marks those weak algorithms as
"SHOULD NOT", and especially the RC4 with unsalted MD4 based
string2key should be marked as "MUST NOT" at least for my opinion.

The document properly explain the reasons why those algorithms are
still there to maintaina backward compatibility with Windows XP and
similars, but as Windows XP is already end of lifed, so I think those
algorithms could also be marked as MUST NOT.

This document also gives recommendations both for Kerberos
implementations and deployments. Normally we do not give instructions
for the adminstrators, we just tell what implementors SHOULD or SHOULD
NOT do.

If we give recommendations to deployments, then I think those should
be MUST NOT instead of SHOULD NOT. I can still see some
implementations wanting to implement those algorithms to allow
backwards compatibility (i.e., go against SHOULD NOT), but no new
deployment should use them ever, and old deployments needs to move
away from them ASAP.

Anyways as a summary I think this document is Ready.
-- 
kivinen@iki.fi