[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ciph-cbc-02.txt
- To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
- Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt
- From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
- Date: Mon, 16 Mar 1998 20:14:11 -0500
- Address: 1 Amherst St., Cambridge, MA 02139
- 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>
- Phone: (617) 253-8091
- Sender: owner-ipsec@ex.tis.com
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
References: