Re: [Trans] Write-up of the "Strict CT" variant

Tom Ritter <tom@ritter.vg> Thu, 25 May 2017 14:46 UTC

Return-Path: <tom@ritter.vg>
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 46250129AD7 for <trans@ietfa.amsl.com>; Thu, 25 May 2017 07:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
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 Eo0EJIw0DRoO for <trans@ietfa.amsl.com>; Thu, 25 May 2017 07:46:13 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 EDAF71294F7 for <trans@ietf.org>; Thu, 25 May 2017 07:46:12 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id k74so179073416qke.1 for <trans@ietf.org>; Thu, 25 May 2017 07:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1MPP0XnhGtHSA34KZCp9ILRE2A0osry4QNdd38waf9E=; b=h4AfEYiptDqSRPnE9xKRtXAta7Npry/ROdcwotai2HL0CG77Tx+ZttzZNThJXHNCKI ysoBOlVcSW3iot7VLb8kvy0E7V7h+fAPGKkQUWnxB6RhqP9ZawLjgBCH1e3Y/eR3rtGQ DtqmEgAbbcZT6287oK7yYSurQB1pmK42U5OiI=
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=1MPP0XnhGtHSA34KZCp9ILRE2A0osry4QNdd38waf9E=; b=uII3MEhXUyhHAg6DhzPcSM8k823lqpQFwGzXKx501a2b/4oOwCkyCJ4HsNiHda2Jne 7144yH9nRdMUFxc/Fhc6vKaIj2jozrgUYo/thHBfWVrQWqKjU1e9WItDjbZeGZC8ln4k BdabtoaG9YQNPERv5CUepSdvgqXz1WQRZONDc/QOl4/N7g1qBfgFMnZ/AaAj28o1GfUn n8ucMBLZFn34SgJLXd6Ug/R79UWn/xGnbN9ffFKVFDCfTydoyDEjCPMPPG/FyHqpyFjX BP18+dCQbOVNlIMiQRKjSwZ3XkoLkHKCLHcLKrhunvvPjNbG849lyK9uXHqtlcat2q7e XPeA==
X-Gm-Message-State: AODbwcAYWu4ZfxiFRxFNmXFqzDXAZjsT9MXwqf9PQsgwGtWq9f3yM6kF ysoAX6ovyYNTUPfqwGEBbzqT4WDi9mP3
X-Received: by 10.233.216.194 with SMTP id u185mr38843563qkf.105.1495723571973; Thu, 25 May 2017 07:46:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.101.148 with HTTP; Thu, 25 May 2017 07:45:51 -0700 (PDT)
In-Reply-To: <3FECD8A3-4B3E-471D-9F2D-3524A87694B6@kth.se>
References: <CALzYgEeUCmj4BgY7uKdMnsvTcbvfAunquuqHxD7FxuzZxY1=Fg@mail.gmail.com> <3FECD8A3-4B3E-471D-9F2D-3524A87694B6@kth.se>
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 25 May 2017 09:45:51 -0500
Message-ID: <CA+cU71nkyX6QhjnLOBfwZFOR4eBeztuuPMU08FhFVYcZ6sv_=Q@mail.gmail.com>
To: Magnus Ahltorp <map@kth.se>
Cc: Eran Messeri <eranm@google.com>, "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/xvrK76SEtW4uelZYBJDzhM4ASlc>
Subject: Re: [Trans] Write-up of the "Strict CT" variant
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, 25 May 2017 14:46:14 -0000

On 25 May 2017 at 06:01, Magnus Ahltorp <map@kth.se> wrote:
>
> I may have misunderstood something, but why would the STH not always be included with the inclusion proof? What is the reason for all this extra complexity (UA vendor distributing the STH, inclusion proof not self-contained)?

The inclusion proof does contain the STH.  But we don't trust it. It
might represent a split view of the log.  There's no way to know
without comparing our view of the log with other people's.  By having
the UA vendor provide it's view of the log (or rather, a specific
subset of it in the form of specific STHs), we can confirm that this
STH we got is in the known set of STHs the UA vendor got. Our view is
the same as theirs. And since theirs is the same sent to every browser
client, we can be pretty sure that we and everyone - who uses this
browser at least - has the same view of the log and we are not being
presented a split view.

-tom