Subject: [Ietf-krb-wg] Camellia-CCM

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 09 Nov 2010 14:11:47 -0500

I've reviewed the discussions we've had so far on the Camellia-CCM
draft, going back to February of this year.  There were only two
replies to my formal consensus call, but I've also taken into account
comments made before and since.

First of all, as previously noted, the question of whether to assign
enctype and checksum type numbers is not up to us, except that we
can force the issue by publishing a standards-track document.  In any
case, I saw no objections to making those assignments, regardless of
how we end up handling the document.  At this point, this is in the
hands of IANA and of the designated expert.  I would note that number
assignments normally do not occur until there is a document ready to
be published(*).

Thomas Hardjono and Greg Hudson have both indicated support for adoption
of this work and for eventual publication on the standards track.  While
they hasn't said so explicitly, I'm assuming the same of Tom Yu, and Luke
Howard, based on their other comments; I'm also making that assumption
of the remaining co-author, Satoru Kanno.

Simon Josefsson and Love Hörnquist-Åstrand have both objected to making
this enctype mandatory-to-implement, and also to publication on the
standards track, though Love's objection to the latter was not expressed
very strongly.  Neither objects to assignment of numbers and publication
of the document; Love explicitly stated he would also not object to the
adoption of the document by the working group.

Both Henry Hotz and Sam Hartman have said they believe it would be a
good idea to adopt at least one standards-track alternative to AES, as
a backup in case a problem is found with that cipher.  However, neither
has expressed a particular opinion on whether Camellia is an appropriate
choice.  Both Sam and Henry have said they have no particular objections
to this work based on IPR concerns.

In addition to the specific comments mentioned above, I've seen a fair
amount of technical discussion on this document, which I take to mean
that a number of people are sufficiently interested in the work to
spend time reading and commenting on it.  I take that as an indication
of some support to do work in this area.

Sam has not, so far as I've been able to find, expressed an opinion on
whether this document should be published on the standards track.
However, he has made the argument that we should not adopt this work
unless we intend it for the standards track.  I have not been able to
find anyone else making that argument, so I'm finding that, at least
for the moment, Sam is in the rough on this point.

At present, we cannot formally adopt this document, because work on new
enctypes is not within the scope of our charter.  However, based on the
above, it is clear to me that there is a desire within the working group
to continue with this work.  Further, I can think of no more appropriate
forum for discussion of new Kerberos enctypes than this mailing list,
regardless of whether they are formally the work of this working group.
Therefore, even though we have not yet adopted the document, I will
continue to allow and encourage discussion of this work here.  I have
also placed this work on Friday's agenda.

I do not believe that rough consensus exists at this time to place this
work on the standards track.

I am currently in the process of preparing a proposed charter update,
which unfortunately will probably not be ready in time for discussion
at Friday's meeting.  I would like that charter to include work on new
and updated enctype specifications, as I expect to see us wanting to
do additional work in that space.  Once the new charter is published,
we will adopt this work under that charter, if it is still ongoing
and the new charter permits.

-- Jeff

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 09 Nov 2010 14:38:26 -0500

Just to add a little bit of confusion, I am going to start pushing for a
camellia-cts-cmac enctype rather than a camellia-ccm enctype.  I don't
think this materially impacts the consensus on whether to adopt the
work.  I hope to have a new draft ready soon.

CCM and GCM were initially attractive to me because they are
NIST-approved AEAD modes depending only on the security of a block
cipher.  However, their use within Kerberos is more problematic than I
had originally anticipated.  The need to fit a nonce and a block count
inside of a 128-bit counter block creates a tension between collision
security margin and message length which can only be resolved by
modifying the cipher modes, and upon reflection I think that destroys
most of the benefit of using a NIST-approved AEAD mode.

Although CBC with ciphertext stealing has been criticized as inelegant,
it is probably no more so than CCM or GCM.  Ciphertext stealing is
NIST-approved (SP800-38A addendum) and we have enough experience with it
to know that it fits into a Kerberos-sized hole with reasonable security
margins.  By using CMAC instead of HMAC for integrity protection, we can
eliminate the dependency on a hash.