Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt
Johannes Merkle <johannes.merkle@secunet.com> Wed, 05 December 2012 18:15 UTC
Return-Path: <Johannes.Merkle@secunet.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D802A21F8C84 for <ipsec@ietfa.amsl.com>; Wed, 5 Dec 2012 10:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWowsb-Jb5fE for <ipsec@ietfa.amsl.com>; Wed, 5 Dec 2012 10:15:40 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id ED6AF21F8BB9 for <ipsec@ietf.org>; Wed, 5 Dec 2012 10:15:39 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C101E1A007B; Wed, 5 Dec 2012 19:14:55 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 9A2A71A007A; Wed, 5 Dec 2012 19:14:51 +0100 (CET)
Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Dec 2012 19:15:34 +0100
Message-ID: <50BF8F44.6040003@secunet.com>
Date: Wed, 05 Dec 2012 19:15:32 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> <20670.1967.744783.372876@fireball.kivinen.iki.fi>
In-Reply-To: <20670.1967.744783.372876@fireball.kivinen.iki.fi>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Dec 2012 18:15:34.0182 (UTC) FILETIME=[84A4EC60:01CDD314]
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 05 Dec 2012 18:15:41 -0000
Hi Tero, some additional feedback: Introduction: In the paragraph 4 you point out the two achievements of the draft: - A generalized authentication method for authentication with digital signatures - A negotiation method for the hash function used as message digest within the signature The motivation should be structured to reflect this distinction. In particular, the first and third paragraphs motivate the authentication method, while the second one motivates the second one. As ECDSA groups, RSASSA-PSS and DSA with other hash than SHA-1 all point to deficiencies of the old authentication method, I would use a list. How about the following? The current signature based authentication methods in the IKEv2 are per algorithm, i.e. there is one for RSA Digital signatures, one for DSS Digital Signatures (using SHA-1) and three for different ECDSA curves each tied to exactly one hash algorithm. This design starts to be cumbersome when more signature algorithms, hash algorithms and elliptic curves are to be supported: * The RSA Digital Signatures format in the IKEv2 is specified to use RSASSA-PKCS1-v1_5 padding, but [RFC 4055] and [PKCS1] recommend the use of the newer RSASSA_PSS. This new padding method is specified by additional parameters and for each parameter set to be supported new authentication methods would be required. * With ECDSA and DSS there is no way to extract the hash algorithm from the signature, thus, for each new hash function to be supported with ECDSA or DSA new authentication methods would be needed. Support for new hash functions is particularly needed for DSS because the current restriction to SHA-1 limits its security, meaning there is no point of using long keys with it. * The tying of ECDSA authentication methods to particular elliptic curve groups requires definition of additional methods for each new group. By combination of new ECDSA groups with various hash functions the number of required authentication methods may grow unmanageable. Furthermore, the restriction of ECDSA authentication to a specific group is inconsistent with the approach taken with DSS. With the selection of SHA-3 [Ref_TBD], it is seen that it might be possible that in the future the signature methods are used with SHA-3 also, not only SHA-2. This means new mechanism for negotiating the hash algorithm for the signature algorithms is needed. > The new digital signature method needs to be flexible enough to > include all current signature methods (ECDSA, ECGDSA, RSASSA-PSS, > ElGamal, etc), The term "current signature methods" is not precise. Currently used with IKE? Currently used in practice at all? Currently specified in standards (which ones)? Actually: - the new authentication method is agnostic to the signature algorithm (like X.509 or CMS are) as far as an ASN.1 algorithm identifier exists. (This holds true only, if parameters of the algorithm can be included) - The hash negotiation method supports only those hash algorithms for which code points have been defined. Furthermore, I suggest not to list specific signature methods supported, as some of them (ECDSA) are common while others are not. This may provoke discussion, in particular, as RSA with PKCS#1v1.5 as the most common one (by far) is not listed. Best regards, Johannes
- [IPsec] New Version Notification for draft-kivine… Tero Kivinen
- Re: [IPsec] New Version Notification for draft-ki… Johannes Merkle
- Re: [IPsec] New Version Notification for draft-ki… Johannes Merkle
- Re: [IPsec] New Version Notification for draft-ki… Tero Kivinen
- Re: [IPsec] New Version Notification for draft-ki… Johannes Merkle
- Re: [IPsec] New Version Notification for draft-ki… Tero Kivinen