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

From: Dan Brown <[email-masked]>
Date: Tue, 1 Oct 2019 10:47:19 +0000

Re ECDSA specs and paywells:
ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 years, despite my weak effort.
A revival, ANSI X9.142, with almost the same content is under way, though even its fate is unsure.
Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA and EdDSA (not ASN.1?), which many may like (even better than ANSI).
Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or not, despite my weak effort.
IETF has specs for sigs and their formats already, no?
Then there's ISO, IEEE, ...

  Original Message  
From: John Mattsson
Sent: Tuesday, October 1, 2019 5:25 AM
To: Peter Gutmann; Hubert Kario; [email-masked]
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

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

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I&s=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=

---

From: John Mattsson <[email-masked]>
Date: Tue, 1 Oct 2019 12:26:42 +0000

Dan Brown <[email-masked]> 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. 

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

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

Cheers,
John

-----Original Message-----
From: Dan Brown <[email-masked]>
Date: Tuesday, 1 October 2019 at 12:47
To: John Mattsson <[email-masked]>, Peter Gutmann <[email-masked]>, Hubert Kario <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS]  Ecdsa-sig-value in TLS 1.3 – need for erratum?

      Original Message  
    From: John Mattsson

    

    
    Cheers,
    John
    
    _______________________________________________
    TLS mailing list
    [email-masked]
    https://protect2.fireeye.com/url?k=749c6dba-280e60e6-749c2d21-0cc47ad93d46-3da924ab2cfe57e8&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_tls%26d%3DDwICAg%26c%3DyzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE%26r%3DqkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw%26m%3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I%26s%3Dp2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU%26e%3D

---

From: Rene Struik <[email-masked]>
Date: Tue, 1 Oct 2019 09:29:29 -0400

Hi Dan:

Just curious about the fate of ANSI X9.62-2005: On the website below, this specification is still listed as "active" (whereas ANSI X9.62-1998 is labelled historic).
I purchased that spec for a project on Nov 22, 2016 from the ANSI webstore (when, surely, it was not labelled as expired) [see purchase info below].

What happened? Was someone sleeping at the wheel? Why would there be a completely differently named "revival", ANSI X9.142, with almost the same content, under way, and why would its fate, 4 years after 2015, be unsure? Is there a technical reason ANSI did not wish to pursue this, or admin mishaps?

Rene

Note: purchase info RS from ansi store below:
Subject: Your Order Confirmation for X_458150
From: [email-masked]
Date: 11/22/2016, 2:57 PM
To: [snip]
25 West 43 Street
New York, NY 10036
Tel: 212.642.4900
Fax: 212.398.0023
Sold To
Rene Struik
[snip]
CANADA
Order ID X_458150
Card Received Mastercard
Charged to Account ****[snip]
Date 11/22/2016
Quantity Product Unit Price Total Price
1 ANSI X9.62:2005 $100.00 $100.00 Download
Total $100.00
THANK YOU FOR USING THE ANSI STANDARDS STORE.
The American National Standards Institute (ANSI) is a private non-profit organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
The standards you purchased were added to your Alerts Profile, which will allow you to receive an automatic
notification via email when the documents are revised or amended. You may manage your alerts at any time.

https://standards.globalspec.com/std/1955141/ANSI%20X9.62

On 10/1/2019 6:47 AM, Dan Brown wrote:
> https://www.ietf.org/mailman/listinfo/tls

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Dan Brown <[email-masked]>
Date: Tue, 1 Oct 2019 13:52:19 +0000

> From: John Mattsson <[email-masked]>
>
> 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.

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

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

---

From: Dan Brown <[email-masked]>
Date: Tue, 1 Oct 2019 14:18:10 +0000

Sorry to TLS-WG if this getting out of TLS scope.  (Let me know, and I will be happy to cease this thread.)

Hi Rene,

Did you mean to ask me about the ANSI X9.62 expiration off-list? I’ll assume not, and answer on-list.  

1.	I was told often by X9 admin and chairs that ANSI X9.62 was withdrawn.  Are you doubting the withdrawal?
2.	When I visited ANSI just to confirm 62 expiration, https://webstore.ansi.org/Search/Find?in=1 <https://webstore.ansi.org/Search/Find?in=1&st=X9.62> &st=X9.62 reports nothing found.
3. The globalspec site you mention is news to me, though I never bother to search the whole web for X9.62.  I sympathize with others that need to: sorry to you.
4.	I imagine that there many reasons for the expiration, many beyond my grade, but, as you say, I (unlike some) often nap, so it’d be fair to grade me at 50%.  Am I to infer that you are more baffled about all this than I am?
5.	Yes, “revival” is my term, and in no way an official, so it’s sensible to quote me on it.

	Dan

From: Rene Struik <[email-masked]> 
Sent: Tuesday, October 1, 2019 9:29 AM
To: Dan Brown <[email-masked]>; John Mattsson <john.mattsson=[email-masked]>; Peter Gutmann <[email-masked]>; Hubert Kario <[email-masked]>; [email-masked]
Subject: (question on ANSI X9.62-2005) Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

Hi Dan:

 
Rene
 
From: [email-masked] <mailto:[email-masked]> 
 
https://standards.globalspec.com/std/1955141/ANSI%20X9.62 <https://urldefense.proofpoint.com/v2/url?u=https-3A__standards.globalspec.com_std_1955141_ANSI-2520X9.62&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=GWxp2Bkr_PO-b6yqjHlSg6UyHEqtMmHRuBwfpqchO7c&s=jYe-ABDhTsOLtk6YVz_62-Hc3mixZpwqMVoyCllAYOE&e=> 

  Original Message  
From: John Mattsson
Sent: Tuesday, October 1, 2019 5:25 AM
To: Peter Gutmann; Hubert Kario; [email-masked] <mailto:[email-masked]> 
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
 
Hubert Kario  <mailto:[email-masked]> <[email-masked]> wrote:

 

Cheers,
John
 
_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I&s=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=> &d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I&s=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=

_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=GWxp2Bkr_PO-b6yqjHlSg6UyHEqtMmHRuBwfpqchO7c&s=CSGRJ6MtwYWjiDpT8RI38oPqbcrfDOYA_Yi5hBFv_Sk&e=> 

-- 
email: [email-masked] <mailto:[email-masked]>  | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Oct 2019 08:01:54 -0700

On Tue, Oct 1, 2019 at 5:27 AM John Mattsson <john.mattsson=
[email-masked]> wrote:

> behind a paywall is even worse.
>

Ugh.

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

I agree with you about the policy here. To be honest, I just didn't notice
this; and it would probably need some github spelunking to figure out the
history of these references.

If someone wanted to propose an erratum that would fix this, I would be
very appreciative.

-Ekr

> To: John Mattsson <[email-masked]>, Peter Gutmann <
> [email-masked]>, Hubert Kario <[email-masked]>, "
> [email-masked]" <[email-masked]>
>     Also, I expect FIPS 186-5 is nearly ready, and will specify much of
> ECDSA and EdDSA (not ASN.1?), which many may like (even better than ANSI).
>     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.
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Oct 2019 05:46:47 +0000

>I agree with you about the policy here. To be honest, I just didn't notice this; and it would probably need some github >spelunking to figure out the history of these references.

The reference comes from RFC 5246 (TLS 1.2). In 2008 the specification was not withdrawn.

> If someone wanted to propose an erratum that would fix this, I would be very appreciative.

Pointing out the problem is easy, but I don't know what to put in "It should say:". Pointing to SEC1 is not good if that is incompatible with NIST/ANSI. ISO and IEEE are behind paywalls. At this point it is probably best to wait for NIST SP 186-5 (NIST said earlier they hoped to release a draft version by May 2019, so I assume it will be released very soon).

RFC 8422 is also referencing ANSI X9.62-2005 and would need a similar errata.

John

From: Eric Rescorla <[email-masked]>
Date: Tuesday, 1 October 2019 at 17:02
To: John Mattsson <[email-masked]>
Cc: Dan Brown <[email-masked]>, Peter Gutmann <[email-masked]>, Hubert Kario <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

On Tue, Oct 1, 2019 at 5:27 AM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> wrote:

Ugh.

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

I agree with you about the policy here. To be honest, I just didn't notice this; and it would probably need some github spelunking to figure out the history of these references.

If someone wanted to propose an erratum that would fix this, I would be very appreciative.

-Ekr

Cheers,
John

-----Original Message-----
From: Dan Brown <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 1 October 2019 at 12:47
To: John Mattsson <[email-masked]<mailto:[email-masked]>>, Peter Gutmann <[email-masked]..ac.nz<mailto:[email-masked]>>, Hubert Kario <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS]  Ecdsa-sig-value in TLS 1.3 – need for erratum?

      Original Message
    From: John Mattsson
    Sent: Tuesday, October 1, 2019 5:25 AM
    To: Peter Gutmann; Hubert Kario; [email-masked]<mailto:[email-masked]>
    Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

    Cheers,
    John

    _______________________________________________
    TLS mailing list
    [email-masked]<mailto:[email-masked]>
    https://protect2.fireeye.com/url?k=749c6dba-280e60e6-749c2d21-0cc47ad93d46-3da924ab2cfe57e8&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_tls%26d%3DDwICAg%26c%3DyzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE%26r%3DqkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw%26m%3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I%26s%3Dp2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU%26e%3D

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Hubert Kario <[email-masked]>
Date: Wed, 02 Oct 2019 13:18:07 +0200

On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote:
> > ECDSA

I just did propose an erratum for that.

-- 
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: Hubert Kario <[email-masked]>
Date: Wed, 02 Oct 2019 13:23:31 +0200

> I just did propose an erratum for that.

https://www.rfc-editor.org/errata/eid5868
-- 
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: Sean Turner <[email-masked]>
Date: Wed, 2 Oct 2019 12:33:28 +0100

> On Oct 2, 2019, at 12:23, Hubert Kario <[email-masked]> wrote:
> 
> Signed PGP part

On the 5480 vs 4492 reference.  4492 is also in the DOWNREF registry so it’s okay on that front, but three’s no ASN.1 module.  That ASN.;1 come from the ASNI X9.62 spec.  I have a slight preference to refer to 5480 and just add the reference.

spt