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

I share the concern, due to the difficulty I've had finding implementations
of this RFC (or any deterministic signature scheme for ECDSA in general).

I'd like to hear the opinion of people who've worked on the Gossip protocol
- as Brian said, the purpose behind deterministic signatures is to make it
difficult to fingerprint individual clients. However, the only gossip
that's taking place right now is STH exchange between monitors, where this
is not a concern,

My proposal for 6962-bis is then to:
* State 6962-bis logs SHOULD use a deterministic signature scheme (making
it optional, but strongly suggested).
* Remove normative references to RFC6979.

Eran

On Thu, May 4, 2017 at 11:21 PM, Brian Smith <brian@briansmith.org> wrote:

> 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 mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>