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