IETF Logo Mail Archive

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 24 September 2015 14:03 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42571AD151 for <tls@ietfa.amsl.com>; Thu, 24 Sep 2015 07:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level:
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IY0FKBoyqtoW for <tls@ietfa.amsl.com>; Thu, 24 Sep 2015 07:03:32 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4351A6F98 for <tls@ietf.org>; Thu, 24 Sep 2015 07:03:32 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id D7C0B91EAB; Thu, 24 Sep 2015 14:03:31 +0000 (UTC)
Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8OE3SA3031264 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 10:03:30 -0400
Message-ID: <1443103408.20825.20.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Simon Josefsson <simon@josefsson.org>
Date: Thu, 24 Sep 2015 16:03:28 +0200
In-Reply-To: <20150924122747.GA10461@LK-Perkele-VII>
References: <878u7xtu06.fsf@latte.josefsson.org> <20150924122747.GA10461@LK-Perkele-VII>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/jCht-j_-v-FcQYW_q5vS3uoPnvY>
Cc: tls@ietf.org
Subject: Re: [TLS] Updated EdDSA/Ed25519 PKIX document
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2015 14:03:33 -0000

On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote:

> 4) For TLS PoP signatures, does it make sense to use HashEdDSA at
> all?
> Another way would to always use PureEdDSA and perform hash separtion
> from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))).
> The certificate signatures are different matter tho, since CAs use
> HSMs for signing (those HSMs tend to be rather beefy, but still).

The problem with the PureEdDSA is that if you use a smart card or an
HSM (both common for TLS), you have to transfer lots of data to them,
something that may render it not really useful. Also the PureEdDSA in
most implementations it requires a new API for signing.

regards,
Nikos

v2.23.0 | Report a Bug | By Email