[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



with SMTP id SAA12372; Thu, 15 Jul 1999 18:02:13 -0500 (CDT)
Posted-Date: Thu, 15 Jul 1999 18:02:13 -0500 (CDT)
Message-Id: <4.1.19990715175408.00ab7190@mail.visi.com>
X-Sender: schneier@mail.visi.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 15 Jul 1999 17:56:33 -0500
To: "Derrell D. Piper" <ddp@Network-Alchemy.COM>, jerome@psti.com
From: Bruce Schneier <schneier@counterpane.com>
Subject: Re: your mail 
Cc: ipsec@lists.tislabs.com
In-Reply-To: <199907151703.KAA19898@gallium.network-alchemy.com>
References: <Your message of "Thu, 15 Jul 1999 12:05:54 EDT."             
<19990715120554.A3699@jerome.psti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

At 10:03 AM 7/15/99 -0700, Derrell D. Piper wrote:
>All,
>
>> > I think giving users a choice is a bad idea, and
>> > that one strong cipher is better than two strong ciphers.
>> 
>> if ipsec is deployed with 2 ciphers A and B, and a major weakness is found
>> out in A, you still have the choice to use B.
>> if A was the only cypher, you have to upgrade all the software/hardware.
>
>I agree that by requiring two MUST's, we ensure that there is a viable
>alternative in deployed implementations if one of the MUST ciphers should be
>compromised in the future.  If there's only one, you're completed hosed.

No.  If there are two "MUST" ciphers, and one gets broken, then you must
implement
both a broken cipher and a strong cipher.  And you had better make sure the
selection mechanism is secure, of you are going to be hosed as well.

This isn't a normal engineering paradigm of not putting all your eggs is
one basket.
In security engineering, the weakest egg defines the strength of the
system.  There 
are far more important things to worry about wrt IPSec that this matter is
almost
irrilevent.

Use triple-DES.  Wait a year or so for AES.  Then add AES.  In the
menetime, solve
all the other IPSec security problems.

>RE: 3DES to historic when AES is announced

No.  That makes no sense, either.

>I would oppose this move at this time.  Even when AES is announced, there's no
>way it's going to have had the same scrutiny that DES, hence 3DES, has had in
>fielded implementations.  There will come a time when we want to deprecate
>3DES, but that's not the day AES comes out.

Agreed.

>RE: AES, in general
>
>It seems a no-brainer to me that the AES choice be added to IPSEC as a MUST
>implement cipher once it's decided.

Agreed.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com