Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad
Eran Messeri <eranm@google.com> Fri, 12 May 2017 13:42 UTC
Return-Path: <eranm@google.com>
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 B57BA12EC08 for <trans@ietfa.amsl.com>; Fri, 12 May 2017 06:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 H9FI8ch24Spy for <trans@ietfa.amsl.com>; Fri, 12 May 2017 06:42:05 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 582DB129AE8 for <trans@ietf.org>; Fri, 12 May 2017 06:36:35 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id o5so10609747ith.1 for <trans@ietf.org>; Fri, 12 May 2017 06:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ttCCsnRGvdwDNyC/4OvrsZpNOW3c+oU9I6RdTti40DE=; b=vfuYmgw9CEwQ1w17CV/mzdPltzLkSd1zLfyQSdhLEfBgbMstvuzvQa5N6QC+iuII3V hocZvERMx11DKV+MVASkzCeU4HLnUgeI6mu+HW6fTjlcBUfSZNvQf5OK4GXpRciVC3Wt kaPcsYx4lH3gUZF6y920Osu4rd974AnhGb9yxiPwcpgyvrGXgzUo0jxkRpvgoK/zWhXo QfP4ZI2l2/OA4aruhx/vXvTt3H+qMYmkc4vhorDckvgjj6rYjmJFFhEautCx8jVzdojp 9lPdb1V1h8TrB3wpZ91z9u1v2WsKHqeAk64ctlW7cgyhB41qgKroC1CU/F85JUUkTEhs umLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ttCCsnRGvdwDNyC/4OvrsZpNOW3c+oU9I6RdTti40DE=; b=DddmpBaTUTltbv1/LdD04B4oiNo/LBKqWhBOaC1a/jvZaExAi2K36wZ72TUIkpndkK uCQMmwSZMlZvXsLu3XngmEc0m/BNaVV/CU1CfADDJiYE7tfkqNbCjJ4BS4uPirYtQWMs 0N9HpB2/fBswgQKHncX57IpmbW8kfIeQb4QU9bEdAD2M+AizlGDayHtPBKJwCyGbibB0 NpJQUFaUCrACopqPz8Wlt8gvwbABEgfGmqid29DBvnf4lNvkhAZf0yy1ABFLDy2JrdIi EpD83iGszDzWT7cyD2gTby+aeswjLaGic0K00QLNPptgzFYeD8VhjWyVRINNpZRjRcN7 01vQ==
X-Gm-Message-State: AODbwcDETE2NT449/+YS68wdkO5xm9KPdGRK+s0BhH8DDgVBNm0nzmkH nRnC+AtXEBbqKWEz3pKWwLyzJWp7A7Yl6bM=
X-Received: by 10.36.55.149 with SMTP id r143mr3132224itr.53.1494596194565; Fri, 12 May 2017 06:36:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.129.6 with HTTP; Fri, 12 May 2017 06:36:04 -0700 (PDT)
In-Reply-To: <CA+cU71kVV_o30p-+dGdLT9Hpg+iiW5KgG-9xJD9iVCEHwhLg6w@mail.gmail.com>
References: <CAFewVt5z3sq-Occ1VaHeNeBvt1yyCM_3_nssZSu2f_PBEL4SFQ@mail.gmail.com> <CA+cU71kBmKsxyvsmpuF6UAzP+fict3v62gEq_iKY-O2P07ZRLw@mail.gmail.com> <87pofiif6g.fsf@nordberg.se> <CA+cU71kVV_o30p-+dGdLT9Hpg+iiW5KgG-9xJD9iVCEHwhLg6w@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
Date: Fri, 12 May 2017 14:36:04 +0100
Message-ID: <CALzYgEeHpxRSxpQTSPasdahWXdzV8bGMV_R4HM02oscHrm8TWw@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
Cc: Linus Nordberg <linus@sunet.se>, "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140c83842dfa3054f53cb72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/9tP5-dHjp0UwcvxVeGDdkC9RJhU>
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: Fri, 12 May 2017 13:42:08 -0000
Thanks for the feedback. It helped me realize deterministic signatures could be achieved not only by using a deterministic signature scheme, but also by logs storing the produced signatures and returning them instead of re-signing SCTs, for example. That's my understanding of the discussion so far: * Requiring the use of RFC6979 is bad, for the reasons Brian has mentioned. * It is not yet clear where deterministic signatures may be more important (SCTs or STHs) because it's not clear what TLS clients will gossip and how. * It is not necessary to require the use of a deterministic signature scheme - only that the same signature is present in all instances of a particular SCT (note that different SCTs for the same submission, with different timestamps, which the log may issue, cannot have the same signature). Also, in 6962-bis, my focus is on correct operation of the log & Merkle Tree - and deterministic signatures are not strictly necessary for that. To make progress on this issue, I propose the following: * Remove references to 6979. * Remove the strong requirement to use deterministic signature schemes (MUST -> SHOULD), so implementations can use non-deterministic signature schemes and still be compliant with the spec. * Add reference to EdDSA, which includes a deterministic signature scheme variant. * Mention that deterministic signatures can be achieved by storing the produced signatures. Any objections? On Tue, May 9, 2017 at 6:43 PM, Tom Ritter <tom@ritter.vg> wrote: > On 9 May 2017 at 03:53, Linus Nordberg <linus@sunet.se> wrote: > > 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). > > I agree that we could catch logs who do this to STHs relatively easily. > > >> 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. > > Definitely agree that we not mandate how it is done. > > I guess I'm more on the fence now because of the STH situation. > > -tom > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >
- [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