[Trans] Removal of STH from get-entries response

Andrew Ayer <agwa@andrewayer.name> Wed, 03 May 2017 16:40 UTC

Return-Path: <agwa@andrewayer.name>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C153A12945C for <trans@ietfa.amsl.com>; Wed, 3 May 2017 09:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bOR4FOGG8lGi for <trans@ietfa.amsl.com>; Wed, 3 May 2017 09:40:38 -0700 (PDT)
Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBE5129434 for <trans@ietf.org>; Wed, 3 May 2017 09:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1493829526; bh=RcT1MbTcJJuHlK6NMRalV3XlR9p5RIxxVV2u2eC+kRc=; h=Date:From:To:Subject; b=s/MOmBPKqXFDtc/BEb8YWgxPzVt4RhmwDeeZVHXhz0Oeind1LNRCeMceFQy2yoXeI wd3N8SwNXz8TlwOOQcAA3vAklXqsjY3DcgOJYSL7MqYxPEb3Ai0GkBPYN7MjdRmaby Ycb3MNBBi5FKcq2D90nAlaEmgcI84N89JVVu/Ede0cBoeitZBMVhgv5rKGBjrS8d02 p7WyGnl0FUf2uJtO0q/gFda+5ZSVVz8oQJqZZtDmrw4qpASJgF2NGI7vSRW496NRUO sEnG9tBpIT2YYRtRo2z75XWmFKqJok5dcChJfBucotNSs9Lel0tFpM59E5qyQkel5w BclbrDH78jgIQ==
Date: Wed, 3 May 2017 09:38:45 -0700
From: Andrew Ayer <agwa@andrewayer.name>
To: trans@ietf.org
Message-Id: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/TOPBmZOpckAKFhXlOpRUVYjE0_k>
Subject: [Trans] Removal of STH from get-entries response
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: Wed, 03 May 2017 16:40:40 -0000

I just noticed that
https://github.com/google/certificate-transparency-rfcs/pull/233 was
merged, removing the STH from the get-entries response.

I am opposed to this change.  The STH was added to the get-entries
response to address skew between log frontends, a problem that arises
today with RFC6962 deployments.  Regularly, the Google CT logs will
advertise a particular STH to my monitor. but fail to return entries
all the way to that STH because the get-entries request is serviced by
a different frontend which is lagging behind.  When this happens, my
monitor cannot authenticate the entries it just received, so it has to
discard all of them and download them again later.  This is a waste of
bandwidth and slows down my monitor.  Returning the latest STH with the
get-entries response would allow my monitor to authenticate the entries
and make forward progress.

If the STH is removed from the get-entries response, this problem needs
to be addressed a different way, such as by forbidding logs from
exhibiting skew.  I suspect that the Google log operators wouldn't
like that.

The same argument applies to the removal of the STH from the
get-sth-consistency response
which I also oppose.

What is the plan for the remaining PRs?  If folks have comments, should
we be sending them to the list now?