Subject: [Ietf-krb-wg] review of draft-ietf-krb-wg-camellia-cts-00.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 08 Mar 2012 16:58:25 -0500

Below is my review of the Camellia document.  These are all editorial
and process issues, and I would like to see all of them resolved before
we move on.  Points 1, 2, 5, 6, and 7 are blockers; they must be
resolved before the document can progress.

I would like to hear from any implementors who plan to implement
this enctype or who have already done so, as well as from anyone
who has verified the test vectors in section 11.

-- Jeff

1. The document header does not include an intended status.  Since we
   have not yet seen consensus to request publication on the standards
   track, please add "Intended Status: Informational" to the document
   header.

   The abstract should include an explicit mention of RFC3961 (but
   without a citation, since the abstract must stand alone).  For
   example:

   OLD
     This document specifies two encryption types and two corresponding
     checksum types for the Kerberos cryptosystem suite.  The new types
     use the Camellia block cipher in CBC-mode with ciphertext stealing
     and the CMAC algorithm for integrity protection.

   NEW
     This document specifies two encryption types and two corresponding
     checksum types for the Kerberos cryptosystem frameworkd defined
     in RFC3961.  The new types use the Camellia block cipher in CBC
     mode with ciphertext stealing and the CMAC algorithm for integrity
     protection.

2. The IETF Trust copyright and license notice in this document is out
   of date, and must be updated to reflect the current version of the
   Trust Legal Provisions, which went into effect Dec 28, 2009.  See
   http://trustee.ietf.org/license-info/ and particularly section 6.b
   of the current (4.0) TLP.

3. The last paragraph of the introduction incorporates requirements
   keywords from RFC2119 by reference, but then does not use them.
   This paragraph should be removed.

4. In section 6, the description of the decryption operation does not
   spell out how separate the MAC and ciphertext parts of the incoming
   "ciphertext".  It also does not specify how to remove the confounder
   from P to obtain the actual plaintext.  These operations should be
   obvious, but it's better to be specific.

5. The IANA considerations section should fully identify the namespace
   into which each value is registered, preferably not only by name
   but also including a URL to the registry and a mention of RFC3961
   where the registries are defined.  Also, this section should list
   each value to be assigned and give each a unique reference (TBD1,
   TBD2, etc); those references should be used instead of plain "TBD"
   in the rest of the document, in order to aid the RFC-Editor in
   making the correct substitutions.  For more details, please see
   RFC5226 section 5.1.

6. References must be split into separate sections for normative and
   informative references.  So far as I can tell, the references to
   RFCs 3713, 3961, and 3962 and to NIST special pubs 800-38B and
   800-108 are all normative, while the references to Schneier's book
   and to the IPA and Mala, et.al. papers and the NESSIE project are
   all informative.  This document contains no RFC2119 requirements
   language, so the reference to RFC2119 is not needed.

7. There is no section acknowledging authors and other contributors to
   this document.

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2012 23:09:42 +0100 (MET)

Jeffrey Hutzelman wrote:
> 
>  [... review of the Camellia document ...]
> 

There seems to be a section marker missing before the author's address.
Currently the Author's Address is part of Appendix A -- which carries an
instruction for the RFC Editor to remove it.  :-D

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 08 Mar 2012 17:18:02 -0500

> instruction for the RFC Editor to remove it.  :-D

No; the "Author's Address" section simply isn't numbered.  That's
normal, and it's what xml2rfc generates.

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2012 23:23:47 +0100 (MET)

> normal, and it's what xml2rfc generates.

I am apparently confused by the html view created by rfcmarkup
that does not recognize standardized sections other than those
starting with a number or "Appendix" and a letter.

  http://tools.ietf.org/html/draft-ietf-krb-wg-camellia-cts-00#appendix-A

Besides the Author's Address, rfcmarkup does not seem to recognize
  - Abstract
  - Status of this Memo
  - Copyright Notice
  - Table of Contents
  - Full Copyright Statement
  - Intellectual Property

:-(

-Martin

---

From: Greg Hudson <[email-masked]>
Date: Fri, 09 Mar 2012 00:14:06 -0500

On 03/08/2012 04:58 PM, Jeffrey Hutzelman wrote:
> Points 1, 2, 5, 6, and 7 are blockers; they must be resolved before
> the document can progress.

I believe all points are taken care of in -01, but some may need
confirmation.

> who has verified the test vectors in section 11.

We have an implementation, awaiting enctype and cksumtype assignments
before becoming part of the default build.  It was, of course, used to
generate the test vectors, so can't be used to verify them.  The
Camellia implementation is off-the-shelf (with off-the-shelf tests) and
the CMAC implementation was verified against RFC 4493 test vectors using
AES as the cipher.

>    of date

I believe I resolved this by updating and re-running xml2rfc, but I
could only detect a one-word difference, so I'm not 100% certain.

>    obvious, but it's better to be specific.

I added the text, "To separate the ciphertext into C and M components,
use the final final 16 bytes for M and all of the preceding bytes for C."

> 5. The IANA considerations [...]

I moved the Assigned Numbers table into the IANA considerations section
and reworked it to match the registry, as described in RFC 5226.  I also
removed the notes to the RFC editor, since I think it can all be taken
care of in the IANA step.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Mar 2012 14:56:38 -0500

> I believe all points are taken care of in -01, but some may need

Yup; it looks like -01 addresses all of my comments.

Is anyone else working on implementing this?
I'd really prefer to have verification of the test vectors if possible,
but I won't hold up publication for that if no one is close to being
able to do so.

-- Jeff