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

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

Return-Path: <brian@briansmith.org>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9045C129478 for <trans@ietfa.amsl.com>; Thu, 4 May 2017 15:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dGLW2Bro8UQK for <trans@ietfa.amsl.com>; Thu, 4 May 2017 15:21:16 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6DE129469 for <trans@ietf.org>; Thu, 4 May 2017 15:21:15 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id e65so7579266ita.1 for <trans@ietf.org>; Thu, 04 May 2017 15:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GQB/GSJjXn/FbiI7hEXbQnN6zBZKP5rF8F5U+/Xe7MA=; b=PYYaTg7lRQk9mELg6MpY6Boor3E9pKyN8Ft6aUNfVvzvV9mmX1RH4dSAQD3R5RaGUC ukLDLREMbrpmDR4AAeILevybwNSIsa/zqTw0LIkD3os4WngT6frW9haAtfwBLf2TcuyH MWezqMoiOPMFa/8BxhV5S9ypfoJJRwKMi355k8EnTZIx5nhrmwFrRdvGJa417oRSONU3 ib4hco3Wb1tLrB1jiOVbog7QdTH/hsAu2g+0vXXSqzQblCgmv8qVEgAcDN/l4NLratLe a4kEWpmvh4lEKbX7uBXBHBqH8WYNWjzApZs4SN+pyhdbP6hi1+KbMYeIiJ/d5mG44Y36 1OOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GQB/GSJjXn/FbiI7hEXbQnN6zBZKP5rF8F5U+/Xe7MA=; b=KyIKn60HsD1IHGEBVNPkRUjqZDpUpBeE0I7FEh6IXSljrbeLkBWsNDLOxi/21ZrEIm QDt5Xs3A/L7O01B/hHQh1fW6STP2qH2sC9441aYviE4shhP18E5wpah3Q5/wt81+wDd4 aGiQEnfgKD4s+uGBb3xeR6r051+Y/frPc7e8TV49Y0I9nQaZVG5RoHVmNgsWP2e3sLbe MYElCdShYS1xLk7KmKG0udkIzL9R9vnH0tg8ji/vgx/zUsTjcPNRYpIHpz6pa/Scaz14 NF1cLh3f5Hkq8DCfsqWFE26mj4QO7HHa+cTqsoBF5Phhsvz/eOjaNtRiK3nyuvpeBY1i MGaQ==
X-Gm-Message-State: AN3rC/4FARIR/zlZRmBq13wf7rnXgLOsdKDJRllx1fZbcPx3WP0HGyeZ up7+MzqHQWFnz1YwdJp60zYjLWW976P6
X-Received: by with SMTP id a82mr4958748itd.90.1493936474817; Thu, 04 May 2017 15:21:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 4 May 2017 15:21:14 -0700 (PDT)
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
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2017 22:21:19 -0000


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

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

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

[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