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

Andrew Ayer <agwa@andrewayer.name> Mon, 08 May 2017 18:11 UTC

Return-Path: <agwa@andrewayer.name>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB4128AFE for <trans@ietfa.amsl.com>; Mon, 8 May 2017 11:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Level:
X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRP1u0Gsn5B5 for <trans@ietfa.amsl.com>; Mon, 8 May 2017 11:11:43 -0700 (PDT)
Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C3712896F for <trans@ietf.org>; Mon, 8 May 2017 11:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494267102; bh=7TSLDuYrNrJIBmVfqaFhptMKRzYc5Y2YzyrgG6nkq/8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=b3B5L4QnE2gju1Xc6cBHxR7OLn8gmrqFomarB1zdRbRiCUr74S+ExQsVexW0GrYej aYrvf5ICjm+kudhboB5CLccxsLfhZ3HDsk/MHFQsUI33W8pmsG/x0AsnVmPYCtDf0N knLqOa+mXlUjnquI5wIEDvqUwytKjCMTU6vr9QBpPYrI4AfX905lI9XvdUNDA5P4sZ DHWpLfx93wdFkl1CFQ/F0szDbdH2UC6ib5DmLTei9iFdi+OiUngO/BR8UOhxIjWWD8 wU487K4s5j64BMafIMQS37ZzsfAYLrwfy5YuX8ik0ieu3WWcqg6vvP3259IWQGYHwf OWj8vqOd5X+TA==
Date: Mon, 08 May 2017 11:11:41 -0700
From: Andrew Ayer <agwa@andrewayer.name>
To: Brian Smith <brian@briansmith.org>
Cc: "trans@ietf.org" <trans@ietf.org>
Message-Id: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name>
In-Reply-To: <CAFewVt5z3sq-Occ1VaHeNeBvt1yyCM_3_nssZSu2f_PBEL4SFQ@mail.gmail.com>
References: <CAFewVt5z3sq-Occ1VaHeNeBvt1yyCM_3_nssZSu2f_PBEL4SFQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/U9AAs0aXJ1opBQypt1SM31XWdgo>
Subject: Re: [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: Mon, 08 May 2017 18:11:44 -0000

On Thu, 4 May 2017 12:21:14 -1000
Brian Smith <brian@briansmith.org> wrote:

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

I think preventing fingerprinting is important.  I suggest we loosen
the requirement on logs.  Logs should still be forbidden from producing
more than one distinct signature for any given STH or SCT, but we
shouldn't specify how logs must satisfy this requirement.

Here are some of the ways a log could satisfy this requirement:

1. Use RFC 6979.

2. Use a different deterministic signature scheme.

3. When producing a new STH or SCT, sign it, store the signature, and
serve the stored signature instead of re-signing on-the-fly every time
the log needs to serve the STH or SCT.  Since the log already needs
to store information about STHs and SCTs, also storing the signature
should not be burdensome.

I'll also note that forbidding the log from producing more than one
signature per STH makes it slightly easier for people participating in
STH pollination to deduplicate STHs, as it becomes possible to
deduplicate based on the entire STH rather than parsing out the
non-signature parts.

Regards,
Andrew