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

Linus Nordberg <linus@sunet.se> Tue, 09 May 2017 08:54 UTC

Return-Path: <linus@sunet.se>
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 21501127B5A for <trans@ietfa.amsl.com>; Tue, 9 May 2017 01:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uLeptYhMGEVb for <trans@ietfa.amsl.com>; Tue, 9 May 2017 01:53:58 -0700 (PDT)
Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD951243FE for <trans@ietf.org>; Tue, 9 May 2017 01:53:58 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v498rtVO000703 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 10:53:55 +0200
Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v498rq42017386 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 08:53:55 GMT
From: Linus Nordberg <linus@sunet.se>
To: Tom Ritter <tom@ritter.vg>
Cc: trans@ietf.org
Organization: Sunet
References: <CAFewVt5z3sq-Occ1VaHeNeBvt1yyCM_3_nssZSu2f_PBEL4SFQ@mail.gmail.com> <CA+cU71kBmKsxyvsmpuF6UAzP+fict3v62gEq_iKY-O2P07ZRLw@mail.gmail.com>
Date: Tue, 09 May 2017 10:53:59 +0200
In-Reply-To: <CA+cU71kBmKsxyvsmpuF6UAzP+fict3v62gEq_iKY-O2P07ZRLw@mail.gmail.com> (Tom Ritter's message of "Mon, 8 May 2017 12:38:45 -0500")
Message-ID: <87pofiif6g.fsf@nordberg.se>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: CanIt (www . roaringpenguin . com)
X-Scanned-By: MIMEDefang 2.74
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN)
X-p0f-Info: os=unknown unknown, link=Ethernet or modem
X-CanIt-Geo: ip=2001:6b0:8::129; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6
X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default)
X-Canit-Stats-ID: 0aTi8RTPA - bad6f2f0d24b - 20170509
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=<linus@sunet.se>; helo=smtp1.nordu.net; identity=mailfrom
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/eAmPSWdNtD1DGpvOGVAEe2Hu3ck>
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: Tue, 09 May 2017 08:54:01 -0000

Tom Ritter <tom@ritter.vg> wrote
Mon, 8 May 2017 12:38:45 -0500:

> Anyway, so I still think there's fingerprinting concerns. But even if
> we require deterministic signatures - if the log *wants* to be
> malicious, it can still issue non-deterministic signatures, and
> there's no way to know, because as I said above - detection is hard.

You seem to focus on SCTs, which are indeed hard to share between
privacy concerned clients because they contain sensitive data. But STHs
have signatures too and I think we should limit the ways a log can track
clients asking for STHs.

Catching a log serving different log clients different bits for the same
timestamp, tree_size and root_hash is a matter of clients comparing
retrieved STHs. Keeping the requirement for deterministic signatures and
the limitation on STH issuance frequency (6962bis-24 4.8) makes
gossiping about STHs reasonable even for clients serving end users with
privacy expectations (gossip-04 10.5.4).


> So I think Eran's suggested changes are okay.

I think we should keep requiring deterministic signatures being used but
stop mandating how it is being done.