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

[Stephen Farrell <[e-mail]>]

Hi Greg,

On 09/10/2012 05:24 PM, Greg Hudson wrote:
> 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?

Nope, your answer above does it for me.

If someone wants to bring this ambiguity to the attention
of the IPR holding folks and if they would like to update
their text then that'd be lovely but our process doesn't
call for them to have to do that.

Otherwise, it turns out the easiest thing is for me (or
whoever wants to if someone else is in the mood) to post
a 3rd party IPR declaration just saying that the current
declaration (#1304) looks like its relevant to this draft
and then start IETF LC and the right pointers will exist.
(Yes, that's an irritating and clunky process, but I
asked the IESG and its what two other ADs suggested,
better ideas welcome;-)

All your answers below also look fine, so I'll do the
above and start IETF LC tomorrow unless the WG chairs
tell me they'd rather some other plan e.g. they might
prefer you issue the update now or not, or they might
want to wait a bit to see if another IPR declaration
is going to be done, but let's leave that call to the
chairs.

Cheers,
S


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