Re: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01

[Benjamin Kaduk <[e-mail]>]

On Wed, May 17, 2017 at 11:54:03AM -0400, Greg Hudson wrote:
> I have reviewed this draft and have no blocking objections.  Some
> non-blocking, editorial notes:
> 
> Interoperability concerns are listed last for RC4, but second out of
> three subsections for DES3.

To some extent the section structure for the two ciphers are
completely different, but I do see some argument for putting interop
concerns last in both cases; I'll make that change.

> Section 5.2, "Modern encryption types such as [...] use" should have a
> comma before "such as" and before "use".

I think this is technically a stylistic matter, but my normal
tendency is to overuse commas (so that I have to consciously correct
for it); I'm happy to put them back.

> Section 5.2, "It is also best practice when [...], to" should have a
> comma before "when".  Also, "it is also best practice" doesn't seem
> right.

Sure, these commas need to come in pairs.  Is dropping to just "it
is best practice" enough of an improvement to make you happy?
(There's not really a preceeding instance that would make the "also"
useful.)

> Section 5.3, "Because [...], this means that these application servers
> also possess" should omit "this means that".  I would also remove the
> parenthetical for that sentence.

Done.

> Section 5.4, "cross-realm situations" should perhaps be "cross-realm
> deployments".

Sure.

> Section 6, in "ample justification for deprecating their use", "their"
> appears to refer back to "The flaws", which doesn't seem quite right.

I think "their" was trying to be representing the plural "triple-DES
based encryption types".  That's rather clunky, so I'll just go for
"deprecating its use", which I think is sufficiently unambiguous.

> Section 6, "blocksize" should be "block size".

Yup.

> Section 6.1, "[nfold] is known not to provide effective mixing of the
> input bits" is not backed up by a reference.  (I don't know of a
> reference.)

I don't know of a reference, either.  I don't really want to drop
down to a weaker statement like "not expected to provide effective
mixing", as I have a vague memory of someone telling me that (e.g.)
it was hard to get things with the high bit set when an ASCII
password is used.  If the lack of reference becomes problematic for
IETF/IESG review we can certainly revisit the question (and try to
get something closer to primary data).

-Ben