AD review of draft-ietf-krb-wg-camellia-cts

Hi all,

My AD review of this is below. Thanks for a nice
and nicely-short document!

The only thing that I'd like before I start IETF LC
is an answer on the IPR question at the top (or a
discussion about that if need be). All the other
stuff can be considered along with other IETF LC
comments.

Cheers,
S.

- The IPR declaration (#1304) is noted in the write-up
but not specifically associated with this draft, so
it wouldn't show up so easily for reviewers but I can
call that out specifically in the IETF LC message, but
there is another issue: that declaration refers for
example to things that are required for compliance
with a standard. However, the wg are proposing this
as informational, so it may be less clear to IETF
LC reviewers if the terms in the declaration apply
or not. Did the WG consider that difference when
deciding to go for informational?

(Note: In some cases, when we've told folks who made
declarations about this ambiguity they've been
happy to modify the language. I don't know if that
applies here or not and of course we cannot force
anyone to use specific language in their declarations,
but letting IPR holders know about it can help.)

- I think section 5 needs to say that the output of
CMAC is 128 bits regardless of key size. At present
that's only explicitly stated in the IANA considerations
and is implicit in the security considerations and
the samples. You could add something like "For this
specification, the CMAC Tlen is set to 128 bits,
that is, checksums are 128 bits long, regardless of
the key length."

- section 6 could do with a reference to the section of
whatever RFC says these are the parameters you need. I guess
that's [1], if so, the ordering is a little different here -
keeping the same order would have helped me a little to check
that nothing's missing.

   [1] http://tools.ietf.org/html/rfc3961#section-3

- section 6: 3961 says some things take UTF-8 as input
but you never mentioned UTF-8 here at all, do you need
to?

- Side note: while I'm not keen myself on ciphersuite
proliferation, when a wg wants it, as in this case, its not
my job to get in the way, especially when the wg have
specifically considered that aspect as you have here
in deciding that you want this as informational and
not standards-track. (I'm just saying this in case
someone says to me later: "but you said Camellia was
ok.";-)

nits:

- section 2: "The Camellia key space is dense" that's either
a non-trivial statement (in which case a reference would be
good) or else is trivial, in which case maybe just get rid of
it as it might confuse. (Even nittier nit: s/random octet
string/octet strings/)

- section 3 has an implicit pointer to section 4, where
KDF-FEEDBACK-CMAC is defined. Maybe add a pointer or swap the
order of sections 3 & 4.

- please say somewhere that "|" means catenation. (Personally
I prefer "||" but whatever.)

- section 6: are the en/de-cryption functions sufficiently
well specified that a coder can work from just this? I'm
guessing they are ok, but be nice to know if that's
happened.

- In cross-checking section 6 with 3961 section 3 I
wasn't sure that the "string-to-key parameter format"
that needs to be specified is clearly specified.
(Note: I just did a mechanical check that the
things called for by 3961 are present, I didn't
really dive into it fully.)

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg