Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis)

Nick Sullivan <nick@cloudflare.com> Thu, 04 May 2017 20:58 UTC

Return-Path: <nick@cloudflare.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 9742E128DF2 for <trans@ietfa.amsl.com>; Thu, 4 May 2017 13:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 m1YrcysIQHRL for <trans@ietfa.amsl.com>; Thu, 4 May 2017 13:58:29 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 C4F66127977 for <trans@ietf.org>; Thu, 4 May 2017 13:58:28 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id g49so17647134uaa.1 for <trans@ietf.org>; Thu, 04 May 2017 13:58:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JV4bMGe14rjaXra08QV8S11MHzFBZPY4oX89qTEMlJc=; b=pVDnBVONsUialkbG6wzZBHKxnOdLIwYM/fbYUbGCDRNrF1Kzumi0CNSRy+ZVjDSN/X 0HeEDlbZE1nCYu58qcEHQC/pChlpP+4N05qUc6/UylYn8UqTM0jyWl39FhFPhnwassQO HrQ7PTAO614PkVApBluzwQYmmlNQ2P+pIoqhQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JV4bMGe14rjaXra08QV8S11MHzFBZPY4oX89qTEMlJc=; b=EPNLxtTWZt7qxDPHzFiWZXCU0CXp9syqZW0xnFIslzg3kJnvNZdz53lllpv19MfuMK U+FRiBKbqhMdRaePcHnMZv1ElkKyzMN0uHcHQxDD2Y16Nt0PpnI5b6Ah3yYZwXGmoSvf 1eOFZnzKjUYWEoe4PgVYAgDsFSSxlVGeOjPEQ29H3GoteVWLaaRIH3MnlY8WOa6iUDBW l3+XVH8+QLxLG8r7bm0MHwtAUyVhCx7w6LykqsPpKyGpMPsF1NGVJ1+FneIe9vGR3+X1 USuIMjRBKkCU1bdLgpVNL2pClwt6ZrvabXnJ80Ug0aYe4iP0iyOx3Ht+SE+yNiDzghQm AW3A==
X-Gm-Message-State: AODbwcB2AGANqmpOMKkbZjGFakiNTVymTHTrA9hwlGFcegGkhqDbHh4r SPirrGt8G1SpW8JR+M1DOsGU83d0znicK4k=
X-Received: by 10.159.59.44 with SMTP id i44mr1279225uah.43.1493931507849; Thu, 04 May 2017 13:58:27 -0700 (PDT)
MIME-Version: 1.0
References: <CALzYgEe+PbYJN6Zz4NnPXBnnhYCi8Op-WmSzFKGxRv+uf+b=sA@mail.gmail.com> <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <CAFDDyk93AcRsCTmt+EPO6VFn-Y4D8g1ETTdGuJrtVk3rH7Xnxg@mail.gmail.com> <20170504123447.41d957a88bd65417e714be78@andrewayer.name>
In-Reply-To: <20170504123447.41d957a88bd65417e714be78@andrewayer.name>
From: Nick Sullivan <nick@cloudflare.com>
Date: Thu, 04 May 2017 20:58:16 +0000
Message-ID: <CAFDDyk-DyBObm2W96R1dZPET-CWwTnitmonkHV2oT+_GH4Gyew@mail.gmail.com>
To: Andrew Ayer <agwa@andrewayer.name>
Cc: Eran Messeri <eranm@google.com>, "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="f403043c4488d84fd1054eb908b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/a-xjmUmDqmeoS3FbVDr8Fs6SHOo>
Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis)
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 20:58:31 -0000

By consistent I mean that if a sequence of STHs such as (A, B, C) are
presented on day 1, that a different sequence is not presented on day 2 (A,
C) or (A, D, B, C).

Rob's language works in term of chronological order.

STH pollination could be a way to support auditing this, but I don't think
it's sufficiently robust as currently defined. To prevent STHs from going
missing, or for new STHs to appear after the fact, STHs should be exchanged
along with metadata indicating the previous and (if it exists yet) the next
STH in the tree.

On Thu, May 4, 2017 at 12:34 PM Andrew Ayer <agwa@andrewayer.name> wrote:

> On Thu, 04 May 2017 19:20:47 +0000
> Nick Sullivan <nick@cloudflare.com> wrote:
>
> > I'm also in favor of this change. I would further suggest that this
> > list be required to be consistent, monotonically increasing and that
> > the results of this API be something that monitors exchange
> > information about.
>
> Hi Nick,
>
> Could you explain what you mean by "consistent"?
>
> As for monotonically increasing, does the following language in Rob's
> PR match what you mean?
>
> "These STHs SHALL be ordered chronologically by timestamp, oldest
> first, beginning with the earliest STH in the specified range."
>
> The gossip draft defines an STH pollination mechanism that monitors can
> use to exchange STHs that they observe.  Would this work, or were you
> thinking about something else?
>
> Regards,
> Andrew
>