Re: [Trans] draft-linus-trans-gossip-ct-01 doesn't work

Tom Ritter <tom@ritter.vg> Thu, 26 March 2015 16:06 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7851A6FF9 for <trans@ietfa.amsl.com>; Thu, 26 Mar 2015 09:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 KYqRsO3YXhvD for <trans@ietfa.amsl.com>; Thu, 26 Mar 2015 09:06:43 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 091451A87A3 for <trans@ietf.org>; Thu, 26 Mar 2015 09:06:41 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so57568417igb.1 for <trans@ietf.org>; Thu, 26 Mar 2015 09:06:40 -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:content-type; bh=kWLySJmhjcu8VTe9NSlmWhmAfzhODpn4cLblkUWA3p0=; b=AnhiQyIkaqf65k6TQzbTeblCMWzGexawex4TNNjkeqYX6Zj/Of3uSw40tJgKRhJwrx l79JcfkHeuX4acSH7HnN7GPTqWHuVYWiD0boYwEibSSiKijT9nhKZHBtmfo+JfcUqIRN A2sedkteLbHpmQUVO2o2OairjqYz53GcLFNQQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kWLySJmhjcu8VTe9NSlmWhmAfzhODpn4cLblkUWA3p0=; b=iHOCWT3xRKMFMA/5RXODoAgv2mo/WAEOt331rZsEYF8c6bO3MIdIkE15rxzcebF6xq mQGmZEHhK38SJk0Phm14f4vHbTR2CEUBBhVQLf1AKoPQvwNKBVmBn5WzmN7eoIC+fCiy LnYVOxwk52YHQDtdvYmy71jqyONqVwet5wPh9SfMBJ0qh8/DSZEeVlna7ZavnnCJtS1q ZlZcPUcng9YJMVQ/72osNIJLNmCCCF1QOvlZ3R67X8AMqYahQq8Q55aE/fAYNervOK4Q sq/7cUG5qgdTy83LmZfyA0sjE1xEH/rguLGakSAE1/0Nofapni65n+SJYXix+O2U6gav MQKQ==
X-Gm-Message-State: ALoCoQl4lkwJ4U/TDXyRqB/S9/zJmuhAujXHZhBFVNgsBr/DvRFj/YHC4SsqQpklI6uw1BQn9mro
X-Received: by 10.107.168.3 with SMTP id r3mr22077422ioe.47.1427386000513; Thu, 26 Mar 2015 09:06:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.166.84 with HTTP; Thu, 26 Mar 2015 09:06:20 -0700 (PDT)
In-Reply-To: <CACsn0c=5ZAUbamYkrMfawMxuk-1vpuydHT0jwaw+TR9cvOQd6w@mail.gmail.com>
References: <CACsn0c=5ZAUbamYkrMfawMxuk-1vpuydHT0jwaw+TR9cvOQd6w@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 26 Mar 2015 11:06:20 -0500
Message-ID: <CA+cU71kKG1203p4mw0YKuwN_pp3OuXw=01+fsyZEJubQ4iL9iQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/26mkwzdU5Hr6Raha2S_D1zHcqW8>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] draft-linus-trans-gossip-ct-01 doesn't work
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 26 Mar 2015 16:06:45 -0000

On 26 March 2015 at 09:56, Watson Ladd <watsonbladd@gmail.com> wrote:
> Dear all,
>
> Suppose I can consistently redirect a client C to a masquerading
> server M. The proposed gossip mechanism will not detect this, as SCTs
> are only ever sent back to the server they are received from. This
> should be fixed by having clients gossip constantly about STHs, thus
> ensuring that if any honest server is contacted, the MITM is detected.

If you are able to isolate a client from a resource _forever_ then
yes, you can win. You can also stop the client from receiving browser
updates, from contacting a client's trusted auditor (if they have
one), from receiving operating system updates, trust root updates, and
so on.

An attacker who can isolate a client from a resource once and forever
is exceptionally difficult to defend against.  It's not clear (to me
at least) what a browser could even do in that situation except refuse
to work at all.  (And I'll note that unless I'm mistaken, every
browser chooses to go the other way and actually fail _open_, removing
security mechanisms if it's been unable to update for a long time.)

-tom