Subject: [Ietf-krb-wg] Camellia Adoption

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Sep 2011 13:30:05 -0400

On June 29, Sam sent a message requesting comments on adopting Greg
Hudson's Camellia CTS draft as a working group item.  Specifically, we
were looking for a consensus in general on the move from counter modes
to CTS, and in particular on adopting Greg's draft as the basis for
that work.  We were also looking to develop a consensus on intended
status.

At the time of Sam's post, we were operating under the presumption that
we already had consensus to work on a Camellia enctype in some form, on
the basis of a consensus call I did last November.  However, Stephen
Farrell, in his role as AD, asked who actually wants Camellia support
in Kerberos.  Stephen's concern is avoiding an unnecessary
proliferation of ciphers, not just in Kerberos but in any protocol.  In
partial response to Stephen's question, Sam asked for comments from WG
participants who support working on a Camellia enctype document,
essentially revisiting the consensus call from last November.

So, we have been considering three questions:
1) Should the WG be working on a Camellia document at all?
2) Moving to CTS; particularly, adopting Greg's document
3) Intended status

On the question of whether we should be doing Camellia work at all, I
saw support for this work from at least Thomas Hardjono, Greg Hudson,
Satoru Kanno, Nicolas Williams, Henry Hotz, and Tom Yu.  I was unable
to find any specific objections to adopting this work, though Sam did
point out his continuing objection to adopting any enctype work unless
it is intended for standards track.  Finally, the minutes from IETF81
show 7 in favor of adopting, including Leif Johansson, and two opposed,
including Jim Schaad.

On the question of moving to CTS in general and using Greg's draft in
particular, I saw only a handful of responses.  Greg reviewed the
reasoning behind the change, and Nico pointed out that with counter
modes out of the picture, there really is no other viable alternative.
There was also a comment from Henry Hotz in favor of Greg's draft. I
found no indication of opposition to this move, nor any objections to
use of Greg's draft as the basis for any WG work that may happen.

Overall, both responses to Sam's post and discussion during IETF81 has
focused on Camellia in general and not on CTS or Greg's draft vs some
other alternative.  However, given the technical discussions which have
led us in this direction, I do not believe this point to be
controversial.

That leaves the question of intended status.  Thomas Hardjono expressed
support for advancing this document on the standards track.  Simon
Josefsson said he would prefer informational.  Nicolas Williams had no
strong opinion on the intended status, but said he would oppose making
implementation of a Camellia enctype mandatory in Kerberos.  Martin Rex
expressed an opinion that the IETF should be somewhat conservative in
placing documents on the standards track; however, he also explicitly
disclaimed any opposition to placing this document on the standards
track.

Overall, I find that the situation is very similar to what we had last
November.  We do seem to have a consensus to proceed with this work,
but we do not have a consensus to place it on the standards track, or
indeed any consensus on intended status.  There does seem to be a
consensus to use Greg's document as a basis for this work, though I am
basing this determination largely on the lack of either objections or
alternative proposals, rather than on a strong indication of support
for this specific approach.

Therefore, draft-hudson-krbwg-camellia-cts will be adopted as a
Kerberos working group document.

Stephen asked about interest in Camellia support in Kerberos, not only
in doing the work but also in using it.  I believe it is clear that
there is sufficient interest in doing the work.  Thomas and others have
referred to a desire on the part of companies, mostly in Japan, to
deploy Kerberos with enctypes other than AES, and specifically with
Camellia.  Finally, there has been some discussion of adopting a
"backup" enctype which can be deployed in the event that a problem is
found either with AES itself or with other aspects of our AES
enctypes.  While it is certainly not the only option, Camellia is
certainly a candidate for such a backup, should we decide to select
one.

Finally, a process note.  In the course of this discussion, someone
quoted the portion of our charter which talks about adopting enctype
work, and asked which of criteria listed for standard-track enctypes
was not met by Camellia.  I want to remind everyone that while the
charter does list specific criteria for standards-track enctypes (and
none for other enctype work), these are not the only requirements.  In
order to adopt any work item (not just enctypes), there must be
participants willing to take part in the work as editors, contributors,
and/or reviewers, and there must be a consensus in the working group to
adopt the item.  Similarly, an action such as recommending a document
be placed on the standards track will generally require a working group
consensus, unless the charter explicitly requires a particular status
for that work.

-- Jeff

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