Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad
Eran Messeri <eranm@google.com> Mon, 22 May 2017 12:23 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 3D452129C5A for <trans@ietfa.amsl.com>; Mon, 22 May 2017 05:23:47 -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 yKztLtWvyqix for <trans@ietfa.amsl.com>; Mon, 22 May 2017 05:23:44 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 6E8471293FD for <trans@ietf.org>; Mon, 22 May 2017 05:23:44 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id o5so150525748ith.1 for <trans@ietf.org>; Mon, 22 May 2017 05:23:44 -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=t4Fxi0/lcqExHrOfmtuCx/WJWH4ZZnBZU16xlpUqP2Y=; b=rShHHZcQDbXxrEpODuOc4n7ow5uKrVpgGzdKpi1dZvXHehPCwwuCtoegFWLffk/Xx+ PS0mM62D10vO0RDndYZCwZNzZJXtBsmw6rzPUXAMqDcjqIng9DsGJdKJr/Pa/Dp1TeCj qWwAQxK73+7HMtLlbrKSL5gi7AbtTBLOBa257jWQ9PGC6H5tU91NhE75acP2ViZjXkk1 aGnLsOZPwNmImZYKZlg7UP5tfmmeNIxFxnbCYCRrFFOVQS9dCUPd6IqH6p3z2KqanAJG r8SjEw2NSR8XzsImAtadWd6Z6H4fibEdX5UL3sqrioVtmQO57b8/smkQuU5Cyy0hpUir H6pw==
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=t4Fxi0/lcqExHrOfmtuCx/WJWH4ZZnBZU16xlpUqP2Y=; b=XNdUoaTT6WmO/CpswQefOCdgDK4TuHZUq3rVJrxB0J0OeU3XxoaT/BWKxd+/4zLdya Dw8J5KHb6hjNdwd3aVn08ffnEn68lwOmkvRvlhRQdeR/Twru9YLPAvIZLgohoZDJKPPS bzEA49FI+h4d37/ECvQ+Kg25uJGyaAaliTTCeGul94b9punT+WlI1sB/LZbbg3k6GZrf OCDdUqATHHLKScPkBMbNaDw/H3rKGXWxpuIkI6y7t3C27Wp79tIjAFLAwG0jqu4iyFpq 71hET1iTZHHWd/8R/Da7GteI5NhnaUbg4xYAiCkcWu4o9kwzhArlSnD9EuDXy3cjFFjM 94WA==
X-Gm-Message-State: AODbwcDLV0G6+2h9um8pnaDCazMoKmW57W7knPMLoNNFx+8c61CqBxHu WEegGGJpT/u+msDUojwHxnb6xJw+53JQ45F7Tw==
X-Received: by 10.36.50.66 with SMTP id j63mr40709701ita.42.1495455823477; Mon, 22 May 2017 05:23:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.129.6 with HTTP; Mon, 22 May 2017 05:23:12 -0700 (PDT)
In-Reply-To: <CALzYgEdunZXRmGtStGhfJHdHeytk3etYLNtAvFgf3bN2-6EyXQ@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> <CALzYgEeHpxRSxpQTSPasdahWXdzV8bGMV_R4HM02oscHrm8TWw@mail.gmail.com> <87inl25r8l.fsf@nordberg.se> <CALzYgEdunZXRmGtStGhfJHdHeytk3etYLNtAvFgf3bN2-6EyXQ@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
Date: Mon, 22 May 2017 13:23:12 +0100
Message-ID: <CALzYgEeCVnWG19F79OSwCC+iPArZbGGaBZYrKP2MWWdEDGVHVg@mail.gmail.com>
To: Linus Nordberg <linus@sunet.se>
Cc: "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a8eec2388c205501bf116"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/tittXZRosWonh0dUxPlubKxswfw>
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, 22 May 2017 12:23:47 -0000
FYI I'm proposing changes per this discussion in https://github.com/google/certificate-transparency-rfcs/pull/261. Comments welcome. Eran On Mon, May 15, 2017 at 12:35 PM, Eran Messeri <eranm@google.com> wrote: > > > On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <linus@sunet.se> wrote: > >> Eran Messeri <eranm@google.com> wrote >> Fri, 12 May 2017 14:36:04 +0100: >> >> > 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. >> >> Not to argue against that statement but I think that it's clear that >> gossiping about STHs would become more problematic for a client caring >> about privacy if logs were allowed to send different strings of bits to >> different clients for a given pair of `log_id` and `tree_head` in an >> STH. >> >> I completely agree - it would be more difficult for clients caring about > privacy (which should be all TLS clients used by end-users these days, > really) to exchange STHs they've obtained themselves, if logs were allowed > to use unique signatures. > I'm not saying the reasoning is wrong - it is very solid as far as I can > tell - but that we don't know if we need it yet, see below. > > >> > * 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). >> >> This sounds like a requirement, i.e. a MUST, which is not reflected in >> the reasoning below ("MUST->SHOULD" and "Mention that"). >> >> Also, this talks about SCTs specifically. What do you think the story is >> for STHs? >> > Seems to me like the same reasoning applies to both - sorry, wasn't clear > about it. > >> >> >> > Also, in 6962-bis, my focus is on correct operation of the log & Merkle >> > Tree - and deterministic signatures are not strictly necessary for that. >> >> While I think it's fair to try to limit the scope I think it would be >> bad to make it hard to gossip since that's supposed to protect against >> attacks on the ability to audit the correctness of said >> operation. Admittedly, one problem here is that "hard to gossip" is far >> from well defined. >> >> Also, does this imply that the limitation on STH issuance frequency >> should be removed too? >> > I'd leave that, as it has several benefits beyond gossip (for example, the > ability to cache STHs and their consistency proofs or coordinating > selection of an SCT). > >> >> >> > 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? >> >> I think that 6962bis should mandate that the same bits are sent over the >> wire to every client asking for a given piece of signed data. (This can >> be accomplished by either using a deterministic signing scheme or by >> storing the data under a unique key for later use.) >> >> The main reason for this requirement is to make it possible for log >> clients to gossip about STHs -- limiting the number of outstanding STHs >> that a log can have at any given time is important in order to limit the >> ability for a log to fingerprint its clients, as described in >> draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the >> log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that >> the same bits are sent over the wire to everyone asking for a given STH. >> >> The privacy argument for imposing this same-bits-for-same-data rule for >> SCTs too seems weaker since SCTs carry much more privacy sensitive data >> but I'm not convinced that this holds for all gossip >> scenarios. Fingerprinting of a gossip peer doesn't necessarily relate to >> linking an SCT to a user of an HTTPS client. I think this is reason >> enough to not separate STHs and SCTs with regard to this requirement. >> > > Overall I agree with the sentiment. However I'm trying to balance the > attempt to make SCTs & STHs non-identifying as much as possible with ease > of implementation and the current deployment: > - As Melinda said on a separate post, 6962-bis has to be correct but it > doesn't have to be complete. We could add the stricter requirement of > producing consistent signatures for the same data later on. > - There's an added cost for implementations: Either more storage (storing > produced signatures) or reliance on features that are not widely supported > in crypto libraries (deterministic signatures). > - Right now, how the gossip is going to take place is unclear: The only > thing currently operating (AFAIK) is STH exchange between several monitors. > I don't know of any TLS client implementation that intends to fetch STHs > directly (we've actually removed this capability > <https://chromium.googlesource.com/chromium/src/+/dba25668458c87c4b38c63db710c49c47d0db087> > from Chrome recently). Even if there was such an implementation, because > it's not clear who it will be exchanging STHs with, it's unclear what's the > threat model - who has to collude to compromise a client's privacy by > tracking it. > > To put it simply, I don't know yet if we'll need it - which is why I > suggest we strongly recommend deterministic signatures, but not mandate it. > > What do you think? >
- [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