Re: Slicing and dicing

Stephen Kent <kent@bbn.com> Fri, 12 September 1997 20:23 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09987 for ipsec-outgoing; Fri, 12 Sep 1997 16:23:11 -0400 (EDT)
X-Sender: kent@po1.bbn.com
Message-Id: <v03102816b03f554fed0a@[128.89.0.110]>
In-Reply-To: <199709121921.MAA12951@trix.cisco.com>
References: <199709121828.LAA13256@kebe.eng.sun.com> from "Dan McDonald" at Sep 12, 97 11:28:35 am
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 12 Sep 1997 16:31:27 -0400
To: Cheryl Madson <cmadson@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Slicing and dicing
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Cheryl,

	I have mixed feelings about this issue.  Some weeks ago I observed
in an e-mail exchange with Ted that  the issue of weak, semi-weak, etc.
keys in DES seemed overblown to me, in the context of CBC mode.  Ted did an
excellent job of providing a quantitative analysis that makes the point
better than my qualitative discussion with him.  However, the analysis is
algorithm and mode dependent.  That suggests that ISAKMP ought to include a
generic facility for a symmetric algorithm to reject candidate keying
material, for instances where this may be a problem.  That said, I agree
with your observation that moving on to another chunk of the key bits is
probably not a good idea, and just giving up and trying a new exchange
seems preferable, especially since any useful algorithm will probably have
a very, very small likelihood of rejecting keys for whatever reason.

	That defers the question of what to do for DES in CBC mode to the
algorithm document itself.  Based on the current discussion, it looks like
people are willing to just punt on this case, but I would likle to see a
requirement in ISAKMP to support the generic rejection facility.  Is it
reasonable to provide an error indication to the other end indicating the
reason for the rejection, just in case implementations don't agree on the
rejection (or at least for audit trail purposes)?

Steve