IETF Logo Mail Archive

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

"Theodore Y. Ts'o" <tytso@MIT.EDU> Tue, 17 March 1998 01:01 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11023 for ipsec-outgoing; Mon, 16 Mar 1998 20:01:44 -0500 (EST)
Date: Mon, 16 Mar 1998 20:14:11 -0500
Message-Id: <199803170114.UAA24831@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>, Roy Pereira <rpereira@TimeStep.com>, IPSEC Mailing List <ipsec@tis.com>, Bart Preneel <preneel@esat.kuleuven.ac.be>, Vincent Rijmen <rijmen@esat.kuleuven.ac.be>
In-Reply-To: Bill Sommerfeld's message of Mon, 16 Mar 1998 18:10:22 -0500, <199803162310.XAA28809@orchard.arlington.ma.us>
Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

   Date: Mon, 16 Mar 1998 18:10:22 -0500
   From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>

   I'm a little leery about this, because it means that different
   implementations would have different ideas about what constitutes a
   weak key, which could lead to rarely-occurring, difficult-to-diagnose
   interoperability glitches when the shared key ends up being "weak" and
   one endpoint detects this and the other doesn't.

I wouldn't think this should cause an interoperability glitch, since
either side should already be able to force that an SA be negotiated,
for a variety of reasons, including one where one of the security
gateway reboots and loses state.  (This is general case problem may be
one of the places where we need some implementation and operatonal
experience before we're sure we've gotten all of the details right.)

						- Ted

v2.30.2 | Report a Bug | By Email | System Status