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