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

From: John Mattsson <[email-masked]>
Date: Tue, 1 Oct 2019 09:25:25 +0000

Hubert Kario <[email-masked]> wrote:
    
> Now, I don't have access to X9.62-2005, but there's a possibility of confusion.

I think references to specifications behind paywalls and other types of limited access is a major problem. Not only for the standardization process, but also for researchers and implementors. In general, I think people should be able to implement and analyze IETF standards without having to pay for access.

Open-access is even more important for security specifications. ANSI X.62 is hopefully quite well-studied, but for other references, the lack of analysis often leads to mistakes and unknown weaknesses.

I would like the IETF to take a much stronger stance against normative references to paywalls. 

Cheers,
John

---

From: Hubert Kario <[email-masked]>
Date: Tue, 01 Oct 2019 14:49:37 +0200

On Monday, 30 September 2019 16:40:57 CEST Dan Brown wrote:
> 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
> 
> ...
> 
> > 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
> >            
> >            }
[snip] 
> 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

yes, in DER, OPTIONAL field that has no value results in a string of 0 octet 
length

so the above quoted structure with "a" and "y" omitted will be bit for bit 
identical with the ECDSA-sig-value structure defined in X9.62-2005 (Thanks 
Peter for providing the relevant section). So for "traditional" format of 
signatures, they will be compatible, it's when an implementation starts to be 
"helpful" by providing those additional values that SEC1 implementation will 
start to fail to interoperate with X9.62 implementation.

>  (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.

a lax DER parser sounds like an oxymoron to me... :)

And I've checked, the TLS since the beginning was specifying signature as 
encoded with DER, not BER
-- 
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: Peter Gutmann <[email-masked]>
Date: Tue, 1 Oct 2019 22:15:13 +0000

>a lax DER parser sounds like an oxymoron to me... :)

That's why I assumed it was an accident/error.  Writing a spec that relies on
buggy parser implementations in order to work is asking for trouble.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 02 Oct 2019 12:59:09 +0200

On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote:
> That's why I assumed it was an accident/error.  Writing a spec that relies
> on buggy parser implementations in order to work is asking for trouble.

well, SEC 1 does not require the ECDSA-Sig-Value structure to be encoded with 
DER, it's TLS that does that (and I'd say for the better, given the multitude 
of ways you can encode SEQUENCE in BER...)
-- 
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: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Oct 2019 16:16:01 +0000

I concur with Hubert, and think that DER in this context is perfectly OK.

On 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario" <[email-masked] on behalf of [email-masked]> wrote: