Document Action: 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' to Informational RFC (draft-herzog-static-ecdh-06.txt)
The IESG <iesg-secretary@ietf.org> Mon, 21 March 2011 17:47 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727A628C0F7; Mon, 21 Mar 2011 10:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.204
X-Spam-Level:
X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, SARE_OBFU_ALL=0.751, 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 qeCYIeKcwiQt; Mon, 21 Mar 2011 10:47:21 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D677128C0F2; Mon, 21 Mar 2011 10:47:20 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' to Informational RFC (draft-herzog-static-ecdh-06.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.12
Message-ID: <20110321174720.22608.99486.idtracker@localhost>
Date: Mon, 21 Mar 2011 10:47:20 -0700
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2011 17:47:22 -0000
The IESG has approved the following document: - 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' (draft-herzog-static-ecdh-06.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ Technical Summary This document describes how to use 'static-static' Elliptic Curve Diffie-Hellman (S-S ECDH) key-agreement with the Cryptographic Message Syntax (CMS). In this form of key-agreement, the Diffie-Hellman values of both sender and receiver are long-term values contained in certificates. This form of key agreement can be used with three CMS content types: EnvelopedData, AuthenicatedData, and AuthEnvelopedData. Working Group Summary This is not the product of a WG, but it was discussed on the SMIME WG mailing list. This draft documents an option not in RFC 5753 (Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)). RFC 5753 specifies the use of ephemeral-static (E-S) ECDH, but does not specify the use of S-S ECDH. The SMIME WG did not specify S-S ECDH because E-S ECDH is more secure (to save you some time: E-S ECDH provides better security due to the originator's ephemeral contribution to the key agreement scheme). This is not to say S-S ECDH is insecure it's just that E-S ECDH is considered more secure and there was only a limited amount of energy to work on ECDH based solutions. Note that draft-herzog-static-ecdh contains a section that compares itself to RFC 5753. The discussion on the WG list was light. Jim Shaad provided reviews that resulted -01. -02, -03 and -04 were to address ID-nits. Document Quality There is an implementation of an earlier version of this document. This implementation can be updated with little effort to match this version of the final document. Personnel Jonathan Herzog <jherzog@ll.mit.edu> is the document Shepherd. Tim Polk is the responsible Area Director. RFC Editor Note Please append the following paragraph to Section 7, Security Considerations: When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption would not be possible by the sender's infrastructure (though it would remain possible for the infrastructure of any recipient.)