Re: draft-ietf-ipsec-ciph-cbc-02.txt

["Theodore Y. Ts'o" <[e-mail]>]

Bart,

	Thanks for sending in this erratum to the draft-ietf-ciph-cbc
draft.  It would have been nicer if you could have discovered this
problem last week, since the I-D submission deadline is closed, and we
were in working group last call in preparation for starting the IETF
last call and sending these documents off to the IESG.


To the working group:

	As some of you may know, we've been under a lot of pressure to
get these documents out the door, since our delay has been blocking the
progress of other groups (most notably the IP Compression documents) and
the release of these documens as proposed standards is long, long
overdue.  I realize that these documents are not perfect; but they do
not need to be perfect.  In particular, as implementors who have not
been involved in our multi-year journey towards standards start trying
to interpret the IPSEC documents, I am sure there will be a number of
places where the text will not be clear to someone who hasn't been
living and breathing IPSEC for the last two years.  That's OK --- that's
what the standards track is for.  We can make editorial changes to
correct such problems when these documents go up for consideration for
elevation to draft standard status.

	The problem that Bart has pointed out here is not an editorial
problem, though, but a problem where the document has screwed up on
matters of fact.  The correction of the author's name in the
bibliography can be corrected in the RFC editing process.  The
enumeration of the currently known weak keys, though, is a much more
serious issue.

	I can see three paths before us:

(a) delay the progress of all of the other IPSEC drafts until this
problem can be fixed (which means waiting until after the LA IETF).

(b) delay the progression of just the draft-ietf-ciph-cbc draft.
(Which we can do since all of its algorithms are OPTIONAL, and no other
documents have a dependency on this draft.)

(c) note this error, but consider it relatively unimportant, (since the
chances of hitting a weak key are infintessimal anyway) and correct it
when we progress up to draft standard status.

My personal preference would be option (b), but I am certainly willing
to entertain arguments for option (c).  I assume that everyone agrees
that option (a) is a bad idea.  :-)

Comments?

						- Ted

P.S.  I suggest that when we revise the text of this draft, that we word
it as saying that implementations SHOULD reject weak keys and request a
new SA, but to not claim to have an exhaustive listing of all possible
weak keys in the document.  That way, when researchers come up with new
and interesting weak keys in IDEA, implementations be updated without
implementors worrying about violating the spec.