Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts

Stephen Kent <> Mon, 10 March 2014 17:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09C1D1A06CD for <>; Mon, 10 Mar 2014 10:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hLpOU-4JjSKW for <>; Mon, 10 Mar 2014 10:29:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A56561A06CB for <>; Mon, 10 Mar 2014 10:29:55 -0700 (PDT)
Received: from ([]:43668 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1WN41U-000LGX-10; Mon, 10 Mar 2014 13:29:56 -0400
Message-ID: <>
Date: Mon, 10 Mar 2014 13:29:48 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <C75A84166056C94F84D238A44AF9F6AD06F1684B@AUSX10MPC102.AMER.DELL.COM> <> <C75A84166056C94F84D238A44AF9F6AD16C67F8F@AUSX10MPS303.AMER.DELL.COM>
In-Reply-To: <C75A84166056C94F84D238A44AF9F6AD16C67F8F@AUSX10MPS303.AMER.DELL.COM>
Content-Type: text/plain; charset=Windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Mar 2014 17:29:57 -0000

> ...
>> It's good to remember the reason that 256-bits keys for AES were specified,
>> i.e., as a hedge against someone building a quantum computer. So, unless the
>> data being encrypted is expected to have a lifetime far enough into the future
>> as to merit protection against that concern, the extra time needed to perform
>> AES-256 vs. AES-128 does not seem justified.
>> Steve
> That’s a good argument for a user choosing to use AES-128 rather than AES-256.  But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact.
> 	paul
I have been told by some commercial security consultants that their 
customers believe that
bigger is more secure, and thus they should mandate use of longer key 
lengths if they
are available. If that report is accurate, then making AES-256 a SHOULD 
(vs. a MAY)
creates a situation where the performance penalty will be incurred, for 
no good reason.

But, I'm not going to fall on my sword for this.