Re: [TLS] Require deterministic ECDSA
Hubert Kario <hkario@redhat.com> Mon, 25 January 2016 11:42 UTC
Return-Path: <hkario@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 BD0A91A8ABC for <tls@ietfa.amsl.com>; Mon, 25 Jan 2016 03:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] 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 ypfAk8Y3hVta for <tls@ietfa.amsl.com>; Mon, 25 Jan 2016 03:42:51 -0800 (PST)
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 5C60E1A8ABB for <tls@ietf.org>; Mon, 25 Jan 2016 03:42:51 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 871ED461D3; Mon, 25 Jan 2016 11:35:54 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-119.brq.redhat.com [10.34.0.119]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0PBZquu008790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2016 06:35:54 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 25 Jan 2016 12:35:47 +0100
Message-ID: <1540862.6uNngKyjAe@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <201601240204.29009.davemgarrett@gmail.com>
References: <CACaGAp=-xJZN=L3av+DX_WQcki_k=L-_tc5dZnJNtM=M0W8MnQ@mail.gmail.com> <56A41F0F.70609@nthpermutation.com> <201601240204.29009.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2289885.CzIHCMqGrI"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yvSmgpMbtgCvr43cdudW49ZufLw>
Subject: Re: [TLS] Require deterministic ECDSA
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: Mon, 25 Jan 2016 11:42:52 -0000
On Sunday 24 January 2016 02:04:28 Dave Garrett wrote: > On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote: > > 1) A receiver of an deterministic ECDSA signature verifies it > > EXACTLY > > like they would a non-deterministic signature. > > 2) A receiver of an ECDSA signature cannot determine whether or not > > the signer did a deterministic signature. > > 3) A TLS implementation has no way (absent repeating signatures over > > identical data) of telling whether or not a given signature using > > the > > client or server private key is deterministic. > > > > All that suggests that this is a completely unenforceable > > requirement > > with respect to TLS. > > We can have unverifiable & unenforceable MUSTs. A SHOULD might be more > appropriate, however, if we want to acknowledge this limitation to > some degree. a MUST is only necessary if you are not sure or simply know that your RNG is broken, if you're doing a HSM implementation you know that your RNG is good so you can just use it and while we can have unverifiable MUSTs, it just looks silly if you do, especially if the other way of doing things is just as interoperable, and just as secure (if implemented properly) as the mandated one... SHOULD with explanation why it's there is definitely better approach -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- [TLS] Require deterministic ECDSA Joseph Birr-Pixton
- Re: [TLS] Require deterministic ECDSA Joseph Birr-Pixton
- Re: [TLS] Require deterministic ECDSA Geoffrey Keating
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Brian Smith
- Re: [TLS] Require deterministic ECDSA Dave Garrett
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Watson Ladd
- Re: [TLS] Require deterministic ECDSA Filippo Valsorda
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- [TLS] Fwd: Re: Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Hubert Kario
- Re: [TLS] Require deterministic ECDSA Jacob Maskiewicz
- Re: [TLS] Require deterministic ECDSA Salz, Rich
- Re: [TLS] Require deterministic ECDSA Adam Langley
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Salz, Rich
- Re: [TLS] Require deterministic ECDSA Daniel Kahn Gillmor
- Re: [TLS] Require deterministic ECDSA Joseph Birr-Pixton
- Re: [TLS] Require deterministic ECDSA Watson Ladd
- Re: [TLS] Require deterministic ECDSA Salz, Rich
- Re: [TLS] Require deterministic ECDSA Jacob Maskiewicz
- Re: [TLS] Require deterministic ECDSA Bill Cox
- Re: [TLS] Require deterministic ECDSA Michael StJohns