Re: [IPsec] Updating IPsec algorithm requirements
Paul Koning <Paul_Koning@dell.com> Fri, 06 November 2009 19:08 UTC
Return-Path: <Paul_Koning@Dell.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C1E3A69DD for <ipsec@core3.amsl.com>; Fri, 6 Nov 2009 11:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6B9DmJXiRpM for <ipsec@core3.amsl.com>; Fri, 6 Nov 2009 11:08:00 -0800 (PST)
Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 5CB873A683A for <ipsec@ietf.org>; Fri, 6 Nov 2009 11:08:00 -0800 (PST)
X-Loopcount0: from 12.110.134.31
X-IronPort-AV: E=Sophos;i="4.44,695,1249275600"; d="scan'208";a="420123507"
Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 06 Nov 2009 13:08:23 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19188.29670.319220.85945@pkoning-laptop.lab.equallogic.com>
Date: Fri, 06 Nov 2009 14:07:18 -0500
From: Paul Koning <Paul_Koning@dell.com>
To: mcgrew@cisco.com
References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com>
X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid
X-OriginalArrivalTime: 06 Nov 2009 19:07:22.0869 (UTC) FILETIME=[5ED82A50:01CA5F14]
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Updating IPsec algorithm requirements
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 06 Nov 2009 19:08:01 -0000
Excerpt of message (sent 6 November 2009) by David McGrew: > Hi Paul, Yaron, and IPsec ME WG participants, > > I would like to propose an update to the algorithm requirements, as > outlined below. > ... > Currently, AES in Counter Mode (AES-CTR)[RFC3686] is recommended as a > SHOULD in "Cryptographic Algorithm Implementation Requirements for > Encapsulating Security Payload (ESP) and Authentication Header (AH)", > RFC 4835. AES-CTR is a useful algorithm because it admits efficient > high speed implementations. However, it provides no authentication. ... and therefore no confidentiality either, if used by itself, via the Bellovin attack. > From RFC3686: "With AES-CTR, it is trivial to use a valid ciphertext > to forge other (valid to the decryptor) ciphertexts. Thus, it is > equally catastrophic to use AES-CTR without a companion authentication > function. Implementations MUST use AES-CTR in conjunction with an > authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]." > Unfortunately, none of the authentication algorithms currently defined > for IPsec (HMAC, XCBC-MAC) admit efficient high speed > implementations. Thus the need for authentication undermines the > efficiency of AES-CTR. > > AES-GCM was designed specifically to overcome this problem. ... > > It is especially important that AES-GCM be recommended over the use of > AES-CTR with HMAC-SHA-256, ... I agree. For the reasons you gave, and also to remove the temptation to run AES-CTR without authentication for performance reasons, even though the standard says not to do this. paul
- [IPsec] Updating IPsec algorithm requirements David McGrew
- Re: [IPsec] Updating IPsec algorithm requirements Paul Koning
- Re: [IPsec] Updating IPsec algorithm requirements Paul Hoffman
- Re: [IPsec] Updating IPsec algorithm requirements Yaron Sheffer
- Re: [IPsec] Updating IPsec algorithm requirements David McGrew