IETF Logo Mail Archive

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

Paul Wouters <paul@cypherpunks.ca> Mon, 10 March 2014 16:45 UTC

Return-Path: <paul@cypherpunks.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C881A0515 for <ipsec@ietfa.amsl.com>; Mon, 10 Mar 2014 09:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRfThDrlhgBP for <ipsec@ietfa.amsl.com>; Mon, 10 Mar 2014 09:45:34 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D3ACA1A04E7 for <ipsec@ietf.org>; Mon, 10 Mar 2014 09:45:34 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EB0B5800AF; Mon, 10 Mar 2014 12:45:28 -0400 (EDT)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2AGjS0Q001672; Mon, 10 Mar 2014 12:45:28 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 10 Mar 2014 12:45:28 -0400
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Paul_Koning@Dell.com
In-Reply-To: <C75A84166056C94F84D238A44AF9F6AD16C67F8F@AUSX10MPS303.AMER.DELL.COM>
Message-ID: <alpine.LFD.2.10.1403101242590.26293@bofh.nohats.ca>
References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <C75A84166056C94F84D238A44AF9F6AD06F1684B@AUSX10MPC102.AMER.DELL.COM> <531DE2C2.7050109@bbn.com> <C75A84166056C94F84D238A44AF9F6AD16C67F8F@AUSX10MPS303.AMER.DELL.COM>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/2cJzFb9qhPZuomwJIZktfeqplMI
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 16:45:39 -0000

On Mon, 10 Mar 2014, Paul_Koning@Dell.com wrote:

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

It's not the implementation cost that matters. It is the GUI confusion.
For example one vendor uses "aes" as aes128, and another vendor uses
"aes" for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we
expose needlessly to the enduser is one more potential interop issue.

Paul

v2.23.0 | Report a Bug | By Email