IETF Logo Mail Archive

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

Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> Mon, 16 March 1998 22:56 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10265 for ipsec-outgoing; Mon, 16 Mar 1998 17:56:42 -0500 (EST)
Message-Id: <199803162310.XAA28809@orchard.arlington.ma.us>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
cc: 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>
Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt
In-reply-to: Your message of "Mon, 16 Mar 1998 14:42:26 -0500 ." <199803161942.OAA24677@dcl.MIT.EDU>
Date: Mon, 16 Mar 1998 18:10:22 -0500
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> 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.

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.

					- Bill

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