Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

Dan Brown <danibrown@blackberry.com> Tue, 01 October 2019 13:52 UTC

Return-Path: <danibrown@blackberry.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E765C1201DB for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 06:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 i47LhDFFuLOP for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 06:52:22 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7634B120024 for <TLS@ietf.org>; Tue, 1 Oct 2019 06:52:21 -0700 (PDT)
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2019 09:52:21 -0400
Received: from XCT113CNC.rim.net (10.65.161.213) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 1 Oct 2019 09:52:20 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0415.000; Tue, 1 Oct 2019 09:52:19 -0400
From: Dan Brown <danibrown@blackberry.com>
To: John Mattsson <john.mattsson@ericsson.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Hubert Kario <hkario@redhat.com>, "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
Thread-Index: AdV4RZj0/krq7yA89EekKREnIpqJfwAL2k0AAAY+MAA=
Date: Tue, 01 Oct 2019 13:52:19 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501E4532F@XMB116CNC.rim.net>
References: <20191001104718.8626261.12105.36904@blackberry.com> <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com>
In-Reply-To: <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.27.110]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_00BC_01D5783D.E9AC77B0"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/N6os8mytJz1PYnKsikArBI3Ap8M>
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 01 Oct 2019 13:52:25 -0000

> -----Original Message-----
> From: John Mattsson <john.mattsson@ericsson.com>
>
> Dan Brown <danibrown@blackberry.com> wrote:
>
> > ANSI X9.62-2005 was withdrawn in 2015
>
> Ok, that TLS 1.3 is relying on a withdrawn publication that used to be 
> behind a
> paywall is even worse.

[DB] Have mercy on TLS: I expect they had plenty of working code, and archived 
ECDSA specs for documentation, so it's not at all their fault that another 
organization's specs expired while they were undertaking a major improvement.

>
> > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA
>
> That NIST FIPS 186-5 will include all the details needed to implement ECDSA 
> is
> great.

[DB] I think I also said that I was not sure if it will have any ASN.1 (i.e. 
resolution of ECDSA-Sig-Value).

>
> >IETF has specs for sigs and their formats already, no?
>
> At the time when RFC 8446 was published, there was probably no quick and
> easy solution to the problem. But the fact that IETF has historically been 
> fine
> with relying on specifications behind paywalls is part of the problem. If 
> IETF had
> implemented a strong open-access policy a long-time ago, there would
> probably be an open-access version of ECDSA (NIST or IETF) a long time ago.
>
[DB] SECG was created, among several other reasons, to provide a kind of 
open-read-access ECC specifications.  I think some IETF docs even refer to 
SECG, maybe SEC2?

Doesn't IETF have RFC 5480, 6090, 6979, which cover a fair amount of ground in 
specifying (some variation of) ECDSA?  Although, that's not a policy, and 
maybe was not even an easy enough solution for RFC 8446, etc.