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

Gandhar Gokhale <gandhar.ietf@gmail.com> Tue, 11 March 2014 06:06 UTC

Return-Path: <gandhar.ietf@gmail.com>
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 D80C31A0641 for <ipsec@ietfa.amsl.com>; Mon, 10 Mar 2014 23:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 qWpJ3-e2Ca8t for <ipsec@ietfa.amsl.com>; Mon, 10 Mar 2014 23:06:13 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7178E1A0649 for <ipsec@ietf.org>; Mon, 10 Mar 2014 23:06:13 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id lf12so2385043vcb.11 for <ipsec@ietf.org>; Mon, 10 Mar 2014 23:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pnhz9TeoA+KBXEgyLWGYh+w3G02wShWQPTpFOaCjIj0=; b=QtUy69opCJN7qQ5gOQ6dK4pX7z6pIuw2rx1QvL3ng7+oC/XNWhjXVjRF8lzMXVC/+2 LbdbnrAjP3Pa1s4t3HALAuhvMVgcKRr0hOOUX4mDuxUON57X6lWkpCxUZh41jXxTRWnK 4OaEpSglHMbmIKlzwvqoXzZgKS6XrSbfLvVAJS8OnWr6gJ3YSocgKYMxHg4kVth3Atc6 /YgBswDSBGh/T9/Waz20EhSaJqAI/E+ye/Rbz1/8OoNMsFJr5PlRuxu5kz7tC4rTsdfc 9koukOFQnZxsG43ap/iQ+UvkTXYh9RMnfjonQyb6KZ8aoDDUaPxBfRFfaO41ytUwHPh6 9V1g==
X-Received: by 10.52.35.196 with SMTP id k4mr214551vdj.38.1394517967684; Mon, 10 Mar 2014 23:06:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.119.134 with HTTP; Mon, 10 Mar 2014 23:05:45 -0700 (PDT)
In-Reply-To: <C75A84166056C94F84D238A44AF9F6AD16C6875F@AUSX10MPS303.AMER.DELL.COM>
References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <C75A84166056C94F84D238A44AF9F6AD06F1684B@AUSX10MPC102.AMER.DELL.COM> <531DE2C2.7050109@bbn.com> <C75A84166056C94F84D238A44AF9F6AD16C67F8F@AUSX10MPS303.AMER.DELL.COM> <alpine.LFD.2.10.1403101242590.26293@bofh.nohats.ca> <C75A84166056C94F84D238A44AF9F6AD16C6875F@AUSX10MPS303.AMER.DELL.COM>
From: Gandhar Gokhale <gandhar.ietf@gmail.com>
Date: Tue, 11 Mar 2014 11:35:45 +0530
Message-ID: <CADp=_KgQzN=UxtN_5f1S3kbDj1_oe8PLP_vEAJzCDStzswmVYg@mail.gmail.com>
To: Paul_Koning@dell.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3fUL2NLx-8z4bjkWcVYImBMRiPc
Cc: ipsec@ietf.org, paul@cypherpunks.ca
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: Tue, 11 Mar 2014 06:06:16 -0000

And testing cost for one more crypto algorithm when the algorithmic
permutations are already too high!
Gandhar Gokhale
Networking Components Group
LSI


On Mon, Mar 10, 2014 at 10:28 PM,  <Paul_Koning@dell.com> wrote:
>
> On Mar 10, 2014, at 12:45 PM, Paul Wouters <paul@cypherpunks.ca> wrote:
>
>> 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.
>
> True.  But if you assume sufficiently foolish GUI designs, just about anything can be hard to use.  And I don't think that good crypto design should be put at the mercy of people who can't design a decent UI.  We know that it's possible to get this right.
>
>         paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec