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

From: Hubert Kario <[email-masked]>
Date: Mon, 30 Sep 2019 14:56:15 +0200

tl;dr: there are conflicting definitions of ECDSA-Sig-Value structure, which 
one "MUST" be used in TLS 1.3?

The ECDSA signature in TLS 1.3 (RFC 8446) is defined as follows:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure.

I.e. there is no clear reference where the ECDSA-Sig-Value structure is 
defined.

At the same time, in TLS 1.2 (RFC 5246) it is defined as follows:
   signature
      This field indicates the signature algorithm that may be used.
      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
      [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively.  The
      "anonymous" value is meaningless in this context but used in
      Section 7.4.3.  It MUST NOT appear in this extension.

with [ECDSA] being reference to X9.62-2005 in both standards.
In other parts of RFC 5246 there's also a reference to RFC 4492, but non-
normative.

Now, I don't have access to X9.62-2005, but there's a possibility of 
confusion. The RFC 5246 defines the ECDSA-Sig-Value as follows:

           Ecdsa-Sig-Value ::= SEQUENCE {
               r       INTEGER,
               s       INTEGER
           }

At the same time SEC 1 v2.0[1] defines that structure as follows:

           ECDSA-Sig-Value ::= SEQUENCE {
               r INTEGER,
               s INTEGER,
               a INTEGER OPTIONAL,
               y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
           }

(or in case the programmer confuses ECDSA-Sig-Value with ECDSA-Signature (or 
uses API that accepts the latter), then also the following encoding may be 
used:

           ECDSA-Full-R ::= SEQUENCE{
               r ECPoint,
               s INTEGER
           }
)

Now, my understanding is that only the two-integer SEQUENCE is supposed to be 
used or supported, but I don't think it follows directly from the text. So I 
think the RFC 8446 should be updated with an erratum that specifies the source 
of the ECDSA-Sig-Value structure.

 1 - https://www.secg.org/sec1-v2.pdf
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Dan Brown <[email-masked]>
Date: Mon, 30 Sep 2019 14:40:57 +0000

A brief reminder below about 2 new extra elements of ECDSA-Sig-Value.

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Hubert Kario
> Sent: Monday, September 30, 2019 8:56 AM
...
>                y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL

The new a and y values help a verifier recover the point R (where R=kG, and 
r=x(R) mod n, s=(e+dr)/k mod n), if desired.

Of course, it is possible to recover R from r, without a or y, but the 
downside is that such recovery seems to requiring test two different 
candidates for R.

There are a few small benefits of recovering R.

Faster verification: the verifier can verify as tsR=teG+trQ with a value t 
chosen to make both ts and tr small, which can be faster than using r alone.

Public-key recovery: the verifier can compute the signer's public key as Q = 
(1/r)(sR-eG).  The subtle sub-applications of Q-recovery include: 
proof-of-generation (if the message signed contains Q, then Q seems to be 
uniquely tagged), data compression (omitting Q from the cert), assisted key 
generation (a trusted authority adds entropy into Q).

I'm not sure if these applications are relevant to TLS, however.

At the ASN.1 and DER formatting level, the intent was that
 (1) old syntax signatures (r,s only) would be compatible with the new syntax 
since optional fields are DER-encoded as empty strings, to empty string should 
DER-decode (is this right?), and
 (2) a lax, liberal implementation of the old syntax would understand the new 
syntax, simply by ignoring the new values a and y, (and ignoring the total 
length of the DER encoding).

Of course, the strictly proper way to do (2) was to have put an ASN.1 "..." 
placeholder in the old syntax, thereby accommodating for future extensions. 
Alas, this was not put in.  So a strict, literal implementation of the old 
syntax should reject the new syntax.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Oct 2019 01:47:17 +0000

Hubert Kario <[email-masked]> writes:

>So I think the RFC 8446 should be updated with an erratum that specifies the
>source of the ECDSA-Sig-Value structure.

It looks like the SECG either defined their own gratuitously incompatible
version (since the X9.62 version has no extension markers) or accidentally
picked a name that clashes with the X9.62 one, presumably the latter.  So it'd
mostly be a note saying that SECG chose a clashing name, and the source should
be the definitive ECC standard X9.62, not the alternative SECG one.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Oct 2019 01:50:14 +0000

Hubert Kario <[email-masked]> writes:

>confusion.

>From X9.62-2005:

  E.8 Digital Signatures

  When a digital signature is represented with ASN.1, the digital signature
  shall be ASN.1 encoded using the following syntax:

So the SECG re/mis-definition is definitely the wrong one.

Peter.