[Trans] The RFC6979 requirement in RFC6962-bis is bad

Brian Smith <brian@briansmith.org> Thu, 04 May 2017 22:21 UTC

MIME-Version: 1.0
From: Brian Smith <brian@briansmith.org>
Date: Thu, 04 May 2017 12:21:14 -1000
Message-ID: <CAFewVt5z3sq-Occ1VaHeNeBvt1yyCM_3_nssZSu2f_PBEL4SFQ@mail.gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/-S0iP5xjcjAQP0tNRAEvsOvpFrU>
Subject: [Trans] The RFC6979 requirement in RFC6962-bis is bad
Precedence: list

Hi,

Recently I implemented RFC 6979 and also I'm implementing some CT things.

Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA
signatures. However, the requirement to use RFC 6979 is problematic
for several reasons, noted below. I think this group should reconsider
if the fingerprinting threat that motivated the requirement for
deterministic signatures is significant enough to overcome these
problems.

If the requirement for deterministic signatures were removed, all the
problems below would be resolved. (Additionally the more secure
RSA-PSS could be mandated instead of the obsolete and less safe PKCS#1
1.5.)

If it is still seen as very important to require signatures be
deterministic, the requirement to to use specifically RFC 6979 should
be be removed, and replaced with a more general requirement to use
*some* secure deterministic nonce for ECDSA signatures, without
mandating RFC 6979 specifically.

Here are the problems I see with mandating the use of RFC 6979:

1. RFC 6979 deterministic signatures are not and cannot be compliant
with FIPS and other regulations. This means, in particular, that a log
cannot use the same CABForum-compliant (HSM) ECDSA implementation that
it could use to sign certificates.

2. RFC 6979 is a very inefficient way of generating deterministic
signatures. Every RFC 6979 signature requires invoking the SHA-256
compression function 19 to 22 times. The BitCoin core developers
reported that this takes 10% of total signature generation time. [0]

3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for
ECDSA. This is a step backward from recent progress towards provable
security of internet protocols.

4. Because of #1, #2, and #3, most crypto libraries and HSM
implementations would be better off using a different deterministic
signature scheme (such as a variant of the much more efficient one
used for Ed25519). And/or they may use a different, non-deterministic,
solution to the concerns that originally motivated the creation of RFC
6979 in the first place, such as the one that Google's BoringSSL [1]
and Cisco [2] have implemented. If one is going to use a better
scheme, then maintaining RFC 6979 support too just for this one
protocol is a large burden.

5. There is no way to check that the log actually used RFC 6979, or
any other specific secure deterministic scheme, because part of
calculating the nonce involves hashing the private key. Thus the
requirement to use RFC 6979 is unenforceable technically or even by
policy.

[0] https://crypto.stackexchange.com/a/42551 (I can't find the
original citation for what the Bitcoin people said.)
[1] https://boringssl.googlesource.com/boringssl/+/783e0957875ac62b35aa4f8741069e133695a3d4
[2] https://blogs.cisco.com/security/fips-and-deterministic-ecdsa-achieving-robust-security-and-conformance

Cheers,
Brian
--
https://briansmith.org/

[Trans] The RFC6979 requirement in RFC6962-bis is… Brian Smith
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Eran Messeri
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Brian Smith
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Rob Stradling
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Tom Ritter
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Andrew Ayer
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
[Trans] What logs are storing (was: The RFC6979 r… Linus Nordberg
Re: [Trans] What logs are storing (was: The RFC69… Andrew Ayer
Re: [Trans] What logs are storing Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] What logs are storing (was: The RFC69… Eran Messeri
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Tom Ritter
Re: [Trans] What logs are storing (was: The RFC69… Al Cutter
Re: [Trans] What logs are storing (was: The RFC69… Andrew Ayer
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Eran Messeri
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Brian Smith
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Eran Messeri
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Eran Messeri
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Gary Belvin
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Eran Messeri
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Linus Nordberg
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Andrew Ayer
Re: [Trans] The RFC6979 requirement in RFC6962-bi… Al Cutter