Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-camellia-cts

[Greg Hudson <[e-mail]>]

Thanks for the comments, Stephen.

On 09/07/2012 09:00 AM, Stephen Farrell wrote:
> - 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?

I don't believe we specifically considered this issue, no.  In theory,
the same ambiguity could apply to a "proposed standard" or "draft
standard," perhaps with lower probability.  Is there anything you'd like
us to do about this before last call beside answer the specific question?

> - I think section 5 needs to say that the output of
> CMAC is 128 bits regardless of key size.

Agreed--though I'm not sure how the key size enters into the picture.
The output length of CMAC is bounded by the cipher block size, and has
no relation to the key length.  I suggest adding "The output length
(Tlen) is 128 bits for both key sizes."

> - 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

That's the correct reference.  I'd suggest changing the introductory
paragraph to begin with "The following parameters, required by RFC 3961
section 3, apply to...".  Similarly for section 7: "The following
parameters, required by RFC 3961 section 4, apply to...".

As for the order, this can be corrected by moving "Default string-to-key
parameters" after "Key-derivation function".

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

I don't think so.  Neither RFC 3962 nor the RFC 3961 simplified profile
mention UTF-8.

> - 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/)

I'm echoing a statement from RFC 3962 section 3.  This statement means
that all bit values in the 128-bit key space are valid keys.  This is
true of all modern block ciphers, but is not true of DES or triple-DES
(which have historically been used by Kerberos).

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

Swapping the order of sections 3 and 4 makes sense to me.

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

I have no personal preference for | versus ||, but I think it's
important to remain consistent with RFC 3961.

I suggest adding, to the end of the first paragraph of section 3 (just
before the equations):

    In the following summary, | indicates concatenation.

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

These are specified in the same level of detail as the specifications in
RFC 3961 section 5.3, which have proved to be sufficiently
well-specified for interoperability.

> - 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.)

I think it makes sense to add, just after "Key-derivation functions" and
before "Default string-to-key parameters":

    String-to-key parameter format: four octets indicating a 32-bit
    iteration count in big-endian order.  Implementations may limit
    the count as specified in RFC 3962 section 4.

I have prepared a revision of the draft with all of the edits I
mentioned, but will not submit it at this time, since we've passed WGLC
and I'm not certain of the editing restrictions at this point.

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