From nobody Mon Aug 3 11:00:16 2015 Return-Path: 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 1FB381B2D64 for ; Mon, 3 Aug 2015 11:00:14 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 3hoZOXMQTmyG for ; Mon, 3 Aug 2015 11:00:12 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 430DD1B2D71 for ; Mon, 3 Aug 2015 11:00:12 -0700 (PDT) Received: by pasy3 with SMTP id y3so19716014pas.2 for ; Mon, 03 Aug 2015 11:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=p6kz3lhtyEzZVTuOzQx0GHm5lmhvpkHPdrM58L322A8=; b=Qww9xD8LpBqu72NAyeqXb61cF3S3oYxabbr0q8ihipsQ2ucQh0PNkyZPMgQquOlOE1 9JbL/BwoG3adqowcaRGqqLCpMRZFswocQnqs8+G27hH1/P0BaY3SGDJ+LijwNteOt4ww wPR+KUoDOCV9n2i0AjAiu5P3Rp2fzqb13NcAxk2AnjtJXVqm44RoPrak1FSs9E3Z4yzb 2e6SVzgv5XkjvWiIV/wp27GvVCK2xWOvTEvWIpymJa+j163P1lpfVsciSpMWVref2jGm TUb6ozqYbN19uXq9c5Mb1m8LL1Q+vWevVSMva4uuWL9htaTTGSsnS2+icYMn9aGuznlq mDjA== X-Received: by 10.66.122.4 with SMTP id lo4mr38059648pab.1.1438624811920; Mon, 03 Aug 2015 11:00:11 -0700 (PDT) Received: from spandex.local (209-193-46-184-radius.dynamic.acsalaska.net. [209.193.46.184]) by smtp.gmail.com with ESMTPSA id l2sm8857062pdd.65.2015.08.03.11.00.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 11:00:11 -0700 (PDT) Message-ID: <55BFAC29.9010109@gmail.com> Date: Mon, 03 Aug 2015 10:00:09 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <55B0D80C.1060600@gmail.com> In-Reply-To: <55B0D80C.1060600@gmail.com> X-Forwarded-Message-Id: <55B0D80C.1060600@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Fwd: Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:00:14 -0000 Reminder. Please read the document and weigh in on whether or not you feel it's within scope and provides a good starting point for a working group deliverable. Melinda -------- Forwarded Message -------- Subject: Call for adoption, draft-linus-trans-gossip-ct Date: Thu, 23 Jul 2015 04:03:24 -0800 From: Melinda Shore To: trans@ietf.org Hi, all: This is a call for adoption of http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ as a working group deliverable. The call closes on August 6. Thanks, Melinda & Paul From nobody Mon Aug 3 11:03:07 2015 Return-Path: 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 407791B2D9C for ; Mon, 3 Aug 2015 11:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 y1510C1mXHYI for ; Mon, 3 Aug 2015 11:03:01 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A29A51B2D97 for ; Mon, 3 Aug 2015 11:03:01 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B8DEA74001A; Mon, 3 Aug 2015 18:03:00 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A129F740018; Mon, 3 Aug 2015 18:03:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1438624980; bh=DpZdq7TsQGzGobFCmiOhVS+ny1+tJ1B071+vxHM4jE8=; l=195; h=From:To:Date:References:In-Reply-To:From; b=sjwouxsPpiVzELP8hfmZNc0/pU8DKrTlKKCrPdlFGV6lmxElShT/JJext8Id8I65w MSkenhoGRxLSEjFinr2PppY5w+t505zHTNnCIGZ7n28PYg/tpwtUNBicyWuDYK8IUo oUJowzV50kzZa6v6tZCg3TsRala2sciOOnzEOiP0= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 969159808E; Mon, 3 Aug 2015 18:03:00 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 3 Aug 2015 13:03:00 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 3 Aug 2015 13:02:59 -0500 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Fwd: Call for adoption, draft-linus-trans-gossip-ct Thread-Index: AQHQzhZDimL7y0Dr+kKVYp5Acm7Jsp36kQhg Date: Mon, 3 Aug 2015 18:02:59 +0000 Message-ID: <3f1ed2de6854469d927206ec629a1843@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55B0D80C.1060600@gmail.com> <55BFAC29.9010109@gmail.com> In-Reply-To: <55BFAC29.9010109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Fwd: Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:03:04 -0000 =20 > Reminder. Please read the document and weigh in on whether or not you > feel it's within scope and provides a good starting point for a working g= roup > deliverable. Yes. Adopt. From nobody Mon Aug 3 12:25:35 2015 Return-Path: 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 53E711A1B87 for ; Mon, 3 Aug 2015 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8Z6WlgdF5Ih1 for ; Mon, 3 Aug 2015 12:25:30 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 4304B1A1B1F for ; Mon, 3 Aug 2015 12:25:30 -0700 (PDT) Received: by lbbpo9 with SMTP id po9so9436656lbb.2 for ; Mon, 03 Aug 2015 12:25:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aOI9PjdAGPOnzYoG3ABPsFuWpH6x3NRX4ydd1bb6QhI=; b=fmmvtWhJymwE5LDr1XS/pISJ9Eu4mI9XpNROeLvaf1ZmgJSq/hY9z5Agl/ZylJnWGE LpaR7QPBeBFde/XMx10MgDmNYjjCc3GaJuabRqQ/iiix3EKAffxnnUckVQa4kEQ0uMo2 LPJU1u/fSsDMHI5VIKKahPEJvJt94v3WUQlnYcavlsvTyv6NezYpewFuk5+PEYmTu8Xq tRGcQgkufYTxz+lb3apSfTch98tvORaetjLtp/Xlw5Mw10dkQWoGpXdG+6ISfVr1IJbh b4wKtsikEJNSqTAV89BLrfZ2rtcTyjR14D90i1eZpuoHzCEUhYSevo3XUUUNr2SaE7Ng PjFQ== X-Gm-Message-State: ALoCoQlvxc5LK4PWeKTn4LCMRrZ1Nq0HcAlt3+puIKK53R/auYUaj1od39/pH/yhTL4tokXUruVg X-Received: by 10.152.23.38 with SMTP id j6mr18148851laf.47.1438629928704; Mon, 03 Aug 2015 12:25:28 -0700 (PDT) Received: from [10.0.0.120] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.googlemail.com with ESMTPSA id k9sm3186313lbp.13.2015.08.03.12.25.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 12:25:28 -0700 (PDT) Message-ID: <55BFC027.3050109@mnt.se> Date: Mon, 03 Aug 2015 21:25:27 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: trans@ietf.org References: <55B0D80C.1060600@gmail.com> <55BFAC29.9010109@gmail.com> In-Reply-To: <55BFAC29.9010109@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:25:33 -0000 On 2015-08-03 20:00, Melinda Shore wrote: > Reminder. Please read the document and weigh in on whether or > not you feel it's within scope and provides a good starting point > for a working group deliverable. > > Melinda > > > -------- Forwarded Message -------- > Subject: Call for adoption, draft-linus-trans-gossip-ct > Date: Thu, 23 Jul 2015 04:03:24 -0800 > From: Melinda Shore > To: trans@ietf.org > > Hi, all: > > This is a call for adoption of > http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > as a working group deliverable. The call closes on August 6. > > Thanks, > > Melinda & Paul > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > support adoption From nobody Mon Aug 3 12:41:13 2015 Return-Path: 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 0E60E1ACD54 for ; Mon, 3 Aug 2015 12:41:11 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 uEQIKl2wD4em for ; Mon, 3 Aug 2015 12:41:09 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 93F521AC40D for ; Mon, 3 Aug 2015 12:41:09 -0700 (PDT) Received: by pawu10 with SMTP id u10so19656715paw.1 for ; Mon, 03 Aug 2015 12:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=DBirLIUUhHZrsLnteszl6j2lLSHjYYdy3NZTMzwsYcM=; b=LYXlNuhMFE/+69/lOieMwsWjXScccHa+IvR8hY1LvKFwgUxnMgPnxiQEXFTqetDN2y +/s7R+W9o+yIgCE4zZFBgs7AIdi4GhvnWwQUnoyX+jojT7tw136f9qL4z60qfsbjo6/c wKUbEAtjbIqLcoZU6SpHokW5TjBWKCecJhs4vSl62eGRBxQhiXvovwfqT5tZrlAlCXah A9kW46Tqr0GD++zpXbxS8Bobp7bbG4SV5AwxddG7/mCGVWL2aRLiFBoKpth7X627fkhR cWHKiUtcMdfl8UNIwoSnbepSUkg5S1iJ20K1iQsa1uLgjHK4LK1gsXTvySjJ51pHyj0F uYsQ== X-Received: by 10.68.174.35 with SMTP id bp3mr26994231pbc.124.1438630869212; Mon, 03 Aug 2015 12:41:09 -0700 (PDT) Received: from twicinski-ltm.internal.salesforce.com ([204.14.236.215]) by smtp.googlemail.com with ESMTPSA id ms16sm8773084pbc.11.2015.08.03.12.41.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 12:41:08 -0700 (PDT) To: trans@ietf.org References: <55B0D80C.1060600@gmail.com> <55BFAC29.9010109@gmail.com> From: Tim Wicinski Message-ID: <55BFC3D9.1010305@gmail.com> Date: Mon, 3 Aug 2015 15:41:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55BFAC29.9010109@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:41:11 -0000 I've read this and I support adoption by the working group. tim On 8/3/15 2:00 PM, Melinda Shore wrote: > Reminder. Please read the document and weigh in on whether or > not you feel it's within scope and provides a good starting point > for a working group deliverable. > > Melinda > > > -------- Forwarded Message -------- > Subject: Call for adoption, draft-linus-trans-gossip-ct > Date: Thu, 23 Jul 2015 04:03:24 -0800 > From: Melinda Shore > To: trans@ietf.org > > Hi, all: > > This is a call for adoption of > http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > as a working group deliverable. The call closes on August 6. > > Thanks, > > Melinda & Paul > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Wed Aug 5 13:57:11 2015 Return-Path: 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 C3A0F1A916C for ; Wed, 5 Aug 2015 13:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 S-HHDnrultMl for ; Wed, 5 Aug 2015 13:57:08 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 277E31A8982 for ; Wed, 5 Aug 2015 13:57:08 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D83DAF984; Wed, 5 Aug 2015 16:57:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8114E2005D; Wed, 5 Aug 2015 22:56:56 +0200 (CEST) From: Daniel Kahn Gillmor To: Ben Laurie , "Salz\, Rich" , "trans\@ietf.org" In-Reply-To: References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 16:56:56 -0400 Message-ID: <87fv3xzc6f.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Trans] TRANS Draft minutes for IETF-93 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 20:57:10 -0000 On Fri 2015-07-24 07:28:53 -0400, Ben Laurie wrote: > On Thu, 23 Jul 2015 at 20:59 Salz, Rich wrote: >> Steve raised issue of exposing what certs a client is interested in if >> size of get-entries can shrink to one, for example. > > My response was omitted: this doesn't matter so long as the client > continues to request entries until it has all the ones it originally > decided to fetch. as a concrete example, if a client says "give me entries from 1000 to 2000" while knowing it actually only wants entry 1223, and the server dribbles them back one at a time instead of 1000 at a time, then the client which stops at 1223 has effectively lost privacy. If the client continues with the next 777 fetches anyway, then it should be identical privacy-wise to the initial request (albeit at a likely higher expense in terms of latency and network traffic) --dkg From nobody Thu Aug 6 02:17:28 2015 Return-Path: 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 182CE1B2AF8 for ; Thu, 6 Aug 2015 02:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 Dol8CjcUWXYS for ; Thu, 6 Aug 2015 02:17:23 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 EFAC31B2AD7 for ; Thu, 6 Aug 2015 02:17:22 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so15211937wib.1 for ; Thu, 06 Aug 2015 02:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3P4enBGAkUbhRxbodGYuf8fz7ndmQ4umevC31+sKWdU=; b=cenjaI1PQ9YDxGaRM8uAoQ4RSLsQCzQAMgZ6Ngjcj6ePm+n/h5nmzxsqRGWMBIildz aaROv5Cf7yFck6Jghy7lkTuqVuKN/ELkQUkhn2IgV9LmxGhOMmNqUfOBd5lLe+Rzfb1u BHmiXZtyqj7qASCJK24ZUCFajpaiaqlzMshX34ph4KOnrpayi26LrxBrWtG0Qww6bPZH +yClk2PKJ9Ed+z+uc/GhYsk0xsFuKTKwjsCr2LONT1sc2nPoJ/cP8xJIb42oqluCLMsN Mso8y3IPRD3ZU5W3ZuFdPNZky4W/QImjex5blwQZvsCgRdhuM7saU2xOYV5BSzBDaN58 IJ3w== X-Received: by 10.180.39.163 with SMTP id q3mr4622047wik.82.1438852641659; Thu, 06 Aug 2015 02:17:21 -0700 (PDT) Received: from [10.247.119.93] (46-253-189-212.dynamic.monzoon.net. [46.253.189.212]) by smtp.gmail.com with ESMTPSA id i6sm8417167wje.33.2015.08.06.02.17.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Aug 2015 02:17:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_08BE9343-57F4-4ECD-A8D1-986A01F6EE16"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Bryan Ford In-Reply-To: Date: Thu, 6 Aug 2015 11:17:19 +0200 Message-Id: <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> To: Ben Laurie X-Mailer: Apple Mail (2.2102) Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:17:27 -0000 --Apple-Mail=_08BE9343-57F4-4ECD-A8D1-986A01F6EE16 Content-Type: multipart/alternative; boundary="Apple-Mail=_185D3EC6-7E47-4BC8-99BC-E17906AAE8F5" --Apple-Mail=_185D3EC6-7E47-4BC8-99BC-E17906AAE8F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the slow followup, I wasn=E2=80=99t able to keep up with the = lists since the IETF meeting... > On Jul 24, 2015, at 1:09 PM, Ben Laurie wrote: > On Thu, 23 Jul 2015 at 23:27 Bryan Ford > wrote: >> From: Melinda Shore > >> Subject: [Trans] Call for adoption, draft-linus-trans-gossip-ct >> Date: July 23, 2015 at 2:03:24 PM GMT+2 >> To: "trans@ietf.org " > >=20 >>=20 >> Hi, all: >>=20 >> This is a call for adoption of >> http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ = >> as a working group deliverable. The call closes on August 6. >=20 >=20 > While the draft represents a fine start at defining a gossip = mechanism, I would like to express serious reservations about the = draft=E2=80=99s basic premise that a gossip mechanism is the best = approach - or even an adequate approach - =E2=80=9Cto detect misbehavior = by CT logs=E2=80=9D, to quote the draft=E2=80=99s self-stated purpose. = As such, I have serious reservations about the WG adopting the draft, = not because there=E2=80=99s anything wrong with the content of the draft = per se but because gossip is simply not the right approach. >=20 > First, the gossip approach creates severe privacy problems, which are = already well-discussed so I won=E2=80=99t reiterate them. >=20 > Actually, I think you need to reiterate them, since we think that = gossip as proposed does _not_ create privacy problems. It creates new privacy problems by requiring the client (browser user) = to =E2=80=9Copt out=E2=80=9D of web browsing privacy in order to gain = any security benefit. Either the user hands over all his browsing = history to a remote =E2=80=9Ctrusted auditor=E2=80=9D, thereby opting = out of privacy; or else the user remains fully vulnerable to the same = kind of (potentially extended) MITM attacks that motivated CT in the = first place. =20 > Second, the gossip approach can=E2=80=99t ensure that = privacy-sensitive Web clients (who can=E2=80=99t or don=E2=80=99t want = to reveal their whole browsing history to a Trusted Auditor) will ever = actually be able =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, if = for example the misbehaving log=E2=80=99s private key is controlled by a = MITM attacker between the Web client and the website the client thinks = he is visiting. >=20 > The intent of CT is not to enable clients to detect such behaviour - = rather, it is to enable the system as a whole to detect it. Could you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects = such misbehavior in the case of the state/ISP-level MITM attacker = scenario? =20 As I see it, if the client/browser doesn=E2=80=99t opt-out of privacy by = gossiping his browsing history with a trusted auditor, then the = client=E2=80=99s *only* connection to the rest of the world, i.e., = =E2=80=9Cthe system as a whole=E2=80=9D, is through the =E2=80=9Cweb = server=E2=80=9D, which may well be the same kind of MITM attackers that = have been known to subvert the CA system. The client never gets to = communicate to the rest of the system - i.e., the legitimate CT log = servers, auditors, or monitors - and so the client never gets the = opportunity to =E2=80=9Ccompare notes=E2=80=9D with the rest of the = system. And the rest of the system (the legitimate log servers, = auditors, and monitors) never have the opportunity to learn from the = client that the client saw a MITM-attacked, forged set of CA certs, = STHs, and SCTs. > Suppose, for example, it ever so happens that a single company ends up = running both a log server and a [sub-]CA, and keeps both in the same = poorly-protected safe. If an attacker can steal those two private keys, = then the attacker can silently MITM any CT-aware client all it wants, by = producing all the [non-EV] certificates it needs with a valid SCT, valid = STH inclusion proofs in a fake log, etc. >=20 > Chrome's policy would require the subversion of at least two logs to = achieve this, but for the sake of argument, I'll concede that. I thought you were requiring CAs to have multiple SCTs only for EV = certificates, no? What if the attacker is happy to MITM attack the user = with a non-EV certificate and forego showing the user the =E2=80=9Cgreen = bar=E2=80=9D? Are you assuming that users will stop using the = connection if they don=E2=80=99t see the green bar? Or are you saying (contrary to my prior understanding) that Chrome = requires *all* CT certs to have multiple SCTs signed by different log = servers? =20 > The web client isn=E2=80=99t going to learn about the problem via = gossip with the website because that=E2=80=99s the MITM attacker, and = the client can=E2=80=99t gossip with anyone else without the serious = privacy risk of trusting a single audit server with his entire browsing = history. If the =E2=80=9Ctrusted audit server=E2=80=9D is actually = co-located with the client, then the audit server in turn can=E2=80=99t = gossip with the rest of the world without creating the same privacy = risk. Even if the client does voluntarily gossip with a remote trusted = audit server, the MITM attacker - e.g., an ISP-level or state-level = attacker - might simply block connections to all well-known audit = servers. >=20 > This attack relies on a MitM that is sustained forever but indeed = would succeed. We accept that CT cannot defeat such an attack.=20 But isn=E2=80=99t that precisely what happened in the prior COMODO and = DigiNotar cases, where the MITM attacks were detected only when a few = more security-conscious users compared the certificates they were seeing = against what the rest of the world was seeing through nonstandard = =E2=80=9Cside-channels=E2=80=9D? Isn=E2=80=99t that=20 > I posted an E-mail last week suggesting an alternative approach, in = which log servers would not individually sign their STHs but instead = collectively sign them with the active participation of (a suitable = quorum of) the auditors and/or monitors watching their logs. But I got = no response to that, so I=E2=80=99d like to try again. >=20 > In short: the log server would propose log entries, but the auditors = and/or monitors contribute to the STH signature, only after performing = at least the =E2=80=9Cauditing=E2=80=9D function of verifying that the = log server is behaving like a correct log server. In particular, all = participants could proactively verify that the log server never forks or = reverts the log, never signs something syntactically invalid or with a = wildly-incorrect timestamp (say +/- 24 hours), etc. Then, even if the = log server=E2=80=99s private key was successfully stolen by a = state-level attacker (and the attacker perhaps even compromises a = minority of the monitor/auditor keys), the attacker will be unable to = forge an STH signature that a Web client or anyone else will believe. >=20 > This would, in effect, convert each log server from yet another juicy = central attack target into a strongest-link set (I like to use the term = =E2=80=9Ccothority=E2=80=9D or collective authority) with all the = monitor and auditor servers watching it and contributing to its = signatures. Of course, the attacker still wins if he successfully = compromises any single CA (or sub-CA) *and* any single =E2=80=9Clogging = cothority=E2=80=9D (i.e., any log server *and* a sufficient quorum of = its followers). But doing the latter becomes way, way harder if = there=E2=80=99s enough size and diversity in each logging cothority. >=20 > How does this improve things for the Web client in Repressistan who's = getting MITM attacked? If the client is only looking at SCTs that are = individually signed by a log server (and are in any case only a = =E2=80=9Cpromise to log soon=E2=80=9D and not actual evidence that the = cert has been logged), then unfortunately not much: the MITM attacker = can still forge at least one SCT for each of its forged certs, and no = one else learns because the MITM can keep the client=E2=80=99s view = isolated from the rest of the world. >=20 > But say we enhance CT so clients can demand STHs *with* cert inclusion = proofs from the web servers they talk to - as I suggested in the meeting = today, and which I believe Ben Laurie mentioned is already in the works. = Then any Web client that does this will be proactively protected from = MITM attacks involving faked, forked, or otherwise bad log entries. And = the client doesn=E2=80=99t have to compromise its privacy by gossiping = with anyone. >=20 > Two points here: >=20 > 1. Is this any different to requiring n SCTs from different logs for = each certificate (other than the inclusion proof part, which I address = below)? Semantically, no different, but how large many SCTs do you think is = practical to require to be attached to each cert? Two, three? Ten? A = hundred? How big is each SCT? =20 With the multi-SCT approach, the amount of bandwidth consumed during TLS = negotiation with every CT-supporting website increases linearly with n. = With the scalable multisignature approach, n can increase to arbitrarily = large size - a hundred, a thousand if needed - e.g., including all the = public auditors, monitors, etc. - without any increase in the size of = certificates, number of SCTs attached, or ultimately the = bandwidth/latency overhead during TLS negotiation. > 2. Our original design for CT did indeed have certs served along with = an STH and an inclusion proof. Unfortunately, CAs categorically rejected = this approach because of the latency it introduced in the certificate = issuance process. Personally, I think it would be a better approach. Now = CAs are more accepting of CT, perhaps it would be worth revisiting the = question with them? Agreed, that would be great. Bryan > =20 >=20 > Bryan > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans = --Apple-Mail=_185D3EC6-7E47-4BC8-99BC-E17906AAE8F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry for the slow followup, I wasn=E2=80=99t able to keep up = with the lists since the IETF meeting...

On = Jul 24, 2015, at 1:09 PM, Ben Laurie <benl@google.com> = wrote:
On Thu, 23 Jul 2015 at = 23:27 Bryan Ford <brynosaurus@gmail.com> wrote:
From: Melinda Shore <melinda.shore@gmail.com>
Subject: [Trans] Call for adoption, = draft-linus-trans-gossip-ct
Date: July 23, 2015 at 2:03:24 PM GMT+2
To: "trans@ietf.org" <trans@ietf.org>

Hi, all:

This is a call for adoption of
http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/
as a working group deliverable.  The call closes on = August 6.

While the draft = represents a fine start at defining a gossip mechanism, I would like to = express serious reservations about the draft=E2=80=99s basic premise = that a gossip mechanism is the best approach - or even an adequate = approach - =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, to quote = the draft=E2=80=99s self-stated purpose.  As such, I have serious = reservations about the WG adopting the draft, not because there=E2=80=99s = anything wrong with the content of the draft per se but because gossip = is simply not the right approach.

First, the gossip approach creates = severe privacy problems, which are already well-discussed so I won=E2=80=99= t reiterate them.

Actually, I think you need to reiterate = them, since we think that gossip as proposed does _not_ create privacy = problems.



As I see it, if the client/browser doesn=E2=80=99t = opt-out of privacy by gossiping his browsing history with a trusted = auditor, then the client=E2=80=99s *only* connection to the rest of the = world, i.e., =E2=80=9Cthe system as a whole=E2=80=9D, is through the = =E2=80=9Cweb server=E2=80=9D, which may well be the same kind of MITM = attackers that have been known to subvert the CA system.  The = client never gets to communicate to the rest of the system - i.e., the = legitimate CT log servers, auditors, or monitors - and so the client = never gets the opportunity to =E2=80=9Ccompare notes=E2=80=9D with the = rest of the system.  And the rest of the system (the legitimate log = servers, auditors, and monitors) never have the opportunity to learn = from the client that the client saw a MITM-attacked, forged set of CA = certs, STHs, and SCTs.

Suppose, for example, it ever so happens that = a single company ends up running both a log server and a [sub-]CA, and = keeps both in the same poorly-protected safe.  If an attacker can = steal those two private keys, then the attacker can silently MITM any = CT-aware client all it wants, by producing all the [non-EV] certificates = it needs with a valid SCT, valid STH inclusion proofs in a fake log, = etc.

Chrome's policy would require the = subversion of at least two logs to achieve this, but for the sake of = argument, I'll concede that.

I thought you were requiring CAs to have multiple = SCTs only for EV certificates, no?  What if the attacker is happy = to MITM attack the user with a non-EV certificate and forego showing the = user the =E2=80=9Cgreen bar=E2=80=9D?  Are you assuming that users = will stop using the connection if they don=E2=80=99t see the green = bar?

Or are you saying (contrary to = my prior understanding) that Chrome requires *all* CT certs to have = multiple SCTs signed by different log = servers?
 
 The web client isn=E2=80=99t going to = learn about the problem via gossip with the website because that=E2=80=99s= the MITM attacker, and the client can=E2=80=99t gossip with anyone else = without the serious privacy risk of trusting a single audit server with = his entire browsing history.  If the =E2=80=9Ctrusted audit = server=E2=80=9D is actually co-located with the client, then the audit = server in turn can=E2=80=99t gossip with the rest of the world without = creating the same privacy risk.  Even if the client does = voluntarily gossip with a remote trusted audit server, the MITM attacker = - e.g., an ISP-level or state-level attacker - might simply block = connections to all well-known audit = servers.

This attack relies on a MitM that is = sustained forever but indeed would succeed. We accept that CT cannot = defeat such an attack. 

But isn=E2=80=99t that precisely what happened in = the prior COMODO and DigiNotar cases, where the MITM attacks were = detected only when a few more security-conscious users compared the = certificates they were seeing against what the rest of the world was = seeing through nonstandard =E2=80=9Cside-channels=E2=80=9D? =  Isn=E2=80=99t that 

I posted an E-mail last week suggesting an alternative = approach, in which log servers would not individually sign their STHs = but instead collectively sign them with the active participation of (a = suitable quorum of) the auditors and/or monitors watching their = logs.  But I got no response to that, so I=E2=80=99d like to try = again.

In = short: the log server would propose log entries, but the auditors and/or = monitors contribute to the STH signature, only after performing at least = the =E2=80=9Cauditing=E2=80=9D function of verifying that the log server = is behaving like a correct log server.  In particular, all = participants could proactively verify that the log server never forks or = reverts the log, never signs something syntactically invalid or with a = wildly-incorrect timestamp (say +/- 24 hours), etc.  Then, even if = the log server=E2=80=99s private key was successfully stolen by a = state-level attacker (and the attacker perhaps even compromises a = minority of the monitor/auditor keys), the attacker will be unable to = forge an STH signature that a Web client or anyone else will = believe.

This = would, in effect, convert each log server from yet another juicy central = attack target into a strongest-link set (I like to use the term = =E2=80=9Ccothority=E2=80=9D or collective authority) with all the = monitor and auditor servers watching it and contributing to its = signatures.  Of course, the attacker still wins if he successfully = compromises any single CA (or sub-CA) *and* any single =E2=80=9Clogging = cothority=E2=80=9D (i.e., any log server *and* a sufficient quorum of = its followers).  But doing the latter becomes way, way harder if = there=E2=80=99s enough size and diversity in each logging = cothority.

How = does this improve things for the Web client in Repressistan who's = getting MITM attacked?  If the client is only looking at SCTs that = are individually signed by a log server (and are in any case only a = =E2=80=9Cpromise to log soon=E2=80=9D and not actual evidence that the = cert has been logged), then unfortunately not much: the MITM attacker = can still forge at least one SCT for each of its forged certs, and no = one else learns because the MITM can keep the client=E2=80=99s view = isolated from the rest of the world.

But say we enhance CT so clients can = demand STHs *with* cert inclusion proofs from the web servers they talk = to - as I suggested in the meeting today, and which I believe Ben Laurie = mentioned is already in the works.  Then any Web client that does = this will be proactively protected from MITM attacks involving faked, = forked, or otherwise bad log entries.  And the client doesn=E2=80=99t= have to compromise its privacy by gossiping with = anyone.

Two points here:
1. Is this any different to requiring = n SCTs from different logs for each certificate (other than the = inclusion proof part, which I address = below)?

Semantically, no different, but how large many = SCTs do you think is practical to require to be attached to each cert? =  Two, three?  Ten?  A hundred?  How big is each SCT? =  

With the multi-SCT approach, = the amount of bandwidth consumed during TLS negotiation with every = CT-supporting website increases linearly with n.  With the scalable = multisignature approach, n can increase to arbitrarily large size - a = hundred, a thousand if needed - e.g., including all the public auditors, = monitors, etc. - without any increase in the size of certificates, = number of SCTs attached, or ultimately the bandwidth/latency overhead = during TLS negotiation.

2. Our original = design for CT did indeed have certs served along with an STH and an = inclusion proof. Unfortunately, CAs categorically rejected this approach = because of the latency it introduced in the certificate issuance = process. Personally, I think it would be a better approach. Now CAs are = more accepting of CT, perhaps it would be worth revisiting the question = with them?

Agreed, that would be great.

Bryan


= --Apple-Mail=_185D3EC6-7E47-4BC8-99BC-E17906AAE8F5-- --Apple-Mail=_08BE9343-57F4-4ECD-A8D1-986A01F6EE16 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA4MDYwOTE3MTlaMCMGCSqGSIb3DQEJBDEWBBT7EFyF/w8THZpHvaMofPox+8vIXjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAYBPQkkB7Hf5FDAcGzrL23MN1qJQk4G036KkKpMmW56Mo4yP5nDSP+qk/Ic0ShQPh N80ZX5UJ3xyMKO+LNIKo5HVjfHdVC8h9Khcbw0HjoPKmN4E5q4XX7xHuKomuypVNTu6ZzxaLAtZk 07KsJ2AKCF6Jrz77QPXpRARjLBCtGwfwPFDUv7GeAM/xIxmCQ/fzTeqcU5QswOKa8dkXC73Gf9yT M8jFu7dQFO81PjlEZHsHcrpHtCNYWND9pYRMkMmR9E87vBqHdF25CF0Zvo7PMUXAOERwiaatFZmf /p5+/P0NUi136WSF7p+g46sPAg0A9ycuhNYeSYS+I11lTx/apgAAAAAAAA== --Apple-Mail=_08BE9343-57F4-4ECD-A8D1-986A01F6EE16-- From nobody Thu Aug 6 05:56:52 2015 Return-Path: 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 D66C81B2ED2 for ; Thu, 6 Aug 2015 05:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wqBZtH8CqISs for ; Thu, 6 Aug 2015 05:56:44 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 8D43C1B2ED0 for ; Thu, 6 Aug 2015 05:56:44 -0700 (PDT) Received: by ykcq64 with SMTP id q64so56238768ykc.2 for ; Thu, 06 Aug 2015 05:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=dEMLfklHvobs9OQGnOm3Dz2jt8A2s8iVgoDCWo+7qPw=; b=GZtmV52HIbN5wH79xVH5KEqjqNM/6vKXsW4TNv7+880g1+rbK8r/N1lHWUcW+CveSq pPphUtZhRIDUgX2dyjemzxTsm69+bFkiyCwV6h/vKlo4x51fZtQGDCDhrVntrCGRHaKc ZxOTQjoSZeSW9v0bFPJAtw10FvHQq5J5Vw5Y4oMGA7d4+mAicyXCg7qQ3LVedZagB/T5 hBj+25YiwPCiOCVkbjzRrbZ4OfmDrSOiffFHzNNcYZSBN4835LY8hIN8euLE/sT2E7KD OMPdUUf6SRiivdFCGnrWaDY8O5FPxYnCUTu1d4isPJj+EG5ZqBTWCRHY8uRBaJhGKQQL 38og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=dEMLfklHvobs9OQGnOm3Dz2jt8A2s8iVgoDCWo+7qPw=; b=kA67PKNXINiQ5//e99UMgoEttcaYDurpiBNphOCjcYl5bmwvjJ0YVGY2oFb08fknoW V1oStINOwmSMMwr66h+WdU6+UbU9DjZNwyV7IJA+JhZ3euH+Frd6mX5922PVQ/9pLOp3 213UMm7PthFXskgIggaXBVfgZVqNJQjg6ydLVaN48jpa5IFzjNy/BQiWc0iSR6NtEeHB 4mEmKPOtcQSt9v/LaKXMEnkijoq3hFeM4HN8D9nNkLYLLUKdYOF32a1fgSpz9VullbOX lbwKYzi0tlCVdE2u9+Ws0oTMm6QVLlXAuAshyvHwERZ+ywkxE1qJJNOAg/dVElFD+42I HETw== X-Gm-Message-State: ALoCoQnLzD5dM5QGjMO/8SLeLqJHUAb11VnC7omUEUzVtZBSnpGkGqkCJz6NXZ5neOxAyVUr9gHs X-Received: by 10.129.51.14 with SMTP id z14mr1284514ywz.65.1438865803794; Thu, 06 Aug 2015 05:56:43 -0700 (PDT) MIME-Version: 1.0 References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> In-Reply-To: <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> From: Ben Laurie Date: Thu, 06 Aug 2015 12:56:34 +0000 Message-ID: To: Bryan Ford Content-Type: multipart/alternative; boundary=001a11407ce21d87ef051ca40da2 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 12:56:49 -0000 --001a11407ce21d87ef051ca40da2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 6 Aug 2015 at 10:17 Bryan Ford wrote: > Sorry for the slow followup, I wasn=E2=80=99t able to keep up with the li= sts since > the IETF meeting... > > On Jul 24, 2015, at 1:09 PM, Ben Laurie wrote: > On Thu, 23 Jul 2015 at 23:27 Bryan Ford wrote: > >> *From: *Melinda Shore >> *Subject: **[Trans] Call for adoption, draft-linus-trans-gossip-ct* >> *Date: *July 23, 2015 at 2:03:24 PM GMT+2 >> *To: *"trans@ietf.org" >> >> >> Hi, all: >> >> This is a call for adoption of >> http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ >> as a working group deliverable. The call closes on August 6. >> >> >> While the draft represents a fine start at defining a gossip mechanism, = I >> would like to express serious reservations about the draft=E2=80=99s bas= ic premise >> that a gossip mechanism is the best approach - or even an adequate appro= ach >> - =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, to quote the draft= =E2=80=99s self-stated >> purpose. As such, I have serious reservations about the WG adopting the >> draft, not because there=E2=80=99s anything wrong with the content of th= e draft per >> se but because gossip is simply not the right approach. >> >> First, the gossip approach creates severe privacy problems, which are >> already well-discussed so I won=E2=80=99t reiterate them. >> > > Actually, I think you need to reiterate them, since we think that gossip > as proposed does _not_ create privacy problems. > > > It creates new privacy problems by requiring the client (browser user) to > =E2=80=9Copt out=E2=80=9D of web browsing privacy in order to gain any se= curity benefit. > Either the user hands over all his browsing history to a remote =E2=80=9C= trusted > auditor=E2=80=9D, thereby opting out of privacy; or else the user remains= fully > vulnerable to the same kind of (potentially extended) MITM attacks that > motivated CT in the first place. > CT is not intended to directly prevent MitM attacks, it is intended to detect mis-issuance of certificates. It is true that if you can persistently isolate a client from the rest of the 'net, then you can defeat CT. However, I don't see why it makes any difference whether you talk to trusted auditors (not, AIUI, expected to be the default) or to the alleged origin server. The MITM can control both paths... > > > Second, the gossip approach can=E2=80=99t ensure that privacy-sensitive W= eb >> clients (who can=E2=80=99t or don=E2=80=99t want to reveal their whole b= rowsing history to >> a Trusted Auditor) will ever actually be able =E2=80=9Cto detect misbeha= vior by CT >> logs=E2=80=9D, if for example the misbehaving log=E2=80=99s private key = is controlled by a >> MITM attacker between the Web client and the website the client thinks h= e >> is visiting. >> > > The intent of CT is not to enable clients to detect such behaviour - > rather, it is to enable the system as a whole to detect it. > > > Could you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects suc= h misbehavior in > the case of the state/ISP-level MITM attacker scenario? > The state or ISP must isolate all clients they attack forever to avoid detection. In practice, this does not generally seem to be possible. > > As I see it, if the client/browser doesn=E2=80=99t opt-out of privacy by = gossiping > his browsing history with a trusted auditor, then the client=E2=80=99s *o= nly* > connection to the rest of the world, i.e., =E2=80=9Cthe > system as a whole=E2=80=9D, is through the =E2=80=9Cweb server=E2=80=9D, wh= ich may well be the same > kind of MITM attackers that have been known to subvert the CA system. Th= e > client never gets to communicate to the rest of the system - i.e., the > legitimate CT log servers, auditors, or monitors - and so the client neve= r > gets the opportunity to =E2=80=9Ccompare notes=E2=80=9D with the rest of = the system. And > the rest of the system (the legitimate log servers, auditors, and monitor= s) > never have the opportunity to learn from the client that the client saw a > MITM-attacked, forged set of CA certs, STHs, and SCTs. > This is correct, and seems to me to be correct for any system - if you can isolate your victim forever, you can show your own view of any system. > > Suppose, for example, it ever so happens that a single company ends up >> running both a log server and a [sub-]CA, and keeps both in the same >> poorly-protected safe. If an attacker can steal those two private keys, >> then the attacker can silently MITM any CT-aware client all it wants, by >> producing all the [non-EV] certificates it needs with a valid SCT, valid >> STH inclusion proofs in a fake log, etc. >> > > Chrome's policy would require the subversion of at least two logs to > achieve this, but for the sake of argument, I'll concede that. > > > I thought you were requiring CAs to have multiple SCTs only for EV > certificates, no? What if the attacker is happy to MITM attack the user > with a non-EV certificate and forego showing the user the =E2=80=9Cgreen = bar=E2=80=9D? Are > you assuming that users will stop using the connection if they don=E2=80= =99t see > the green bar? > Not at all. EV certificates are our first step for CT. > > Or are you saying (contrary to my prior understanding) that Chrome > requires *all* CT certs to have multiple SCTs signed by different log > servers? > Chrome makes no requirement on "CT certs", only on EV certs. But in the long run, the intention is to require CT for all certs. > > > The web client isn=E2=80=99t going to learn about the problem via gossip= with the >> website because that=E2=80=99s the MITM attacker, and the client can=E2= =80=99t gossip with >> anyone else without the serious privacy risk of trusting a single audit >> server with his entire browsing history. If the =E2=80=9Ctrusted audit = server=E2=80=9D is >> actually co-located with the client, then the audit server in turn can= =E2=80=99t >> gossip with the rest of the world without creating the same privacy risk= . >> Even if the client does voluntarily gossip with a remote trusted audit >> server, the MITM attacker - e.g., an ISP-level or state-level attacker - >> might simply block connections to all well-known audit servers. >> > > This attack relies on a MitM that is sustained forever but indeed would > succeed. We accept that CT cannot defeat such an attack. > > > But isn=E2=80=99t that precisely what happened in the prior COMODO and Di= giNotar > cases, where the MITM attacks were detected only when a few more > security-conscious users compared the certificates they were seeing again= st > what the rest of the world was seeing through nonstandard =E2=80=9Cside-c= hannels=E2=80=9D? > Comodo: I don't know, actually. DigiNotar: no - this was detected through pinning violations. Furthermore, the attacker would have had to do substantially more hacking to have managed to get something that even fooled the browser in the face of CT, and it still would've leaked. > Isn=E2=80=99t that > > I posted an E-mail last week suggesting an alternative approach, in which >> log servers would not individually sign their STHs but instead collectiv= ely >> sign them with the active participation of (a suitable quorum of) the >> auditors and/or monitors watching their logs. But I got no response to >> that, so I=E2=80=99d like to try again. >> >> In short: the log server would propose log entries, but the auditors >> and/or monitors contribute to the STH signature, only after performing a= t >> least the =E2=80=9Cauditing=E2=80=9D function of verifying that the log = server is behaving >> like a correct log server. In particular, all participants could >> proactively verify that the log server never forks or reverts the log, >> never signs something syntactically invalid or with a wildly-incorrect >> timestamp (say +/- 24 hours), etc. Then, even if the log server=E2=80= =99s private >> key was successfully stolen by a state-level attacker (and the attacker >> perhaps even compromises a minority of the monitor/auditor keys), the >> attacker will be unable to forge an STH signature that a Web client or >> anyone else will believe. >> >> This would, in effect, convert each log server from yet another juicy >> central attack target into a strongest-link set (I like to use the term >> =E2=80=9Ccothority=E2=80=9D or collective authority) with all the monito= r and auditor >> servers watching it and contributing to its signatures. Of course, the >> attacker still wins if he successfully compromises any single CA (or >> sub-CA) *and* any single =E2=80=9Clogging cothority=E2=80=9D (i.e., any = log server *and* a >> sufficient quorum of its followers). But doing the latter becomes way, = way >> harder if there=E2=80=99s enough size and diversity in each logging coth= ority. >> >> How does this improve things for the Web client in Repressistan who's >> getting MITM attacked? If the client is only looking at SCTs that are >> individually signed by a log server (and are in any case only a =E2=80= =9Cpromise to >> log soon=E2=80=9D and not actual evidence that the cert has been logged)= , then >> unfortunately not much: the MITM attacker can still forge at least one S= CT >> for each of its forged certs, and no one else learns because the MITM ca= n >> keep the client=E2=80=99s view isolated from the rest of the world. >> >> But say we enhance CT so clients can demand STHs *with* cert inclusion >> proofs from the web servers they talk to - as I suggested in the meeting >> today, and which I believe Ben Laurie mentioned is already in the works. >> Then any Web client that does this will be proactively protected from MI= TM >> attacks involving faked, forked, or otherwise bad log entries. And the >> client doesn=E2=80=99t have to compromise its privacy by gossiping with = anyone. >> > > Two points here: > > 1. Is this any different to requiring n SCTs from different logs for each > certificate (other than the inclusion proof part, which I address below)? > > > Semantically, no different, but how large many SCTs do you think is > practical to require to be attached to each cert? Two, three? Ten? A > hundred? How big is each SCT? > 44 bytes each. > > With the multi-SCT approach, the amount of bandwidth consumed during TLS > negotiation with every CT-supporting website increases linearly with n. > With the scalable multisignature approach, n can increase to arbitrarily > large size - a hundred, a thousand if needed - e.g., including all the > public auditors, monitors, etc. - without any increase in the size of > certificates, number of SCTs attached, or ultimately the bandwidth/latenc= y > overhead during TLS negotiation. > To be clear, you are proposing that instead of n logs with 1 signer each, we have 1 log with n signers? That seems unwise to me. You then have a SPOF for the whole network. But clearly each log could have more than one signer, but still have multiple logs. Then the question is: where is the trade off between number of logs and number of signers, bearing in mind that more than one signer introduces substantial complication. > > 2. Our original design for CT did indeed have certs served along with an > STH and an inclusion proof. Unfortunately, CAs categorically rejected thi= s > approach because of the latency it introduced in the certificate issuance > process. Personally, I think it would be a better approach. Now CAs are > more accepting of CT, perhaps it would be worth revisiting the question > with them? > > > Agreed, that would be great. > It would. A more likely outcome, though, is that servers serve inclusion proofs, which become available some (short) time after the certificate becomes available. This does leave a window in which the inclusion proof is not available. > > Bryan > > > >> >> Bryan >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans > > --001a11407ce21d87ef051ca40da2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , 6 Aug 2015 at 10:17 Bryan Ford <brynosaurus@gmail.com> wrote:
Sorry for the slow followup, I was= n=E2=80=99t able to keep up with the lists since the IETF meeting...
On Jul 24, 2015, at 1:09 PM, Ben Laurie <benl@google.com> wr= ote:

Hi, all:

Th= is is a call for adoption of
http://datatracker.ietf.org= /doc/draft-linus-trans-gossip-ct/
as a working group deliverable.=C2= =A0 The call closes on August 6.

While the draft represents a fine start at defi= ning a gossip mechanism, I would like to express serious reservations about= the draft=E2=80=99s basic premise that a gossip mechanism is the best appr= oach - or even an adequate approach - =E2=80=9Cto detect misbehavior by CT = logs=E2=80=9D, to quote the draft=E2=80=99s self-stated purpose.=C2=A0 As s= uch, I have serious reservations about the WG adopting the draft, not becau= se there=E2=80=99s anything wrong with the content of the draft per se but = because gossip is simply not the right approach.

F= irst, the gossip approach creates severe privacy problems, which are alread= y well-discussed so I won=E2=80=99t reiterate them.

Actually, I think you need to reiterate them, si= nce we think that gossip as proposed does _not_ create privacy problems.

It creates new privacy problems = by requiring the client (browser user) to =E2=80=9Copt out=E2=80=9D of web = browsing privacy in order to gain any security benefit.=C2=A0 Either the us= er hands over all his browsing history to a remote =E2=80=9Ctrusted auditor= =E2=80=9D, thereby opting out of privacy; or else the user remains fully vu= lnerable to the same kind of (potentially extended) MITM attacks that motiv= ated CT in the first place.

CT is not intended to directly prevent MitM attacks, it is intende= d to detect mis-issuance of certificates. It is true that if you can persis= tently isolate a client from the rest of the 'net, then you can defeat = CT.

However, I don't see why it makes any diff= erence whether you talk to trusted auditors (not, AIUI, expected to be the = default) or to the alleged origin server. The MITM can control both paths..= .


=C2=A0
=C2=A0
Second, th= e gossip approach can=E2=80=99t ensure that privacy-sensitive Web clients (= who can=E2=80=99t or don=E2=80=99t want to reveal their whole browsing hist= ory to a Trusted Auditor) will ever actually be able =E2=80=9Cto detect mis= behavior by CT logs=E2=80=9D, if for example the misbehaving log=E2=80=99s = private key is controlled by a MITM attacker between the Web client and the= website the client thinks he is visiting.

The intent of CT is not to enable clients to detect such = behaviour - rather, it is to enable the system as a whole to detect it.

Could you explain how =E2=80=9Cthe syst= em as a whole=E2=80=9D detects such misbehavior in the case of the state/IS= P-level MITM attacker scenario? =C2=A0
=

The state or ISP must isolate all clients they attack f= orever to avoid detection. In practice, this does not generally seem to be = possible.
=C2=A0

As I see it, if the= client/browser doesn=E2=80=99t opt-out of privacy by gossiping his browsin= g history with a trusted auditor, then the client=E2=80=99s *only* connecti= on to the rest of the world, i.e., =E2=80=9Cthe=C2=A0
system as a whole=E2=80=9D, is through the =E2=80=9Cw= eb server=E2=80=9D, which may well be the same kind of MITM attackers that = have been known to subvert the CA system.=C2=A0 The client never gets to co= mmunicate to the rest of the system - i.e., the legitimate CT log servers, = auditors, or monitors - and so the client never gets the opportunity to =E2= =80=9Ccompare notes=E2=80=9D with the rest of the system.=C2=A0 And the res= t of the system (the legitimate log servers, auditors, and monitors) never = have the opportunity to learn from the client that the client saw a MITM-at= tacked, forged set of CA certs, STHs, and SCTs.

This is correct, and seems to me to be correct= for any system - if you can isolate your victim forever, you can show your= own view of any system.
=C2=A0

=
Suppose, for example, it ever= so happens that a single company ends up running both a log server and a [= sub-]CA, and keeps both in the same poorly-protected safe.=C2=A0 If an atta= cker can steal those two private keys, then the attacker can silently MITM = any CT-aware client all it wants, by producing all the [non-EV] certificate= s it needs with a valid SCT, valid STH inclusion proofs in a fake log, etc.=

Chrome's policy woul= d require the subversion of at least two logs to achieve this, but for the = sake of argument, I'll concede that.

=
I thought you were requiring CAs to have multiple SCTs only for EV cer= tificates, no?=C2=A0 What if the attacker is happy to MITM attack the user = with a non-EV certificate and forego showing the user the =E2=80=9Cgreen ba= r=E2=80=9D?=C2=A0 Are you assuming that users will stop using the connectio= n if they don=E2=80=99t see the green bar?

Not at all. EV certificates are our first step for = CT.
=C2=A0

Or are you saying (contrary= to my prior understanding) that Chrome requires *all* CT certs to have mul= tiple SCTs signed by different log servers?

Chrome makes no requirement on "CT certs"= ;, only on EV certs. But in the long run, the intention is to require CT fo= r all certs.
=C2=A0
=C2=A0
=C2=A0The web client isn=E2= =80=99t going to learn about the problem via gossip with the website becaus= e that=E2=80=99s the MITM attacker, and the client can=E2=80=99t gossip wit= h anyone else without the serious privacy risk of trusting a single audit s= erver with his entire browsing history.=C2=A0 If the =E2=80=9Ctrusted audit= server=E2=80=9D is actually co-located with the client, then the audit ser= ver in turn can=E2=80=99t gossip with the rest of the world without creatin= g the same privacy risk.=C2=A0 Even if the client does voluntarily gossip w= ith a remote trusted audit server, the MITM attacker - e.g., an ISP-level o= r state-level attacker - might simply block connections to all well-known a= udit servers.

This attack= relies on a MitM that is sustained forever but indeed would succeed. We ac= cept that CT cannot defeat such an attack.=C2=A0

But isn=E2=80=99t that precisely what happened in the prior CO= MODO and DigiNotar cases, where the MITM attacks were detected only when a = few more security-conscious users compared the certificates they were seein= g against what the rest of the world was seeing through nonstandard =E2=80= =9Cside-channels=E2=80=9D?

Comodo: I don't know, actually.

DigiNo= tar: no - this was detected through pinning violations. Furthermore, the at= tacker would have had to do substantially more hacking to have managed to g= et something that even fooled the browser in the face of CT, and it still w= ould've leaked.
=C2=A0
=C2=A0Isn=E2=80=99t t= hat=C2=A0
<= div>
= I posted an E-mail last week suggesting an alternative approach, in which l= og servers would not individually sign their STHs but instead collectively = sign them with the active participation of (a suitable quorum of) the audit= ors and/or monitors watching their logs.=C2=A0 But I got no response to tha= t, so I=E2=80=99d like to try again.

In short: the= log server would propose log entries, but the auditors and/or monitors con= tribute to the STH signature, only after performing at least the =E2=80=9Ca= uditing=E2=80=9D function of verifying that the log server is behaving like= a correct log server.=C2=A0 In particular, all participants could proactiv= ely verify that the log server never forks or reverts the log, never signs = something syntactically invalid or with a wildly-incorrect timestamp (say += /- 24 hours), etc.=C2=A0 Then, even if the log server=E2=80=99s private key= was successfully stolen by a state-level attacker (and the attacker perhap= s even compromises a minority of the monitor/auditor keys), the attacker wi= ll be unable to forge an STH signature that a Web client or anyone else wil= l believe.

This would, in effect, convert each log= server from yet another juicy central attack target into a strongest-link = set (I like to use the term =E2=80=9Ccothority=E2=80=9D or collective autho= rity) with all the monitor and auditor servers watching it and contributing= to its signatures.=C2=A0 Of course, the attacker still wins if he successf= ully compromises any single CA (or sub-CA) *and* any single =E2=80=9Cloggin= g cothority=E2=80=9D (i.e., any log server *and* a sufficient quorum of its= followers).=C2=A0 But doing the latter becomes way, way harder if there=E2= =80=99s enough size and diversity in each logging cothority.

=
How does this improve things for the Web client in Repressistan = who's getting MITM attacked?=C2=A0 If the client is only looking at SCT= s that are individually signed by a log server (and are in any case only a = =E2=80=9Cpromise to log soon=E2=80=9D and not actual evidence that the cert= has been logged), then unfortunately not much: the MITM attacker can still= forge at least one SCT for each of its forged certs, and no one else learn= s because the MITM can keep the client=E2=80=99s view isolated from the res= t of the world.

But say we enhance CT so clients c= an demand STHs *with* cert inclusion proofs from the web servers they talk = to - as I suggested in the meeting today, and which I believe Ben Laurie me= ntioned is already in the works.=C2=A0 Then any Web client that does this w= ill be proactively protected from MITM attacks involving faked, forked, or = otherwise bad log entries.=C2=A0 And the client doesn=E2=80=99t have to com= promise its privacy by gossiping with anyone.

Two points here:

1. Is this a= ny different to requiring n SCTs from different logs for each certificate (= other than the inclusion proof part, which I address below)?

Semantically, no different, but how large many SCT= s do you think is practical to require to be attached to each cert?=C2=A0 T= wo, three?=C2=A0 Ten?=C2=A0 A hundred?=C2=A0 How big is each SCT? =C2=A0

44 bytes each.
<= div>=C2=A0

With the multi-SCT approach, the amou= nt of bandwidth consumed during TLS negotiation with every CT-supporting we= bsite increases linearly with n.=C2=A0 With the scalable multisignature app= roach, n can increase to arbitrarily large size - a hundred, a thousand if = needed - e.g., including all the public auditors, monitors, etc. - without = any increase in the size of certificates, number of SCTs attached, or ultim= ately the bandwidth/latency overhead during TLS negotiation.

To be clear, you are proposing th= at instead of n logs with 1 signer each, we have 1 log with n signers?

That seems unwise to me. You then have a SPOF for the = whole network.

But clearly each log could have mor= e than one signer, but still have multiple logs. Then the question is: wher= e is the trade off between number of logs and number of signers, bearing in= mind that more than one signer introduces substantial complication.
<= div>=C2=A0

2. Our original design for CT did indee= d have certs served along with an STH and an inclusion proof. Unfortunately= , CAs categorically rejected this approach because of the latency it introd= uced in the certificate issuance process. Personally, I think it would be a= better approach. Now CAs are more accepting of CT, perhaps it would be wor= th revisiting the question with them?
Agreed, that would be great.
It would.

A more likely outcome, thoug= h, is that servers serve inclusion proofs, which become available some (sho= rt) time after the certificate becomes available. This does leave a window = in which the inclusion proof is not available.
=C2=A0

Bryan

=C2=A0

Bryan
________= _______________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a11407ce21d87ef051ca40da2-- From nobody Thu Aug 6 08:46:30 2015 Return-Path: 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 098C91B3060 for ; Thu, 6 Aug 2015 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 B5a-gFxtCTcK for ; Thu, 6 Aug 2015 08:46:25 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 3FDD31B305D for ; Thu, 6 Aug 2015 08:46:25 -0700 (PDT) Received: by igbij6 with SMTP id ij6so13752916igb.1 for ; Thu, 06 Aug 2015 08:46:24 -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:content-transfer-encoding; bh=L0f57EOC3DBpSulkQVcSoDDlsyzgmYfzVn2mqc+qymM=; b=4KHPOlqWfKmrhcrDIV2k02V+e+p8466/+LUYtiete1KvVWf9pZH9+QnCBSEnp58ou4 SryQsFC1R47fl6i0x67+2cbMSukRqLFhMSzKfNluWAZd5gfU5cxhuzjbFtbTv+epJ4UL cSeP82pqV4xJWHwYedMXC+kOdahLykNp3qEDc= 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:content-transfer-encoding; bh=L0f57EOC3DBpSulkQVcSoDDlsyzgmYfzVn2mqc+qymM=; b=Se79edQPcQ37qC0tS5z/krveX+pdQBV0w8Z2y8XgLVBlUEXuEvhNZrO09BdVt6pU1z 9DxFxCJFAaMqb2m70HRbTIi3CR+lhk/+by3p61EI3fLT1QSrtRuvtJcBTR6sHR0LW6Iw Lqizco6YVJ7Feq42h/ZPQhpOtNgu55BRzIKxC3oj12jzwxbT7golqAVmHLl+8CX6XbMH 2H1HBYhbOu1nXq9erXXabK09MSOdYblDJwZg63W9d4suKW0LXwkoX/Ep4aBK3kw7ea4Y UQSflFs1opfPJgNugoeRAfNzuTa6keUBLbgAmhW/E7XscMF7mQlapnAmuayleABJIxb8 aVbg== X-Gm-Message-State: ALoCoQm+BWM25UzAPDvZ7Wnga5YkoWYpjYdWeXCVW9e3VaQflxlyqcCt/kPiYKEtAmDcxsWOV1iw X-Received: by 10.50.102.68 with SMTP id fm4mr4666531igb.25.1438875984478; Thu, 06 Aug 2015 08:46:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.71.1 with HTTP; Thu, 6 Aug 2015 08:46:04 -0700 (PDT) In-Reply-To: <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> From: Tom Ritter Date: Thu, 6 Aug 2015 08:46:04 -0700 Message-ID: To: Bryan Ford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:46:27 -0000 Thanks for this Bryan. I'm going to echo Ben a bit: On 6 August 2015 at 02:17, Bryan Ford wrote: > It creates new privacy problems by requiring the client (browser user) to > =E2=80=9Copt out=E2=80=9D of web browsing privacy in order to gain any se= curity benefit. > Either the user hands over all his browsing history to a remote =E2=80=9C= trusted > auditor=E2=80=9D, thereby opting out of privacy; or else the user remains= fully > vulnerable to the same kind of (potentially extended) MITM attacks that > motivated CT in the first place. If the Trusted Auditor mode is a default that requires Opting Out instead of Opting In I think I speak for every author when I say we will have considered this a huge failure and will rally against it as much as we can. > Could you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects suc= h misbehavior in > the case of the state/ISP-level MITM attacker scenario? > > As I see it, if the client/browser doesn=E2=80=99t opt-out of privacy by = gossiping > his browsing history with a trusted auditor, then the client=E2=80=99s *o= nly* > connection to the rest of the world, i.e., =E2=80=9Cthe system as a whole= =E2=80=9D, is > through the =E2=80=9Cweb server=E2=80=9D, which may well be the same kind= of MITM attackers > that have been known to subvert the CA system. The client never gets to > communicate to the rest of the system - i.e., the legitimate CT log serve= rs, > auditors, or monitors - and so the client never gets the opportunity to > =E2=80=9Ccompare notes=E2=80=9D with the rest of the system. And the res= t of the system > (the legitimate log servers, auditors, and monitors) never have the > opportunity to learn from the client that the client saw a MITM-attacked, > forged set of CA certs, STHs, and SCTs. In SCT Feedback the only connection to disclose data about Website A is indeed website A. In STH Feedback, assuming the client can resolve a Cert to a STH via an inclusion proof (which we currently suggest via DNS, but other mechanisms can exist, such as Tor) - that STH will be pollinated to _any_ website. And the split-view log will be caught. So that's how the 'system as a whole' detects the issue. The difference is of course because the SCT is private data that reveals browsing history, the STH is not (not counting old-STH attacks which we mitigate). If an attacker can both persistently MITM someone to a website (or the whole internet) and DoS the STH lookup mechanism (and compromise a log and a CA) - yes, the attacker wins. Attackers who can persistently MITM users forever are extremely powerful and we have no way to defend against them except to make all your client software just stop working. This applies to the CA system absent CT, it requires to the CA system with CT, and it applies to software updates. If you can write exploits, but not find bugs - just wait for a patch to come out, block the update, take your leisurely time reverse engineering, writing the exploit, and using it. I don't mean to dismiss this concern, but a) I don't believe SCT Feedback and STH Pollination cause privacy problems b) This problem is so hard that no one is attempting to defend against it c) History suggests such attackers are not all-powerful. Or at least, we've caught a lot of folks who could have gotten away with it that supposedly had that capability and could have known better. > Or are you saying (contrary to my prior understanding) that Chrome requir= es > *all* CT certs to have multiple SCTs signed by different log servers? As Ben said, the end goal is to use it for everything. I don't know when we'll get there, but in the interim there will probably be a period of opt-in: https://ritter.vg/blog-require_certificate_transparency.html > But isn=E2=80=99t that precisely what happened in the prior COMODO and Di= giNotar > cases, where the MITM attacks were detected only when a few more > security-conscious users compared the certificates they were seeing again= st > what the rest of the world was seeing through nonstandard =E2=80=9Cside-c= hannels=E2=80=9D? http://wiki.cacert.org/Risk/History and my recollection indicates DigiNotar - Chrome Pinning google.com TurkTrust - Chrome Pinning google.com ANSSI - Chrome Pinning google.com India CCA - Chrome Pinning google.com CNNIC - that website indicates it was CT that caught it, but I think that's a misunderstanding it was again Chrome Pinning google.com The Comodo incident you reference, was that the mozilla.com cert in 2008? That was someone just trying a RA portal and getting a cert: http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ Despite all the effort to find such certs manually, via MEKAI, Perspectives, Convergence, Cert Patrol, and others - I'm not aware of anyone ever catching a CA-signed misissued cert manually. > With the multi-SCT approach, the amount of bandwidth consumed during TLS > negotiation with every CT-supporting website increases linearly with n. > With the scalable multisignature approach, n can increase to arbitrarily > large size - a hundred, a thousand if needed - e.g., including all the > public auditors, monitors, etc. - without any increase in the size of > certificates, number of SCTs attached, or ultimately the bandwidth/latenc= y > overhead during TLS negotiation. While we aim to keep SCTs small as Ben indicated - yes, sending 10 would be quite a bit. I'm not sure of a great answer here.. I think the onus is kind of on the community to curate and run a fewer number of high-quality, mutually distrusting, different-juristictional logs. > 2. Our original design for CT did indeed have certs served along with an = STH > and an inclusion proof. Unfortunately, CAs categorically rejected this > approach because of the latency it introduced in the certificate issuance > process. Personally, I think it would be a better approach. Now CAs are m= ore > accepting of CT, perhaps it would be worth revisiting the question with > them? > > > Agreed, that would be great. I am most excited about the prospect of sending an inclusion proof to a recent STH to the client - but I don't actually think the cert is the answer. I think it's a TLS extension or (better) an OCSP staple. Doing this would eliminate what I think is the weakest part of the gossip document - the requirement to obtain a STH from a SCT (well a cert) via some 'privacy preserving manner'. (Which we, again, theorize to be DNS, but I don't think that's the answer for everyone.) If the STH was included in the Cert, that doesn't really change the game fo= r me. 1) The STH could be a STH on the split view of the log, so the immediate-decision security is no better that just sending a SCT. 2) The STH is too old. I don't want clients pollinate old STHs, because as time goes on, old STHs will be rarer and will be indicative of what website you visited. After 2.5 years there will only be 100? 1000? popular websites with that STH in the cert. So the old STH needs to be resolved to a recent STH, and you pollinate _that_. -tom From nobody Thu Aug 6 20:42:41 2015 Return-Path: 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 0ECA91B41BF for ; Thu, 6 Aug 2015 20:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gc5E8YEMnZ_d for ; Thu, 6 Aug 2015 20:42:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916061B41BE for ; Thu, 6 Aug 2015 20:42:37 -0700 (PDT) Received: from [128.89.254.153] (port=50904 helo=Johns-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZNYYF-0005iv-Uh for trans@ietf.org; Thu, 06 Aug 2015 23:42:36 -0400 To: trans@ietf.org References: <55B0D80C.1060600@gmail.com> From: Karen Seo Message-ID: <55C4292A.4070203@bbn.com> Date: Thu, 6 Aug 2015 23:42:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55B0D80C.1060600@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 03:42:39 -0000 +1 for adoption. On 7/23/15 8:03 AM, Melinda Shore wrote: > Hi, all: > > This is a call for adoption of > http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > as a working group deliverable. The call closes on August 6. > > Thanks, > > Melinda & Paul > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Fri Aug 7 12:02:34 2015 Return-Path: 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 4AF991A88BA; Fri, 7 Aug 2015 12:02:33 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 wj1QJPmcEBpI; Fri, 7 Aug 2015 12:02:32 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 28B161B2D27; Fri, 7 Aug 2015 12:02:32 -0700 (PDT) Received: by pdco4 with SMTP id o4so48236417pdc.3; Fri, 07 Aug 2015 12:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=FSXk1tSnszg7s49QArKmR/EbEKgISR5JMzvNoLo32rA=; b=CL+ajUTD22ifm6asU/lNofDS8ivtR31+yMypIZTRh6J7Iou1uLiQnQbFTH/CrPOEBR qqOizBAXnR5ktlaKRm7XzLd7kyN82XLlLYKMAj5N4FNvcdZr7D7tOsGp5LpfLNREuHcx gxuRZ4ubLcmqGUT9YqdXSw5/+Kr92ZLVl3epqDdEAsWfgwAEeZgt/Ov7EKF8Jd5664dF KVQNJbqTJPN0haIZhyNRGoLa5CRplQA0Q7KS8ApwRqqhVtGvdOq00nyYRk+EbScn3oKa /NG2bzYQ03jyu+Fng0wzpEj6Nzt6rAnfblkOrGlcPqrm+h3lEybJAmlRLCOETjqo6oXp 9CsQ== X-Received: by 10.70.53.1 with SMTP id x1mr17700534pdo.114.1438974151862; Fri, 07 Aug 2015 12:02:31 -0700 (PDT) Received: from spandex.local (209-193-56-16-radius.dynamic.acsalaska.net. [209.193.56.16]) by smtp.gmail.com with ESMTPSA id f4sm10942506pdc.95.2015.08.07.12.02.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2015 12:02:30 -0700 (PDT) Message-ID: <55C500C4.2080702@gmail.com> Date: Fri, 07 Aug 2015 11:02:28 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" , draft-linus-trans-gossip-ct@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Gossip draft CFA closed X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 19:02:33 -0000 Hi, all: Thank you for your feedback on the call for working group adoption of draft-linux-trans-gossip-ct. It's very clear that there's widespread support for adoption, and that we've both got people to work on the draft and to review it. Bryan Ford raised some technical issues during the discussion but those have been resolved (future revisions of the draft should include some text clarifying the conditions under which the data will be gossiped and what problems gossip is *not* intended to solve). The authors should resubmit the draft as draft-ietf-trans-gossip, and Paul and I will work with them to establish delivery milestones. Thanks again for your comments and discussion. Melinda From nobody Sat Aug 8 09:57:02 2015 Return-Path: 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 0935C1A916D for ; Sat, 8 Aug 2015 09:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 CAnq6Gji2elE for ; Sat, 8 Aug 2015 09:56:55 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 406B21A9165 for ; Sat, 8 Aug 2015 09:56:55 -0700 (PDT) Received: by qged69 with SMTP id d69so93864020qge.0 for ; Sat, 08 Aug 2015 09:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KACrVU0k9hjU5GLFMQG8xeTLkt3BgxZqwSR2Ghtubzs=; b=KJOMAyJxz8ruMnjeIhvWmiQ8WT4LquMg4u+5alO4/EhnX8qqp1BmpZeLgSO9WqpS/M 184Q+9spUizdcFnhbjXdCzesknpPleRCOe+Gw+iV+vys6V8HKcDaTIOz42MKRhge2FRM JoecYjbawYevFOKP8omyrs5EkrPdIN/kFgA9mwnZL00vTq9pTjGnaOSlUufe1Q2wd5jJ A9fDp4T/Iy+UqPxHFMihMFMyN+Ie37zDDm7sX7GSYgAnw/gAWTQauxYQKevILNS5rLdT RBdlEm7leJdZIxKsn8GCqgdqNzrzEj2uW8BjVMJf0E4iCZbvKVZzg0ymeLFBRUxGt07L nSQA== X-Received: by 10.140.135.197 with SMTP id 188mr25822203qhh.89.1439053014443; Sat, 08 Aug 2015 09:56:54 -0700 (PDT) Received: from [172.20.10.5] (mobile-107-107-57-205.mycingular.net. [107.107.57.205]) by smtp.gmail.com with ESMTPSA id b86sm4773472qkb.8.2015.08.08.09.56.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Aug 2015 09:56:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C79B6A2A-6905-4305-B042-BE1D1690A502"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Bryan Ford In-Reply-To: Date: Sat, 8 Aug 2015 12:56:50 -0400 Message-Id: References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> To: Tom Ritter X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 16:57:01 -0000 --Apple-Mail=_C79B6A2A-6905-4305-B042-BE1D1690A502 Content-Type: multipart/alternative; boundary="Apple-Mail=_202A3001-45BD-4EEF-BB11-DC36A5042D0D" --Apple-Mail=_202A3001-45BD-4EEF-BB11-DC36A5042D0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tom, > On Aug 6, 2015, at 11:46 AM, Tom Ritter wrote: >=20 > Thanks for this Bryan. I'm going to echo Ben a bit: >=20 > On 6 August 2015 at 02:17, Bryan Ford wrote: >> It creates new privacy problems by requiring the client (browser = user) to >> =E2=80=9Copt out=E2=80=9D of web browsing privacy in order to gain = any security benefit. >> Either the user hands over all his browsing history to a remote = =E2=80=9Ctrusted >> auditor=E2=80=9D, thereby opting out of privacy; or else the user = remains fully >> vulnerable to the same kind of (potentially extended) MITM attacks = that >> motivated CT in the first place. >=20 > If the Trusted Auditor mode is a default that requires Opting Out > instead of Opting In I think I speak for every author when I say we > will have considered this a huge failure and will rally against it as > much as we can. Agreed. With that in mind, would it be reasonable to include text to = this effect in the =E2=80=9Cgossip=E2=80=9D draft if it is adopted? For = example, =E2=80=9CImplementations of CT must ensure that Trusted Auditor = relationships are =E2=80=98opt-in=E2=80=99 relationships require the = explicit consent of the user, and not a bundled system default=E2=80=9D = or something like that? >> Could you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects = such misbehavior in >> the case of the state/ISP-level MITM attacker scenario? >>=20 >> As I see it, if the client/browser doesn=E2=80=99t opt-out of privacy = by gossiping >> his browsing history with a trusted auditor, then the client=E2=80=99s = *only* >> connection to the rest of the world, i.e., =E2=80=9Cthe system as a = whole=E2=80=9D, is >> through the =E2=80=9Cweb server=E2=80=9D, which may well be the same = kind of MITM attackers >> that have been known to subvert the CA system. The client never gets = to >> communicate to the rest of the system - i.e., the legitimate CT log = servers, >> auditors, or monitors - and so the client never gets the opportunity = to >> =E2=80=9Ccompare notes=E2=80=9D with the rest of the system. And the = rest of the system >> (the legitimate log servers, auditors, and monitors) never have the >> opportunity to learn from the client that the client saw a = MITM-attacked, >> forged set of CA certs, STHs, and SCTs. >=20 > In SCT Feedback the only connection to disclose data about Website A > is indeed website A. > In STH Feedback, assuming the client can resolve a Cert to a STH via > an inclusion proof (which we currently suggest via DNS, but other > mechanisms can exist, such as Tor) - that STH will be pollinated to > _any_ website. And the split-view log will be caught. So that's how > the 'system as a whole' detects the issue. OK, I see how STH pollination can at least raise the bar significantly = for MITM attackers in a way that SCT feedback can=E2=80=99t. But it = still seems neither sufficient, nor the best we can do, nor convincingly = =E2=80=9Csafe=E2=80=9D in terms of privacy; see below. > The difference is of course because the SCT is private data that > reveals browsing history, the STH is not (not counting old-STH attacks > which we mitigate). I see there is already some text in the gossip draft acknowledging the = privacy risks that =E2=80=9Cpromiscuous=E2=80=9D STH pollination, but = the current text doesn=E2=80=99t go far enough and underestimates the = risk. For example, by the calculations in the text, suppose a malicious = HTTPS server has up to 336 unique STHs per log that it could use to = =E2=80=9Ctag=E2=80=9D and track clients over time. Supposing there are = 10 well-known log servers, this is 3360 unique STHs total. The current = text seems to suggest that this is =E2=80=9Csmall enough=E2=80=9D, which = may be true in the one particular attack the text suggests earlier, = namely that the attacker picks one particular less-popular (e.g., = somewhat-old) STH to give a client it wishes to track. =20 But this is not the =E2=80=9Creal=E2=80=9D attack of interest: a just = slightly smarter attacker would probably use the presence or absence of = these less-popular STHs in a client=E2=80=99s gossip cache as (noisy) = bits in a tracking identifier. The attacker would gossip to each client = it hasn=E2=80=99t seen before some kind of ECC-encoded pattern of = less-popular STHs. Thus, the 3360 unique STHs the attacker gets to play = with do not represents =E2=80=9Cthe number of clients the attacker can = track=E2=80=9D as the current text seems to suggest, but rather the 3360 = unique STHs may in fact be =E2=80=9Ctracking tag bits=E2=80=9D that the = attacker gets to play with in attempting to imprint clients with = tracking tags via gossip. And 3360 bits is a lot of bits: plenty of = room for a highly-unique (say 64-bit) per-client tag to be encoded in a = high-expansion, rather noise-tolerant encoding. Of course, a user could still avoid being tracked in this fashion by = using a stateless, =E2=80=9Camnesiac=E2=80=9D browsing platform like = Tails, which would presumably start with an empty STH cache on each = boot. But this would also defeat CT=E2=80=99s ability to use STH = polination to detect MITM attacks across client/browser sessions. > If an attacker can both persistently MITM someone to a website (or the > whole internet) and DoS the STH lookup mechanism (and compromise a log > and a CA) - yes, the attacker wins. >=20 > Attackers who can persistently MITM users forever are extremely > powerful and we have no way to defend against them except to make all > your client software just stop working. Attackers who can persistently MITM users forever are indeed extremely = powerful but are not at all unrealistic, given the increasing presence = of Great Firewall type attackers (and all the smaller wanna-be = knockoffs), which can indeed persistently control the =E2=80=9Cnetworked = view of the world=E2=80=9D seen by any user who cannot or does not = regularly travel internationally. I disagree that we have no way to defend against them; if you think so = you=E2=80=99re giving up too quickly. Of course such an attacker can = simply block or DoS all the user=E2=80=99s communication in any case, = but in practice most of these attackers would rather let the client = think they=E2=80=99re communicating securely while silently compromising = them. CT with gossip cannot even guarantee that such silent, persistent = MITM attacks will ever even be detected (by anyone), let alone = prevented. But the multi-signed STH approach I suggested would do = exactly that. Since the pervasive MITM attacker would be unable to = forge a single valid STH signature the client will accept without = compromising a large quorum of monitor/witness/co-signer servers as = well, the attacker is left with the choice of remaining silent and = leaving the client=E2=80=99s communication uncompromised, or = denying/blocking the communication entirely. I claim that such a = situation would be much, much preferable to the current state of affairs = even with CT deployed. > This applies to the CA system > absent CT, it requires to the CA system with CT, and it applies to > software updates. If you can write exploits, but not find bugs - just > wait for a patch to come out, block the update, take your leisurely > time reverse engineering, writing the exploit, and using it. Of course client-side software security is a huge and important problem = in itself, but it=E2=80=99s orthogonal to the design of CT. I have = plenty of thoughts on how multi-signing or cothorities could be used to = improve the situation there as well, but that=E2=80=99s another topic. > I don't mean to dismiss this concern, but a) I don't believe SCT > Feedback and STH Pollination cause privacy problems See above. > b) This problem is > so hard that no one is attempting to defend against it I am; see above. > c) History > suggests such attackers are not all-powerful. =20 Agreed, such attackers are not all-powerful, but pretty much any = compromised or state-controlled ISP is certainly powerful enough to = persistently MITM any client that always connects through that ISP - = which is true at least of (a) desktop machines on a home or work network = always attached via the same connection, and (b) smartphones roaming = within a country but always using a data plan through the same cellular = ISP. These threat models do not seem unrealistic to me, but rather = quite ubiquitous. > Or at least, we've > caught a lot of folks who could have gotten away with it that > supposedly had that capability and could have known better. Yes, a lot of current attackers have been sloppy in one way or another, = but that doesn=E2=80=99t mean we should assume the they will not learn = from their past mistakes and adopt less sloppy attacks in the future. = They will. >> Or are you saying (contrary to my prior understanding) that Chrome = requires >> *all* CT certs to have multiple SCTs signed by different log servers? >=20 > As Ben said, the end goal is to use it for everything. What is the =E2=80=9Cit=E2=80=9D to be used for everything? CT? Or CT = with a mandatory minimum of >1 SCTs? And again, what do you think a = reasonable mandatory minimum number of SCTs would be? Two, five, ten, = 100? If it starts at 1 or 2 for pragmatic reasons, will it ever = increase or will it stay forever at 2 due to inertia? Is that good = enough? > I don't know > when we'll get there, but in the interim there will probably be a > period of opt-in: > https://ritter.vg/blog-require_certificate_transparency.html = Nice blog post, but I don=E2=80=99t see where it addresses the issue of = how many independent SCTs a browser should expect/require a cert to have = even if it does decide to demand CT support. > The Comodo incident you reference, was that the mozilla.com cert in > 2008? That was someone just trying a RA portal and getting a cert: > http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ = > Despite all the effort to find such certs manually, via MEKAI, > Perspectives, Convergence, Cert Patrol, and others - I'm not aware of > anyone ever catching a CA-signed misissued cert manually. I think it was the March 2011 incident, where a hacker was able to = obtain fraudulent certificates through Comodo and then apparently = attempted to use at least one of them, for =E2=80=98login.yahoo.com=E2=80=99= , in some way: = https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html = = Comodo=E2=80=99s report and the other information I found don=E2=80=99t = make it clear exactly in what way the login.yahoo.com = cert was =E2=80=9Cseen live on the Internet=E2=80= =9D - perhaps it was Google pinning as well if Google was pinning = Yahoo=E2=80=99s certs at that time (were they?), or perhaps it was = manual forensics. Perhaps you or someone else has better information = about this. But this is all incidental: it=E2=80=99s great that Google = pinning has caught a lot of incidents, but nobody seems to be saying = that means Google pinning is the best/final solution. >> With the multi-SCT approach, the amount of bandwidth consumed during = TLS >> negotiation with every CT-supporting website increases linearly with = n. >> With the scalable multisignature approach, n can increase to = arbitrarily >> large size - a hundred, a thousand if needed - e.g., including all = the >> public auditors, monitors, etc. - without any increase in the size of >> certificates, number of SCTs attached, or ultimately the = bandwidth/latency >> overhead during TLS negotiation. >=20 > While we aim to keep SCTs small as Ben indicated - yes, sending 10 > would be quite a bit. I'm not sure of a great answer here.. I think > the onus is kind of on the community to curate and run a fewer number > of high-quality, mutually distrusting, different-juristictional logs. This is precisely my point: by architecturally relying on multiple SCTs = per cert we=E2=80=99re tying ourselves into the same bad old security = tradeoff of having to trust a few =E2=80=9Chigh-quality, mutually = distrusting, different-jurisdictional logs=E2=80=9D - i.e., a few = conventional centralized authorities. How do you choose them? Who = chooses them? Do you let one of those 10 be run by (say) Iran or Syria, = in the interest of diversity (at least they=E2=80=99re probably not = colluding with the Five Eyes countries!) - even though their governments = have a record of trying to MITM their users = (https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-h= ttps = , = https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook = = ) and can probably be expected to try to exploit their control over = =E2=80=9Ctheir=E2=80=9D log server in any way the CT architecture allows = them to (such as persistent MITM attacks as discussed above)? With the scalable multi signing, in contrast, we could have 10 or 100 or = 1000 monitor/co-signer servers contributing to each STH signature with = *no* cost to client verification time, client CPU costs, TLS startup = bandwidth consumed, etc. One quite reasonable policy might be that = *every* country that is technically capable of running a = monitor/co-signer server could join and participate in the signing = process of every STH of every well-known log. If you=E2=80=99re = claiming that it=E2=80=99s infeasible to decentralize trust in such a = service beyond 10 or so well-known nodes, again I think you=E2=80=99re = just giving up and conceding the field too quickly. >> 2. Our original design for CT did indeed have certs served along with = an STH >> and an inclusion proof. Unfortunately, CAs categorically rejected = this >> approach because of the latency it introduced in the certificate = issuance >> process. Personally, I think it would be a better approach. Now CAs = are more >> accepting of CT, perhaps it would be worth revisiting the question = with >> them? >>=20 >>=20 >> Agreed, that would be great. >=20 > I am most excited about the prospect of sending an inclusion proof to > a recent STH to the client - but I don't actually think the cert is > the answer. I think it's a TLS extension or (better) an OCSP staple. > Doing this would eliminate what I think is the weakest part of the > gossip document - the requirement to obtain a STH from a SCT (well a > cert) via some 'privacy preserving manner'. (Which we, again, > theorize to be DNS, but I don't think that's the answer for everyone.) Agreed on this. In fact, it=E2=80=99s increasingly unclear to me what = security purpose SCTs actually serve if it indeed ends up that the = =E2=80=9Creal=E2=80=9D security CT provides is eventually going to = revolve mainly around STHs and inclusion proofs. Out of curiosity, has = anyone floated or elaborated on the idea of what CT would look like if = simplified not to rely on SCTs at all? > If the STH was included in the Cert, that doesn't really change the = game for me. > 1) The STH could be a STH on the split view of the log, so the > immediate-decision security is no better that just sending a SCT. > 2) The STH is too old. I don't want clients pollinate old STHs, > because as time goes on, old STHs will be rarer and will be indicative > of what website you visited. After 2.5 years there will only be 100? > 1000? popular websites with that STH in the cert. So the old STH needs > to be resolved to a recent STH, and you pollinate _that_. Agreed again. B >=20 > -tom --Apple-Mail=_202A3001-45BD-4EEF-BB11-DC36A5042D0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tom,

On Aug 6, 2015, at 11:46 AM, = Tom Ritter <tom@ritter.vg> wrote:

Thanks for this = Bryan.  I'm going to echo Ben a bit:

On = 6 August 2015 at 02:17, Bryan Ford <brynosaurus@gmail.com> wrote:
It creates new privacy problems by requiring = the client (browser user) to
=E2=80=9Copt out=E2=80=9D of = web browsing privacy in order to gain any security benefit.
Either the user hands over all his browsing history to a = remote =E2=80=9Ctrusted
auditor=E2=80=9D, thereby opting = out of privacy; or else the user remains fully
vulnerable = to the same kind of (potentially extended) MITM attacks that
motivated CT in the first place.
If the Trusted Auditor mode is a default that requires = Opting Out
instead of Opting In I think I speak for every = author when I say we
will have considered this a huge = failure and will rally against it as
much as we can.

Agreed. =  With that in mind, would it be reasonable to include text to this = effect in the =E2=80=9Cgossip=E2=80=9D draft if it is adopted?  For = example, =E2=80=9CImplementations of CT must ensure that Trusted Auditor = relationships are =E2=80=98opt-in=E2=80=99 relationships require the = explicit consent of the user, and not a bundled system default=E2=80=9D = or something like that?

Could = you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects such = misbehavior in
the case of the state/ISP-level MITM = attacker scenario?

As I see it, if the = client/browser doesn=E2=80=99t opt-out of privacy by gossiping
his browsing history with a trusted auditor, then the = client=E2=80=99s *only*
connection to the rest of the = world, i.e., =E2=80=9Cthe system as a whole=E2=80=9D, is
through the =E2=80=9Cweb server=E2=80=9D, which may well be = the same kind of MITM attackers
that have been known to = subvert the CA system.  The client never gets to
communicate to the rest of the system - i.e., the legitimate = CT log servers,
auditors, or monitors - and so the client = never gets the opportunity to
=E2=80=9Ccompare notes=E2=80=9D= with the rest of the system.  And the rest of the system
(the legitimate log servers, auditors, and monitors) never = have the
opportunity to learn from the client that the = client saw a MITM-attacked,
forged set of CA certs, STHs, = and SCTs.

In SCT Feedback the = only connection to disclose data about Website A
is indeed = website A.
In STH Feedback, assuming the client can = resolve a Cert to a STH via
an inclusion proof (which we = currently suggest via DNS, but other
mechanisms can exist, = such as Tor) - that STH will be pollinated to
_any_ = website.  And the split-view log will be caught. So that's how
the 'system as a whole' detects the issue.

OK, I see = how STH pollination can at least raise the bar significantly for MITM = attackers in a way that SCT feedback can=E2=80=99t.  But it still = seems neither sufficient, nor the best we can do, nor convincingly = =E2=80=9Csafe=E2=80=9D in terms of privacy; see below.

The = difference is of course because the SCT is private data that
reveals browsing history, the STH is not (not counting = old-STH attacks
which we mitigate).

I see there = is already some text in the gossip draft acknowledging the privacy risks = that =E2=80=9Cpromiscuous=E2=80=9D STH pollination, but the current text = doesn=E2=80=99t go far enough and underestimates the risk.  For = example, by the calculations in the text, suppose a malicious HTTPS = server has up to 336 unique STHs per log that it could use to =E2=80=9Ctag= =E2=80=9D and track clients over time.  Supposing there are 10 = well-known log servers, this is 3360 unique STHs total.  The = current text seems to suggest that this is =E2=80=9Csmall enough=E2=80=9D,= which may be true in the one particular attack the text suggests = earlier, namely that the attacker picks one particular less-popular = (e.g., somewhat-old) STH to give a client it wishes to track. =  

But this is not the = =E2=80=9Creal=E2=80=9D attack of interest: a just slightly smarter = attacker would probably use the presence or absence of these = less-popular STHs in a client=E2=80=99s gossip cache as (noisy) bits in = a tracking identifier.  The attacker would gossip to each client it = hasn=E2=80=99t seen before some kind of ECC-encoded pattern of = less-popular STHs.  Thus, the 3360 unique STHs the attacker gets to = play with do not represents =E2=80=9Cthe number of clients the attacker = can track=E2=80=9D as the current text seems to suggest, but rather the = 3360 unique STHs may in fact be =E2=80=9Ctracking tag bits=E2=80=9D that = the attacker gets to play with in attempting to imprint clients with = tracking tags via gossip.  And 3360 bits is a lot of bits: plenty = of room for a highly-unique (say 64-bit) per-client tag to be encoded in = a high-expansion, rather noise-tolerant encoding.

Of course, a user could still avoid being tracked = in this fashion by using a stateless, =E2=80=9Camnesiac=E2=80=9D = browsing platform like Tails, which would presumably start with an empty = STH cache on each boot.  But this would also defeat CT=E2=80=99s = ability to use STH polination to detect MITM attacks across = client/browser sessions.

If an attacker can both persistently MITM = someone to a website (or the
whole internet) and DoS the = STH lookup mechanism (and compromise a log
and a CA) - = yes, the attacker wins.

Attackers who can = persistently MITM users forever are extremely
powerful and = we have no way to defend against them except to make all
your client software just stop = working.

Attackers who = can persistently MITM users forever are indeed extremely powerful but = are not at all unrealistic, given the increasing presence of Great = Firewall type attackers (and all the smaller wanna-be knockoffs), which = can indeed persistently control the =E2=80=9Cnetworked view of the = world=E2=80=9D seen by any user who cannot or does not regularly travel = internationally.

I disagree that we = have no way to defend against them; if you think so you=E2=80=99re = giving up too quickly.  Of course such an attacker can simply block = or DoS all the user=E2=80=99s communication in any case, but in practice = most of these attackers would rather let the client think they=E2=80=99re = communicating securely while silently compromising them.  CT with = gossip cannot even guarantee that such silent, persistent MITM attacks = will ever even be detected (by anyone), let alone prevented.  But = the multi-signed STH approach I suggested would do exactly that. =  Since the pervasive MITM attacker would be unable to forge a = single valid STH signature the client will accept without compromising a = large quorum of monitor/witness/co-signer servers as well, the attacker = is left with the choice of remaining silent and leaving the client=E2=80=99= s communication uncompromised, or denying/blocking the communication = entirely.  I claim that such a situation would be much, much = preferable to the current state of affairs even with CT = deployed.

This applies to the CA system
absent CT, it = requires to the CA system with CT, and it applies to
software updates.  If you can write exploits, but not = find bugs - just
wait for a patch to come out, block the = update, take your leisurely
time reverse engineering, = writing the exploit, and using it.

Of course = client-side software security is a huge and important problem in itself, = but it=E2=80=99s orthogonal to the design of CT.  I have plenty of = thoughts on how multi-signing or cothorities could be used to improve = the situation there as well, but that=E2=80=99s another topic.

I don't = mean to dismiss this concern, but a) I don't believe SCT
Feedback and STH Pollination cause privacy problems =

See above.

b) This = problem is
so hard that no one is attempting to defend = against it

I am; see = above.

c) History
suggests such attackers are not = all-powerful.  

Agreed, such attackers are not all-powerful, but = pretty much any compromised or state-controlled ISP is certainly = powerful enough to persistently MITM any client that always connects = through that ISP - which is true at least of (a) desktop machines on a = home or work network always attached via the same connection, and (b) = smartphones roaming within a country but always using a data plan = through the same cellular ISP.  These threat models do not seem = unrealistic to me, but rather quite ubiquitous.

Or at = least, we've
caught a lot of folks who could have gotten = away with it that
supposedly had that capability and could = have known better.

Yes, a lot of current attackers have been sloppy = in one way or another, but that doesn=E2=80=99t mean we should assume = the they will not learn from their past mistakes and adopt less sloppy = attacks in the future.  They will.

Or are you saying (contrary to my prior understanding) that = Chrome requires
*all* CT certs to have multiple SCTs = signed by different log servers?

As Ben said, the end goal is to use it for = everything.

What is the = =E2=80=9Cit=E2=80=9D to be used for everything?  CT?  Or CT = with a mandatory minimum of >1 SCTs?  And again, what do you = think a reasonable mandatory minimum number of SCTs would be?  Two, = five, ten, 100?  If it starts at 1 or 2 for pragmatic reasons, will = it ever increase or will it stay forever at 2 due to inertia?  Is = that good enough?

I don't know
when we'll get = there, but in the interim there will probably be a
period = of opt-in:
https://ritter.vg/blog-require_certificate_transparency.html

Nice blog = post, but I don=E2=80=99t see where it addresses the issue of how many = independent SCTs a browser should expect/require a cert to have even if = it does decide to demand CT support.

The Comodo incident you = reference, was that the mozilla.com cert in
2008?  That was = someone just trying a RA portal and getting a cert:
http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/<= /a>

Despite all the effort to find such certs = manually, via MEKAI,
Perspectives, Convergence, Cert = Patrol, and others - I'm not aware of
anyone ever catching = a CA-signed misissued cert manually.

I think it was the March 2011 incident, where a = hacker was able to obtain fraudulent certificates through Comodo and = then apparently attempted to use at least one of them, for =E2=80=98login.yahoo.com=E2=80=99, = in some way: https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html  Comodo=E2=80=99s report and the other information I found = don=E2=80=99t make it clear exactly in what way the login.yahoo.com cert = was =E2=80=9Cseen live on the Internet=E2=80=9D - perhaps it was Google = pinning as well if Google was pinning Yahoo=E2=80=99s certs at that time = (were they?), or perhaps it was manual forensics.  Perhaps you or = someone else has better information about this.  But this is all = incidental: it=E2=80=99s great that Google pinning has caught a lot of = incidents, but nobody seems to be saying that means Google pinning is = the best/final solution.

With the = multi-SCT approach, the amount of bandwidth consumed during TLS
negotiation with every CT-supporting website increases = linearly with n.
With the scalable multisignature = approach, n can increase to arbitrarily
large size - a = hundred, a thousand if needed - e.g., including all the
public auditors, monitors, etc. - without any increase in the = size of
certificates, number of SCTs attached, or = ultimately the bandwidth/latency
overhead during TLS = negotiation.

While we aim to = keep SCTs small as Ben indicated - yes, sending 10
would = be quite a bit.  I'm not sure of a great answer here.. I think
the onus is kind of on the community to curate and run a = fewer number
of high-quality, mutually distrusting, = different-juristictional logs.

This is precisely my point: by architecturally = relying on multiple SCTs per cert we=E2=80=99re tying ourselves into the = same bad old security tradeoff of having to trust a few =E2=80=9Chigh-qual= ity, mutually distrusting, different-jurisdictional logs=E2=80=9D - = i.e., a few conventional centralized authorities.  How do you = choose them?  Who chooses them?  Do you let one of those 10 be = run by (say) Iran or Syria, in the interest of diversity (at least = they=E2=80=99re probably not colluding with the Five Eyes countries!) - = even though their governments have a record of trying to MITM their = users (https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fr= audulent-https, https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against= -facebook) and can probably be expected to try to exploit their = control over =E2=80=9Ctheir=E2=80=9D log server in any way the CT = architecture allows them to (such as persistent MITM attacks as = discussed above)?

With the scalable = multi signing, in contrast, we could have 10 or 100 or 1000 = monitor/co-signer servers contributing to each STH signature with *no* = cost to client verification time, client CPU costs, TLS startup = bandwidth consumed, etc.  One quite reasonable policy might be that = *every* country that is technically capable of running a = monitor/co-signer server could join and participate in the signing = process of every STH of every well-known log.  If you=E2=80=99re = claiming that it=E2=80=99s infeasible to decentralize trust in such a = service beyond 10 or so well-known nodes, again I think you=E2=80=99re = just giving up and conceding the field too quickly.

2. Our original design = for CT did indeed have certs served along with an STH
and = an inclusion proof. Unfortunately, CAs categorically rejected this
approach because of the latency it introduced in the = certificate issuance
process. Personally, I think it would = be a better approach. Now CAs are more
accepting of CT, = perhaps it would be worth revisiting the question with
them?


Agreed, = that would be great.

I am most = excited about the prospect of sending an inclusion proof to
a recent STH to the client - but I don't actually think the = cert is
the answer. I think it's a TLS extension or = (better) an OCSP staple.
Doing this would eliminate what I = think is the weakest part of the
gossip document - the = requirement to obtain a STH from a SCT (well a
cert) via = some 'privacy preserving manner'.  (Which we, again,
theorize to be DNS, but I don't think that's the answer for = everyone.)

Agreed on this.  In fact, it=E2=80=99s = increasingly unclear to me what security purpose SCTs actually serve if = it indeed ends up that the =E2=80=9Creal=E2=80=9D security CT provides = is eventually going to revolve mainly around STHs and inclusion proofs. =  Out of curiosity, has anyone floated or elaborated on the idea of = what CT would look like if simplified not to rely on SCTs at = all?

If the STH was included in the Cert, that doesn't really = change the game for me.
1) The STH could be a STH on the = split view of the log, so the
immediate-decision security = is no better that just sending a SCT.
2) The STH is too = old. I don't want clients pollinate old STHs,
because as = time goes on, old STHs will be rarer and will be indicative
of what website you visited. After 2.5 years there will only = be 100?
1000? popular websites with that STH in the cert. = So the old STH needs
to be resolved to a recent STH, and = you pollinate _that_.

Agreed again.

B


-tom

= --Apple-Mail=_202A3001-45BD-4EEF-BB11-DC36A5042D0D-- --Apple-Mail=_C79B6A2A-6905-4305-B042-BE1D1690A502 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA4MDgxNjU2NTFaMCMGCSqGSIb3DQEJBDEWBBQ26xzjcXHBB3aeb9bWP0L8vv5rqzCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAPTtV3M13hRcYFhsBd8Yhyux+q9BszYH0xcpop5az9S3GXFqzJyg2YHdfae8ePkkS fRE2RDShmdmw7cfx24rIZvApPj6ZcABBn80Osp1M8U6iGzhYzgTUphqvYEVWRWWtoYGlRojf/Amy E5IdD5YEZUa6gi47JmDOU/KQVCbQ8O+NK3hNFFy/qvsbvNqOazYUehJqbJw0gfdcp1XMGtR0XGDI 6US3lbl/cG48RFdifXv9pxbBGLTCFtsT5ExMcMUpRip6r/Uypy0ftctJ+wyX17Qiljw3WnnoG0Cq GiOp+J67/GbyB39rHESVG4cFovHODKvz7shJp+7MoV8EpEuhIQAAAAAAAA== --Apple-Mail=_C79B6A2A-6905-4305-B042-BE1D1690A502-- From nobody Sat Aug 8 10:25:51 2015 Return-Path: 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 27AA71B29D1 for ; Sat, 8 Aug 2015 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 LH3h5CeQVU-x for ; Sat, 8 Aug 2015 10:25:46 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 710B71B29CB for ; Sat, 8 Aug 2015 10:25:46 -0700 (PDT) Received: by qgj62 with SMTP id 62so68943703qgj.2 for ; Sat, 08 Aug 2015 10:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+Md67ECNmDbc9tmFMDtib2jORvJQ/fdxkBr9KVa1LCg=; b=JPQQiPyKC1HHdn40r6gYQaNQ7blMmd4xst0EZpiJKhaQgDgrB1OrHhg+57QU4zwAFi Iqb78lNapXggRM9zrwPCTS7jCh1ngPyQE+PIpWrEdqQj4DaGiRQHqk67Y3PFGOUgANvI 6zp6YEC2dcyxyRk/vCYSwTnGFKywotKLn0on8EIMbYwkmc6ZPPC0fEaImGub3YSrWuSB Ht15gvVZcBGeXQa3GuXQGRuhRc6nlJIY6+RocbP2ZSrZSMt5zvBY9ut7xK3ZqNgKJxRv Uvast/IW8ufKsMqppGUd7giYMwDnj+PRyfWXh8QiRDVg+pyP+YNWHf0hY4i3Ylex/J72 rlYw== X-Received: by 10.140.216.18 with SMTP id m18mr25093046qhb.104.1439054745640; Sat, 08 Aug 2015 10:25:45 -0700 (PDT) Received: from [172.20.10.5] (mobile-107-107-57-205.mycingular.net. [107.107.57.205]) by smtp.gmail.com with ESMTPSA id 16sm6822892qhg.32.2015.08.08.10.25.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Aug 2015 10:25:44 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_ADE35D3E-7E1E-4E6C-8FA2-5413F1B81702"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Bryan Ford In-Reply-To: Date: Sat, 8 Aug 2015 13:25:41 -0400 Message-Id: <1AD5EA0D-5E8C-4C1D-B32C-24CB9375C8F2@gmail.com> References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> To: Ben Laurie X-Mailer: Apple Mail (2.2102) Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 17:25:50 -0000 --Apple-Mail=_ADE35D3E-7E1E-4E6C-8FA2-5413F1B81702 Content-Type: multipart/alternative; boundary="Apple-Mail=_0B95B546-66BF-49CE-83E1-3A699C091BC3" --Apple-Mail=_0B95B546-66BF-49CE-83E1-3A699C091BC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 6, 2015, at 8:56 AM, Ben Laurie wrote: > On Thu, 6 Aug 2015 at 10:17 Bryan Ford > wrote: >> On Jul 24, 2015, at 1:09 PM, Ben Laurie > wrote: >> On Thu, 23 Jul 2015 at 23:27 Bryan Ford > wrote: >=20 >> Second, the gossip approach can=E2=80=99t ensure that = privacy-sensitive Web clients (who can=E2=80=99t or don=E2=80=99t want = to reveal their whole browsing history to a Trusted Auditor) will ever = actually be able =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, if = for example the misbehaving log=E2=80=99s private key is controlled by a = MITM attacker between the Web client and the website the client thinks = he is visiting. >>=20 >> The intent of CT is not to enable clients to detect such behaviour - = rather, it is to enable the system as a whole to detect it. >=20 > Could you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects = such misbehavior in the case of the state/ISP-level MITM attacker = scenario? =20 >=20 > The state or ISP must isolate all clients they attack forever to avoid = detection. In practice, this does not generally seem to be possible. > =20 > As I see it, if the client/browser doesn=E2=80=99t opt-out of privacy = by gossiping his browsing history with a trusted auditor, then the = client=E2=80=99s *only* connection to the rest of the world, i.e., = =E2=80=9Cthe=20 > system as a whole=E2=80=9D, is through the =E2=80=9Cweb server=E2=80=9D,= which may well be the same kind of MITM attackers that have been known = to subvert the CA system. The client never gets to communicate to the = rest of the system - i.e., the legitimate CT log servers, auditors, or = monitors - and so the client never gets the opportunity to =E2=80=9Ccompar= e notes=E2=80=9D with the rest of the system. And the rest of the = system (the legitimate log servers, auditors, and monitors) never have = the opportunity to learn from the client that the client saw a = MITM-attacked, forged set of CA certs, STHs, and SCTs. >=20 > This is correct, and seems to me to be correct for any system - if you = can isolate your victim forever, you can show your own view of any = system. To reiterate the key point I made in my response to Tom=E2=80=99s = E-mail, this is not true of the multisignature-based STH signing I = suggested. Suppose for each CT log server there are (for example) 100 = monitor servers widely distributed around the world, run by diverse = companies, governments, etc. And suppose that any STH must be = collectively signed by the log server and at least 51 of its monitor = servers in order for clients to consider it valid. Assume the victim = user/browser is isolated behind a MITM attacker (call it Repressistan) = who controls all the paths in and out of Repressistan and never lets the = user physically enter or leave Repressistan. Thus the user never has = opportunity to do CT gossip via any path not controlled by the = Repressistani Firewall. In CT=E2=80=99s current design, Repressistan = wins - gaining the ability to silently compromise the user forever - = simply by Pwning one CA key and one log server key. (Or maybe two if = you require two SCTs per cert.) =20 In the multisignature approach, Repressistan gains the ability to forge = a STH for a =E2=80=9Cclient-customized world view" only if Repressistan = can also compromise more than 50 monitors of a compromised log = server=E2=80=99s collective signing pool. Every valid, = client-verifiable STH signature ensures to the client not only that the = log server=E2=80=99s key signed the STH but also that at least 51 = monitor servers also witnessed it (even if those monitors are doing no = checking at all other than saying =E2=80=9CI saw it=E2=80=9D). = Repressistan can no longer forge a valid (above-threshold) STH signature = without an inconceivably massive collusion or security breach. = Repressistan still simply prevent the user from communicating at all, of = course, but loses the ability either to silently compromise the = connection or silently evade detection. And the client need not risk = its privacy via gossip in any way to receive this protection. >> Suppose, for example, it ever so happens that a single company ends = up running both a log server and a [sub-]CA, and keeps both in the same = poorly-protected safe. If an attacker can steal those two private keys, = then the attacker can silently MITM any CT-aware client all it wants, by = producing all the [non-EV] certificates it needs with a valid SCT, valid = STH inclusion proofs in a fake log, etc. >>=20 >> Chrome's policy would require the subversion of at least two logs to = achieve this, but for the sake of argument, I'll concede that. >=20 > I thought you were requiring CAs to have multiple SCTs only for EV = certificates, no? What if the attacker is happy to MITM attack the user = with a non-EV certificate and forego showing the user the =E2=80=9Cgreen = bar=E2=80=9D? Are you assuming that users will stop using the = connection if they don=E2=80=99t see the green bar? >=20 > Not at all. EV certificates are our first step for CT. > =20 > Or are you saying (contrary to my prior understanding) that Chrome = requires *all* CT certs to have multiple SCTs signed by different log = servers? >=20 > Chrome makes no requirement on "CT certs", only on EV certs. But in = the long run, the intention is to require CT for all certs. But what does =E2=80=9Crequiring CT=E2=80=9D mean in terms of the number = of SCTs a given cert (EV or non-EV) will be =E2=80=9Crequired=E2=80=9D = to have? What do you see as reasonable numbers there, for the near term = and long term? > With the multi-SCT approach, the amount of bandwidth consumed during = TLS negotiation with every CT-supporting website increases linearly with = n. With the scalable multisignature approach, n can increase to = arbitrarily large size - a hundred, a thousand if needed - e.g., = including all the public auditors, monitors, etc. - without any increase = in the size of certificates, number of SCTs attached, or ultimately the = bandwidth/latency overhead during TLS negotiation. >=20 > To be clear, you are proposing that instead of n logs with 1 signer = each, we have 1 log with n signers? Possibly but not necessarily. I envision n logs with m signers each, = where say 1 <=3D n <=3D 10, but 10 <=3D m <=3D 1000. (And different log = servers need not have the same signers, or even the same number of = signers.) > That seems unwise to me. You then have a SPOF for the whole network. If a single log server cannot sign anything without it being witnessed = and validated by 10, 100, or 1000 signers, how is it a SPOF? Again, = I=E2=80=99m not saying n should be 1 - there are good reasons we might = still want n to be greater than 1. But if each log server can=E2=80=99t = produce a valid STH without the active participation of a quorum of its = m signers, and a reasonable number of those co-signers at least do = minimal checking to ensure that the log server is behaving like a log = (e.g., never signing two STHs with the same sequence number), then = there=E2=80=99s a lot less a misbehaving log server - or an attacker who = compromises that log server=E2=80=99s key - can do with it. > But clearly each log could have more than one signer, but still have = multiple logs. Then the question is: where is the trade off between = number of logs and number of signers, bearing in mind that more than one = signer introduces substantial complication. As I pointed out before, the problem with the current model is that = adding log servers *decreases* security, at least in certain realistic = attack scenarios, by giving the attacker more possible log server = targets to compromise. Weakest-link security, just as in the current CA = system. Whereas increasing m, the number of signers per log server, can = only increase security, assuming the multi-signing protocol/crypto = itself isn=E2=80=99t broken. B= --Apple-Mail=_0B95B546-66BF-49CE-83E1-3A699C091BC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 6, 2015, at 8:56 AM, Ben Laurie <benl@google.com> = wrote:
On = Thu, 6 Aug 2015 at 10:17 Bryan Ford <brynosaurus@gmail.com> wrote:
On Jul = 24, 2015, at 1:09 PM, Ben Laurie <benl@google.com> wrote:
On Thu, 23 Jul 2015 at 23:27 Bryan Ford <brynosaurus@gmail.com> = wrote:
=
Second, the gossip approach can=E2=80=99t ensure that = privacy-sensitive Web clients (who can=E2=80=99t or don=E2=80=99t want = to reveal their whole browsing history to a Trusted Auditor) will ever = actually be able =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, if = for example the misbehaving log=E2=80=99s private key is controlled by a = MITM attacker between the Web client and the website the client thinks = he is visiting.

The intent of CT is not to enable = clients to detect such behaviour - rather, it is to enable the system as = a whole to detect it.

Could you = explain how =E2=80=9Cthe system as a whole=E2=80=9D detects such = misbehavior in the case of the state/ISP-level MITM attacker scenario? =  

The state or ISP must isolate all = clients they attack forever to avoid detection. In practice, this does = not generally seem to be possible.
 
As I see it, if the client/browser doesn=E2=80=99= t opt-out of privacy by gossiping his browsing history with a trusted = auditor, then the client=E2=80=99s *only* connection to the rest of the = world, i.e., = =E2=80=9Cthe 
system as a whole=E2=80=9D, is through the =E2=80=9Cweb = server=E2=80=9D, which may well be the same kind of MITM attackers that = have been known to subvert the CA system.  The client never gets to = communicate to the rest of the system - i.e., the legitimate CT log = servers, auditors, or monitors - and so the client never gets the = opportunity to =E2=80=9Ccompare notes=E2=80=9D with the rest of the = system.  And the rest of the system (the legitimate log servers, = auditors, and monitors) never have the opportunity to learn from the = client that the client saw a MITM-attacked, forged set of CA certs, = STHs, and SCTs.

This is correct, and seems to me to be = correct for any system - if you can isolate your victim forever, you can = show your own view of any system.

To reiterate the key point I made in my response = to Tom=E2=80=99s E-mail, this is not true of the multisignature-based = STH signing I suggested.  Suppose for each CT log server there are = (for example) 100 monitor servers widely distributed around the world, = run by diverse companies, governments, etc.  And suppose that any = STH must be collectively signed by the log server and at least 51 of its = monitor servers in order for clients to consider it valid.  Assume = the victim user/browser is isolated behind a MITM attacker (call it = Repressistan) who controls all the paths in and out of Repressistan and = never lets the user physically enter or leave Repressistan.  Thus = the user never has opportunity to do CT gossip via any path not = controlled by the Repressistani Firewall.  In CT=E2=80=99s current = design, Repressistan wins - gaining the ability to silently compromise = the user forever - simply by Pwning one CA key and one log server key. =  (Or maybe two if you require two SCTs per cert.) =  

In the multisignature = approach, Repressistan gains the ability to forge a STH for a = =E2=80=9Cclient-customized world view" only if Repressistan can also = compromise more than 50 monitors of a compromised log server=E2=80=99s = collective signing pool.  Every valid, client-verifiable STH = signature ensures to the client not only that the log server=E2=80=99s = key signed the STH but also that at least 51 monitor servers also = witnessed it (even if those monitors are doing no checking at all other = than saying =E2=80=9CI saw it=E2=80=9D).  Repressistan can no = longer forge a valid (above-threshold) STH signature without an = inconceivably massive collusion or security breach.  Repressistan = still simply prevent the user from communicating at all, of course, but = loses the ability either to silently compromise the connection or = silently evade detection.  And the client need not risk its privacy = via gossip in any way to receive this protection.

Suppose, for example, it ever so happens that = a single company ends up running both a log server and a [sub-]CA, and = keeps both in the same poorly-protected safe.  If an attacker can = steal those two private keys, then the attacker can silently MITM any = CT-aware client all it wants, by producing all the [non-EV] certificates = it needs with a valid SCT, valid STH inclusion proofs in a fake log, = etc.

Chrome's policy would require the = subversion of at least two logs to achieve this, but for the sake of = argument, I'll concede that.

I= thought you were requiring CAs to have multiple SCTs only for EV = certificates, no?  What if the attacker is happy to MITM attack the = user with a non-EV certificate and forego showing the user the =E2=80=9Cgr= een bar=E2=80=9D?  Are you assuming that users will stop using the = connection if they don=E2=80=99t see the green = bar?

Not at all. EV certificates are our = first step for CT.
 
Or= are you saying (contrary to my prior understanding) that Chrome = requires *all* CT certs to have multiple SCTs signed by different log = servers?

Chrome makes no requirement on "CT = certs", only on EV certs. But in the long run, the intention is to = require CT for all certs.

But what does =E2=80=9Crequiring CT=E2=80=9D mean = in terms of the number of SCTs a given cert (EV or non-EV) will be = =E2=80=9Crequired=E2=80=9D to have?  What do you see as reasonable = numbers there, for the near term and long term?

With the multi-SCT approach, the amount of = bandwidth consumed during TLS negotiation with every CT-supporting = website increases linearly with n.  With the scalable = multisignature approach, n can increase to arbitrarily large size - a = hundred, a thousand if needed - e.g., including all the public auditors, = monitors, etc. - without any increase in the size of certificates, = number of SCTs attached, or ultimately the bandwidth/latency overhead = during TLS negotiation.

To be clear, you are = proposing that instead of n logs with 1 signer each, we have 1 log with = n signers?

Possibly but not necessarily.  I envision n = logs with m signers each, where say 1 <=3D n <=3D 10, but 10 <=3D= m <=3D 1000.  (And different log servers need not have the same = signers, or even the same number of signers.)

That seems unwise to me. You then = have a SPOF for the whole = network.

If = a single log server cannot sign anything without it being witnessed and = validated by 10, 100, or 1000 signers, how is it a SPOF?  Again, = I=E2=80=99m not saying n should be 1 - there are good reasons we might = still want n to be greater than 1.  But if each log server can=E2=80=99= t produce a valid STH without the active participation of a quorum of = its m signers, and a reasonable number of those co-signers at least do = minimal checking to ensure that the log server is behaving like a log = (e.g., never signing two STHs with the same sequence number), then = there=E2=80=99s a lot less a misbehaving log server - or an attacker who = compromises that log server=E2=80=99s key - can do with it.

But clearly each log could have = more than one signer, but still have multiple logs. Then the question = is: where is the trade off between number of logs and number of signers, = bearing in mind that more than one signer introduces substantial = complication.

As I pointed out before, the problem with the = current model is that adding log servers *decreases* security, at least = in certain realistic attack scenarios, by giving the attacker more = possible log server targets to compromise.  Weakest-link security, = just as in the current CA system.  Whereas increasing m, the number = of signers per log server, can only increase security, assuming the = multi-signing protocol/crypto itself isn=E2=80=99t = broken.

B
= --Apple-Mail=_0B95B546-66BF-49CE-83E1-3A699C091BC3-- --Apple-Mail=_ADE35D3E-7E1E-4E6C-8FA2-5413F1B81702 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA4MDgxNzI1NDFaMCMGCSqGSIb3DQEJBDEWBBQow918svbPGyhbqIi62IaeOCPVcjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAAYvevBUuXs3KjqamOfMREqi5jHVjstPNFO8wxwPbHg5PE9jeN2bOzfJTGiiC4awD usVnsF1nRFpi5atv5V8UHYSr0qpYoxXI8XiiPaSiH1xUh+6zd1ZdNlsHUMib86WSXnR0cgtS9+WR y4X1beXSML1yfzObTyZ3XHkAL9livElSA/6xN/1nOfeL1WUQDqoAVVtvMpZW4CocM7/kD/YiExYd t904D3TtLQUfK3fg7GuGnyx7OYSDTI53M051IwAXk9MlDKtT7UB8Q7HnE/ir9bSzbiArFGF2j3ts afQudFRv5onuvYAwdIZrBQJf9ED6wzwG8RoMTf7/jG6MpMXvZAAAAAAAAA== --Apple-Mail=_ADE35D3E-7E1E-4E6C-8FA2-5413F1B81702-- From nobody Sun Aug 9 06:41:27 2015 Return-Path: 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 CC1991B2CED for ; Sun, 9 Aug 2015 06:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 mEsxOlihSqei for ; Sun, 9 Aug 2015 06:41:24 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 ADAE31B2CEC for ; Sun, 9 Aug 2015 06:41:23 -0700 (PDT) Received: by qkbm65 with SMTP id m65so50945386qkb.2 for ; Sun, 09 Aug 2015 06:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=wPwNLekwgWttaT9fLagLUK4CbO3AWs53J6Q6w07eizs=; b=opi4qoElI1xmEZRlVnRWOH8BSS6aK2/nviLOXyrcaKlNzLVFRET1A+61y2PU+6smgj Fp3LN4WiXXYiPfYr9qSzTpiK0BICGVN+IJq4dK/unP7INOxCAaPF9Zp7IIGjOBqTt6z0 oWKvTYc36ln/zYASqJ8xgAy1mSlHNgojMbydZOZlbtFT8ny2s6fL6acxxZYzSM65mTrp 82kUtga8j69hQU1j3Hzxgz9Vo45W+EYxkZjQK8hARcODgZVn8BWAQQUjZOzHa1U1TWws x9XjKsEL99MxzdQ8FEzT/oyzZztIwPn9lk4t0nPNeghQl244rfJzPP6T2P4Le2uIwVkk h+Fg== X-Received: by 10.55.16.209 with SMTP id 78mr29604465qkq.81.1439127682879; Sun, 09 Aug 2015 06:41:22 -0700 (PDT) Received: from [172.20.2.154] ([12.139.225.10]) by smtp.gmail.com with ESMTPSA id b196sm8237365qka.14.2015.08.09.06.41.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Aug 2015 06:41:22 -0700 (PDT) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_52E01D64-A3E7-436B-BA5D-E0E03E3875DA"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <30A8C7DD-B87D-4095-AAFF-FB63EA01D292@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Date: Sun, 9 Aug 2015 09:41:28 -0400 References: To: trans@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [Trans] Gossip draft CFA closed X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 13:41:26 -0000 --Apple-Mail=_52E01D64-A3E7-436B-BA5D-E0E03E3875DA Content-Type: multipart/alternative; boundary="Apple-Mail=_94C58042-D0D4-46DE-A21A-CA45D1FCF645" --Apple-Mail=_94C58042-D0D4-46DE-A21A-CA45D1FCF645 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Melinda, > From: Melinda Shore > Subject: [Trans] Gossip draft CFA closed > Date: August 7, 2015 at 3:02:28 PM EDT > To: "trans@ietf.org" , = draft-linus-trans-gossip-ct@ietf.org >=20 >=20 > Hi, all: >=20 > Thank you for your feedback on the call for working group > adoption of draft-linux-trans-gossip-ct. It's very clear > that there's widespread support for adoption, and that we've > both got people to work on the draft and to review it. Bryan > Ford raised some technical issues during the discussion but > those have been resolved (future revisions of the draft should > include some text clarifying the conditions under which the > data will be gossiped and what problems gossip is *not* > intended to solve). I must object to your conclusion that the =E2=80=9Ctechnical issues=E2=80=9D= I brought up during the discussion =E2=80=9Chave been resolved=E2=80=9D = - at any rate, I consider them neither purely =E2=80=9Ctechnical = issues=E2=80=9D nor having =E2=80=9Cbeen resolved=E2=80=9D, as should be = eminently clear from my E-mails on the topic. As I stated clearly earlier, I feel that the entire gossip approach is = fundamentally flawed. It=E2=80=99s not just some technical issues = within the draft that can be easily fixed, but the whole approach. My = concerns are with the strategy, not just minor =E2=80=9Ctechnical = issues=E2=80=9D. And similarly, I do not see how it can be concluded from the E-mail = discussion that my concerns =E2=80=9Chave been resolved=E2=80=9D (or = even addressed). =20 Any approach will add complexity to the system: a gossip protocol will, = and a multisignature approach will. Have the advantages, disadvantages, = and relative complexities of each of these approaches been weighed and = considered in any way? Or was it somehow just =E2=80=9Cassumed as a = given=E2=80=9D since before I started participating that gossip was the = right approach and no one is interested in questioning that now? I=E2=80=99ll grant that no one else on the list seems to be echoing my = concerns with the gossip approach at the moment - so if you wish to = close the call for adoption anyway over my objections, please feel free = to do so; I assume that=E2=80=99s what the =E2=80=9Crough=E2=80=9D in = =E2=80=9Crough consensus=E2=80=9D is for. But please do not = mischaracterize my position as merely having raised =E2=80=9Csome = technical issues=E2=80=9D that =E2=80=9Chave been resolved.=E2=80=9D Bryan --Apple-Mail=_94C58042-D0D4-46DE-A21A-CA45D1FCF645 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Melinda,

From: = Melinda Shore <melinda.shore@gmail.com>
Subject: = [Trans] Gossip = draft CFA closed
Date: August 7, 2015 at 3:02:28 PM EDT
To: = "trans@ietf.org" <trans@ietf.org>, draft-linus-trans-gossip-ct@ietf.org


Hi, all:

Thank you for your feedback on the call for = working group
adoption of draft-linux-trans-gossip-ct. =  It's very clear
that there's widespread support for = adoption, and that we've
both got people to work on the = draft and to review it.  Bryan
Ford raised some = technical issues during the discussion but
those have been = resolved (future revisions of the draft should
include = some text clarifying the conditions under which the
data = will be gossiped and what problems gossip is *not*
intended = to solve).

I must object to your conclusion that the = =E2=80=9Ctechnical issues=E2=80=9D I brought up during the discussion = =E2=80=9Chave been resolved=E2=80=9D - at any rate, I consider them = neither purely =E2=80=9Ctechnical issues=E2=80=9D nor having =E2=80=9Cbeen= resolved=E2=80=9D, as should be eminently clear from my E-mails on the = topic.

As I stated clearly earlier, = I feel that the entire gossip approach is fundamentally flawed. =  It=E2=80=99s not just some technical issues within the draft that = can be easily fixed, but the whole approach.  My concerns are with = the strategy, not just minor =E2=80=9Ctechnical issues=E2=80=9D.

And similarly, I do not see how it can be = concluded from the E-mail discussion that my concerns =E2=80=9Chave been = resolved=E2=80=9D (or even addressed).  

Any approach will add complexity to the system: a = gossip protocol will, and a multisignature approach will.  Have the = advantages, disadvantages, and relative complexities of each of these = approaches been weighed and considered in any way?  Or was it = somehow just =E2=80=9Cassumed as a given=E2=80=9D since before I started = participating that gossip was the right approach and no one is = interested in questioning that now?

I=E2=80=99ll grant that no one else on the list = seems to be echoing my concerns with the gossip approach at the moment - = so if you wish to close the call for adoption anyway over my objections, = please feel free to do so; I assume that=E2=80=99s what the =E2=80=9Crough= =E2=80=9D in =E2=80=9Crough consensus=E2=80=9D is for.  But please = do not mischaracterize my position as merely having raised =E2=80=9Csome = technical issues=E2=80=9D that =E2=80=9Chave been = resolved.=E2=80=9D

Bryan

= --Apple-Mail=_94C58042-D0D4-46DE-A21A-CA45D1FCF645-- --Apple-Mail=_52E01D64-A3E7-436B-BA5D-E0E03E3875DA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA4MDkxMzQxMjhaMCMGCSqGSIb3DQEJBDEWBBSeuuWwMa1Os3/ncZCQgtRRlUhnxDCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAighN0BAxrinVGDiop0S7wfvq6YT4H2frV/hGISKjp5CHgDY0e+NuzctsZtw4snHN Yz9FUVmUHHIW18ldI7FotGkpDhZ4A+u7bY3hllc+cHOcAlVqgqhcr9FqunghFOXENApsLiNhuMOz u2GeGqYM7STrFrRLT+QJ9/klDLNDJaycz7kj5GbL1jhvIR2hplutK/AIxc3z1ruihEplPr7vcOc2 1v2cUzYpPY51BXebaAkj/j5BXVRLUJWP/jyHBy0vAYaRJ1DmpzKYOyfcnGvehv/iUT8AlMANGdV/ KNa+5uKvDVfhRTpS3OYY70Qv0Wb0SdgQTsUwfJm4pnFiqV+udQAAAAAAAA== --Apple-Mail=_52E01D64-A3E7-436B-BA5D-E0E03E3875DA-- From nobody Mon Aug 10 03:33:33 2015 Return-Path: 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 90A931B3432 for ; Mon, 10 Aug 2015 03:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5N3DQlqCOSyw for ; Mon, 10 Aug 2015 03:33:26 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 08CF61B3433 for ; Mon, 10 Aug 2015 03:28:16 -0700 (PDT) Received: by ykdz80 with SMTP id z80so23986281ykd.2 for ; Mon, 10 Aug 2015 03:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=loGPyvEDvQxCKMs8LgpccYvqCPNpy/nS6KqhxvonxxQ=; b=hTnjNQlFigEcS3v8rvYRB0NVlIpiQSOCIKXBPHWykLfVzxsXOvF+o9Rwim+/qabBZM MNQflSK11mBqIZmcqG+Q2kITLHucI8It0Oyfk957YJ8C1t4ZC5ZMbvaHJAR2SKEq6ZWx V3kzs6u5ajM0igX+Sa9RpzN1GJCx1VottASn1jh+D0Vj/DiaC4+o6Ew7S3tpgQV+2E+k lDp00VkFTSi6JDnLymM2ems18BUntF88c+vVgYHHgNf1f1gRTCIEhvffFA7BwP4S0H5G S/YjV7r+m6k1W4AwUdwtFSXsVWc8N6XXH+I7QocF55FZCDcjH2U5JtEZDK9H6AkGhfrO VkHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=loGPyvEDvQxCKMs8LgpccYvqCPNpy/nS6KqhxvonxxQ=; b=e+KnvyZVcv+TMqOtrZcjDLKPsArWYxmbU0JcqTbAHwXQn1eKQUFqHgHFq+mzImakmW nzP/EPyTMuY+imUx1THtqcHhIabOzbgQU9JR92sgnnbVHvvG3r9/eAw4ujFCxKHyjwOJ 30Q+fSONwrkiXOc3K0em5QfYujMwdJWCQAoXGBNMaFIpXc2S+OvSPhWTMw5xvxmD+B00 4PFvoTmTeuGcVxkcwxItH5m7wAaJvhfPe3v8VtiqAfWjQrX7qc2V2dwwHaF54XQ2/tpS Zu47BQ8brskfex2EHTABUrSkpPwbPAJoYshetS6Q1BpPItBpSsEUJCXvJYNT4pW/wWVX bnxQ== X-Gm-Message-State: ALoCoQnxcVi+ik4LXl2Pl3xRtJM6v5W+8himGc7dT3GM0joT5MtnX6yq3S0lfvPx3WgD2iXZnytN X-Received: by 10.13.254.70 with SMTP id o67mr20957800ywf.88.1439202495310; Mon, 10 Aug 2015 03:28:15 -0700 (PDT) MIME-Version: 1.0 References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> In-Reply-To: From: Ben Laurie Date: Mon, 10 Aug 2015 10:28:05 +0000 Message-ID: To: Bryan Ford , Tom Ritter Content-Type: multipart/alternative; boundary=94eb2c07e7267e6ca3051cf2710f Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 10:33:31 -0000 --94eb2c07e7267e6ca3051cf2710f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 8 Aug 2015 at 17:56 Bryan Ford wrote: > Hi Tom, > > On Aug 6, 2015, at 11:46 AM, Tom Ritter wrote: > > Thanks for this Bryan. I'm going to echo Ben a bit: > > On 6 August 2015 at 02:17, Bryan Ford wrote: > > It creates new privacy problems by requiring the client (browser user) to > =E2=80=9Copt out=E2=80=9D of web browsing privacy in order to gain any se= curity benefit. > Either the user hands over all his browsing history to a remote =E2=80=9C= trusted > auditor=E2=80=9D, thereby opting out of privacy; or else the user remains= fully > vulnerable to the same kind of (potentially extended) MITM attacks that > motivated CT in the first place. > > > If the Trusted Auditor mode is a default that requires Opting Out > instead of Opting In I think I speak for every author when I say we > will have considered this a huge failure and will rally against it as > much as we can. > > > Agreed. With that in mind, would it be reasonable to include text to thi= s > effect in the =E2=80=9Cgossip=E2=80=9D draft if it is adopted? For examp= le, > =E2=80=9CImplementations of CT must ensure that Trusted Auditor relations= hips are > =E2=80=98opt-in=E2=80=99 relationships require the explicit consent of th= e user, and not a > bundled system default=E2=80=9D or something like that? > We already decided for the main CT I-D that client behaviour of this kind is out of scope. Also, as previously mentioned, not all clients have privacy concerns (or users, necessarily). > Could you explain how =E2=80=9Cthe system as a whole=E2=80=9D detects suc= h misbehavior in > the case of the state/ISP-level MITM attacker scenario? > > As I see it, if the client/browser doesn=E2=80=99t opt-out of privacy by = gossiping > his browsing history with a trusted auditor, then the client=E2=80=99s *o= nly* > connection to the rest of the world, i.e., =E2=80=9Cthe system as a whole= =E2=80=9D, is > through the =E2=80=9Cweb server=E2=80=9D, which may well be the same kind= of MITM attackers > that have been known to subvert the CA system. The client never gets to > communicate to the rest of the system - i.e., the legitimate CT log > servers, > auditors, or monitors - and so the client never gets the opportunity to > =E2=80=9Ccompare notes=E2=80=9D with the rest of the system. And the res= t of the system > (the legitimate log servers, auditors, and monitors) never have the > opportunity to learn from the client that the client saw a MITM-attacked, > forged set of CA certs, STHs, and SCTs. > > > In SCT Feedback the only connection to disclose data about Website A > is indeed website A. > In STH Feedback, assuming the client can resolve a Cert to a STH via > an inclusion proof (which we currently suggest via DNS, but other > mechanisms can exist, such as Tor) - that STH will be pollinated to > _any_ website. And the split-view log will be caught. So that's how > the 'system as a whole' detects the issue. > > > OK, I see how STH pollination can at least raise the bar significantly fo= r > MITM attackers in a way that SCT feedback can=E2=80=99t. But it still se= ems > neither sufficient, nor the best we can do, nor convincingly =E2=80=9Csaf= e=E2=80=9D in > terms of privacy; see below. > > The difference is of course because the SCT is private data that > reveals browsing history, the STH is not (not counting old-STH attacks > which we mitigate). > > > I see there is already some text in the gossip draft acknowledging the > privacy risks that =E2=80=9Cpromiscuous=E2=80=9D STH pollination, but the= current text > doesn=E2=80=99t go far enough and underestimates the risk. For example, = by the > calculations in the text, suppose a malicious HTTPS server has up to 336 > unique STHs per log that it could use to =E2=80=9Ctag=E2=80=9D and track = clients over > time. Supposing there are 10 well-known log servers, this is 3360 unique > STHs total. The current text seems to suggest that this is =E2=80=9Csmal= l enough=E2=80=9D, > which may be true in the one particular attack the text suggests earlier, > namely that the attacker picks one particular less-popular (e.g., > somewhat-old) STH to give a client it wishes to track. > How does it then track it? Also, the client then either reconciles the STH with a newer one (or perhaps already has done so) and discards it, or it gossips it, meaning other clients will start mentioning this "rare" STH. > But this is not the =E2=80=9Creal=E2=80=9D attack of interest: a just sli= ghtly smarter > attacker would probably use the presence or absence of these less-popular > STHs in a client=E2=80=99s gossip cache as (noisy) bits in a tracking ide= ntifier. > The attacker would gossip to each client it hasn=E2=80=99t seen before so= me kind of > ECC-encoded pattern of less-popular STHs. Thus, the 3360 unique STHs the > attacker gets to play with do not represents =E2=80=9Cthe number of clien= ts the > attacker can track=E2=80=9D as the current text seems to suggest, but rat= her the > 3360 unique STHs may in fact be =E2=80=9Ctracking tag bits=E2=80=9D that = the attacker gets > to play with in attempting to imprint clients with tracking tags via > gossip. And 3360 bits is a lot of bits: plenty of room for a highly-uniq= ue > (say 64-bit) per-client tag to be encoded in a high-expansion, rather > noise-tolerant encoding. > I'd be interested to see how this kind of attack would actually work out in practice, especially given there are some relatively simple countermeasures= . a) Cache old STHs so they can be dropped immediately. b) Always attempt to reconcile received STHs before gossiping them. > > Of course, a user could still avoid being tracked in this fashion by usin= g > a stateless, =E2=80=9Camnesiac=E2=80=9D browsing platform like Tails, whi= ch would > presumably start with an empty STH cache on each boot. But this would al= so > defeat CT=E2=80=99s ability to use STH polination to detect MITM attacks = across > client/browser sessions. > I don't think that's correct. Detection can be done by any participant, so all that is needed is for the browser to gossip at least once. > > If an attacker can both persistently MITM someone to a website (or the > whole internet) and DoS the STH lookup mechanism (and compromise a log > and a CA) - yes, the attacker wins. > > Attackers who can persistently MITM users forever are extremely > powerful and we have no way to defend against them except to make all > your client software just stop working. > > > Attackers who can persistently MITM users forever are indeed extremely > powerful but are not at all unrealistic, given the increasing presence of > Great Firewall type attackers (and all the smaller wanna-be knockoffs), > which can indeed persistently control the =E2=80=9Cnetworked view of the = world=E2=80=9D > seen by any user who cannot or does not regularly travel internationally. > That doesn't seem to be the case, in practice. > > I disagree that we have no way to defend against them; if you think so > you=E2=80=99re giving up too quickly. Of course such an attacker can sim= ply block > or DoS all the user=E2=80=99s communication in any case, but in practice = most of > these attackers would rather let the client think they=E2=80=99re communi= cating > securely while silently compromising them. CT with gossip cannot even > guarantee that such silent, persistent MITM attacks will ever even be > detected (by anyone), let alone prevented. But the multi-signed STH > approach I suggested would do exactly that. > I don't see how - both are numbers games. There's nothing in multi-signing that provides strong guarantees, just statistical ones. > Since the pervasive MITM attacker would be unable to forge a single vali= d > STH signature the client will accept without compromising a large quorum = of > monitor/witness/co-signer servers as well, the attacker is left with the > choice of remaining silent and leaving the client=E2=80=99s communication > uncompromised, or denying/blocking the communication entirely. I claim > that such a situation would be much, much preferable to the current state > of affairs even with CT deployed. > If we tone down your rhetoric to admit the fallibility of your scheme, then in principle I think its worth exploring, but: a) We still need gossip, b) There are architectural issues I mention in my previous email that need resolving. > > This applies to the CA system > absent CT, it requires to the CA system with CT, and it applies to > software updates. If you can write exploits, but not find bugs - just > wait for a patch to come out, block the update, take your leisurely > time reverse engineering, writing the exploit, and using it. > > > Of course client-side software security is a huge and important problem i= n > itself, but it=E2=80=99s orthogonal to the design of CT. I have plenty o= f thoughts > on how multi-signing or cothorities could be used to improve the situatio= n > there as well, but that=E2=80=99s another topic. > > I don't mean to dismiss this concern, but a) I don't believe SCT > Feedback and STH Pollination cause privacy problems > > > See above. > > b) This problem is > so hard that no one is attempting to defend against it > > > I am; see above. > > c) History > suggests such attackers are not all-powerful. > > > Agreed, such attackers are not all-powerful, but pretty much any > compromised or state-controlled ISP is certainly powerful enough to > persistently MITM any client that always connects through that ISP > Eh? You have to also compromise a CA and some logs, as well as own the ISP. And you have to MITM all protocols (I am assuming that over time gossip will be a multi-protocol thing). > - which is true at least of (a) desktop machines on a home or work networ= k > always attached via the same connection, and (b) smartphones roaming with= in > a country but always using a data plan through the same cellular ISP. > These threat models do not seem unrealistic to me, but rather quite > ubiquitous. > > Or at least, we've > caught a lot of folks who could have gotten away with it that > supposedly had that capability and could have known better. > > > Yes, a lot of current attackers have been sloppy in one way or another, > but that doesn=E2=80=99t mean we should assume the they will not learn fr= om their > past mistakes and adopt less sloppy attacks in the future. They will. > > Or are you saying (contrary to my prior understanding) that Chrome requir= es > *all* CT certs to have multiple SCTs signed by different log servers? > > > As Ben said, the end goal is to use it for everything. > > > What is the =E2=80=9Cit=E2=80=9D to be used for everything? CT? Or CT w= ith a mandatory > minimum of >1 SCTs? And again, what do you think a reasonable mandatory > minimum number of SCTs would be? Two, five, ten, 100? If it starts at 1 > or 2 for pragmatic reasons, will it ever increase or will it stay forever > at 2 due to inertia? Is that good enough? > > I don't know > when we'll get there, but in the interim there will probably be a > period of opt-in: > https://ritter.vg/blog-require_certificate_transparency.html > > > Nice blog post, but I don=E2=80=99t see where it addresses the issue of h= ow many > independent SCTs a browser should expect/require a cert to have even if i= t > does decide to demand CT support. > > The Comodo incident you reference, was that the mozilla.com cert in > 2008? That was someone just trying a RA portal and getting a cert: > http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ > > > Despite all the effort to find such certs manually, via MEKAI, > Perspectives, Convergence, Cert Patrol, and others - I'm not aware of > anyone ever catching a CA-signed misissued cert manually. > > > I think it was the March 2011 incident, where a hacker was able to obtain > fraudulent certificates through Comodo and then apparently attempted to u= se > at least one of them, for =E2=80=98login.yahoo.com=E2=80=99, in some way: > https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html Comodo=E2= =80=99s > report and the other information I found don=E2=80=99t make it clear exac= tly in > what way the login.yahoo.com cert was =E2=80=9Cseen live on the Internet= =E2=80=9D - > perhaps it was Google pinning as well if Google was pinning Yahoo=E2=80= =99s certs > at that time (were they?), or perhaps it was manual forensics. Perhaps y= ou > or someone else has better information about this. But this is all > incidental: it=E2=80=99s great that Google pinning has caught a lot of in= cidents, > but nobody seems to be saying that means Google pinning is the best/final > solution. > In this case, though, CT would have caught the mis-issue. > > With the multi-SCT approach, the amount of bandwidth consumed during TLS > negotiation with every CT-supporting website increases linearly with n. > With the scalable multisignature approach, n can increase to arbitrarily > large size - a hundred, a thousand if needed - e.g., including all the > public auditors, monitors, etc. - without any increase in the size of > certificates, number of SCTs attached, or ultimately the bandwidth/latenc= y > overhead during TLS negotiation. > > > While we aim to keep SCTs small as Ben indicated - yes, sending 10 > would be quite a bit. I'm not sure of a great answer here.. I think > the onus is kind of on the community to curate and run a fewer number > of high-quality, mutually distrusting, different-juristictional logs. > > > This is precisely my point: by architecturally relying on multiple SCTs > per cert we=E2=80=99re tying ourselves into the same bad old security tra= deoff of > having to trust a few =E2=80=9Chigh-quality, mutually distrusting, > different-jurisdictional logs=E2=80=9D - i.e., a few conventional central= ized > authorities. How do you choose them? Who chooses them? Do you let one = of > those 10 be run by (say) Iran or Syria, in the interest of diversity (at > least they=E2=80=99re probably not colluding with the Five Eyes countries= !) - even > though their governments have a record of trying to MITM their users ( > https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-h= ttps, > https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook) > and can probably be expected to try to exploit their control over =E2=80= =9Ctheir=E2=80=9D > log server in any way the CT architecture allows them to (such as > persistent MITM attacks as discussed above)? > Now you seem to be claiming that it is possible to persistently MITM an entire nation. I find that difficult to swallow. > > With the scalable multi signing, in contrast, we could have 10 or 100 or > 1000 monitor/co-signer servers contributing to each STH signature with *n= o* > cost to client verification time, client CPU costs, TLS startup bandwidth > consumed, etc. One quite reasonable policy might be that *every* country > that is technically capable of running a monitor/co-signer server could > join and participate in the signing process of every STH of every > well-known log. If you=E2=80=99re claiming that it=E2=80=99s infeasible = to decentralize > trust in such a service beyond 10 or so well-known nodes, again I think > you=E2=80=99re just giving up and conceding the field too quickly. > > 2. Our original design for CT did indeed have certs served along with an > STH > and an inclusion proof. Unfortunately, CAs categorically rejected this > approach because of the latency it introduced in the certificate issuance > process. Personally, I think it would be a better approach. Now CAs are > more > accepting of CT, perhaps it would be worth revisiting the question with > them? > > > Agreed, that would be great. > > > I am most excited about the prospect of sending an inclusion proof to > a recent STH to the client - but I don't actually think the cert is > the answer. I think it's a TLS extension or (better) an OCSP staple. > Doing this would eliminate what I think is the weakest part of the > gossip document - the requirement to obtain a STH from a SCT (well a > cert) via some 'privacy preserving manner'. (Which we, again, > theorize to be DNS, but I don't think that's the answer for everyone.) > > > Agreed on this. In fact, it=E2=80=99s increasingly unclear to me what se= curity > purpose SCTs actually serve if it indeed ends up that the =E2=80=9Creal= =E2=80=9D security > CT provides is eventually going to revolve mainly around STHs and inclusi= on > proofs. Out of curiosity, has anyone floated or elaborated on the idea o= f > what CT would look like if simplified not to rely on SCTs at all? > I believe I already mentioned that the original plan was to use inclusion proofs, not SCTs. CAs did not like the consequent delay in certificate issuance. > > If the STH was included in the Cert, that doesn't really change the game > for me. > 1) The STH could be a STH on the split view of the log, so the > immediate-decision security is no better that just sending a SCT. > 2) The STH is too old. I don't want clients pollinate old STHs, > because as time goes on, old STHs will be rarer and will be indicative > of what website you visited. After 2.5 years there will only be 100? > 1000? popular websites with that STH in the cert. So the old STH needs > to be resolved to a recent STH, and you pollinate _that_. > > > Agreed again. > > B > > > -tom > > > --94eb2c07e7267e6ca3051cf2710f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat= , 8 Aug 2015 at 17:56 Bryan Ford <brynosaurus@gmail.com> wrote:
Hi Tom,

<= /div>
On Aug 6, 2015, at 11:46 AM, Tom Ritter <tom@ritter.vg> wrote:

Thank= s for this Bryan.=C2=A0 I'm going to echo Ben a bit:

On 6 August= 2015 at 02:17, Bryan Ford <brynosaurus@gmail.com> wrote:
It creates new privacy problems by requiring the client (browser user= ) to
=E2=80=9Copt out=E2=80=9D of web browsing privacy in order to gain = any security benefit.
Either the user hands over all his browsing histor= y to a remote =E2=80=9Ctrusted
auditor=E2=80=9D, thereby opting out of p= rivacy; or else the user remains fully
vulnerable to the same kind of (p= otentially extended) MITM attacks that
motivated CT in the first place.<= br>

If the Trusted Auditor mode is a default that requires = Opting Out
instead of Opting In I think I speak for every author when I = say we
will have considered this a huge failure and will rally against i= t as
much as we can.

Agreed.=C2=A0 With t= hat in mind, would it be reasonable to include text to this effect in the = =E2=80=9Cgossip=E2=80=9D draft if it is adopted?=C2=A0 For example, =E2=80= =9CImplementations of CT must ensure that Trusted Auditor relationships are= =E2=80=98opt-in=E2=80=99 relationships require the explicit consent of the= user, and not a bundled system default=E2=80=9D or something like that?

We already decided fo= r the main CT I-D that client behaviour of this kind is out of scope.
=

Also, as previously mentioned, not all clients have pri= vacy concerns (or users, necessarily).


Could you explain how =E2=80= =9Cthe system as a whole=E2=80=9D detects such misbehavior in
the case o= f the state/ISP-level MITM attacker scenario?

As I see it, if the cl= ient/browser doesn=E2=80=99t opt-out of privacy by gossiping
his browsin= g history with a trusted auditor, then the client=E2=80=99s *only*
conne= ction to the rest of the world, i.e., =E2=80=9Cthe system as a whole=E2=80= =9D, is
through the =E2=80=9Cweb server=E2=80=9D, which may well be the = same kind of MITM attackers
that have been known to subvert the CA syste= m.=C2=A0 The client never gets to
communicate to the rest of the system = - i.e., the legitimate CT log servers,
auditors, or monitors - and so th= e client never gets the opportunity to
=E2=80=9Ccompare notes=E2=80=9D w= ith the rest of the system.=C2=A0 And the rest of the system
(the legiti= mate log servers, auditors, and monitors) never have the
opportunity to = learn from the client that the client saw a MITM-attacked,
forged set of= CA certs, STHs, and SCTs.

In SCT Feedback the only con= nection to disclose data about Website A
is indeed website A.
In STH = Feedback, assuming the client can resolve a Cert to a STH via
an inclusi= on proof (which we currently suggest via DNS, but other
mechanisms can e= xist, such as Tor) - that STH will be pollinated to
_any_ website.=C2=A0= And the split-view log will be caught. So that's how
the 'syste= m as a whole' detects the issue.

<= /div>
OK, I s= ee how STH pollination can at least raise the bar significantly for MITM at= tackers in a way that SCT feedback can=E2=80=99t.=C2=A0 But it still seems = neither sufficient, nor the best we can do, nor convincingly =E2=80=9Csafe= =E2=80=9D in terms of privacy; see below.

The = difference is of course because the SCT is private data that
reveals bro= wsing history, the STH is not (not counting old-STH attacks
which we mit= igate).

I see there is already some text i= n the gossip draft acknowledging the privacy risks that =E2=80=9Cpromiscuou= s=E2=80=9D STH pollination, but the current text doesn=E2=80=99t go far eno= ugh and underestimates the risk.=C2=A0 For example, by the calculations in = the text, suppose a malicious HTTPS server has up to 336 unique STHs per lo= g that it could use to =E2=80=9Ctag=E2=80=9D and track clients over time.= =C2=A0 Supposing there are 10 well-known log servers, this is 3360 unique S= THs total.=C2=A0 The current text seems to suggest that this is =E2=80=9Csm= all enough=E2=80=9D, which may be true in the one particular attack the tex= t suggests earlier, namely that the attacker picks one particular less-popu= lar (e.g., somewhat-old) STH to give a client it wishes to track. =C2=A0

How does it then trac= k it? Also, the client then either reconciles the STH with a newer one (or = perhaps already has done so) and discards it, or it gossips it, meaning oth= er clients will start mentioning this "rare" STH.
=C2= =A0
But this is not the =E2=80=9Creal=E2=80=9D attack of intere= st: a just slightly smarter attacker would probably use the presence or abs= ence of these less-popular STHs in a client=E2=80=99s gossip cache as (nois= y) bits in a tracking identifier.=C2=A0 The attacker would gossip to each c= lient it hasn=E2=80=99t seen before some kind of ECC-encoded pattern of les= s-popular STHs.=C2=A0 Thus, the 3360 unique STHs the attacker gets to play = with do not represents =E2=80=9Cthe number of clients the attacker can trac= k=E2=80=9D as the current text seems to suggest, but rather the 3360 unique= STHs may in fact be =E2=80=9Ctracking tag bits=E2=80=9D that the attacker = gets to play with in attempting to imprint clients with tracking tags via g= ossip.=C2=A0 And 3360 bits is a lot of bits: plenty of room for a highly-un= ique (say 64-bit) per-client tag to be encoded in a high-expansion, rather = noise-tolerant encoding.

I'd be interested to see how this kind of attack would actually w= ork out in practice, especially given there are some relatively simple coun= termeasures.

a) Cache old STHs so they can be drop= ped immediately.

b) Always attempt to reconcile re= ceived STHs before gossiping them.
=C2=A0

=
Of course, a user could still avoid being tracked in this fashion by u= sing a stateless, =E2=80=9Camnesiac=E2=80=9D browsing platform like Tails, = which would presumably start with an empty STH cache on each boot.=C2=A0 Bu= t this would also defeat CT=E2=80=99s ability to use STH polination to dete= ct MITM attacks across client/browser sessions.

I don't think that's correct. Detectio= n can be done by any participant, so all that is needed is for the browser = to gossip at least once.
=C2=A0

If an attacker can both persistently MITM someone to a website (or= the
whole internet) and DoS the STH lookup mechanism (and compromise a = log
and a CA) - yes, the attacker wins.

Attackers who can persist= ently MITM users forever are extremely
powerful and we have no way to de= fend against them except to make all
your client software just stop work= ing.

Attackers who can persistently MITM users f= orever are indeed extremely powerful but are not at all unrealistic, given = the increasing presence of Great Firewall type attackers (and all the small= er wanna-be knockoffs), which can indeed persistently control the =E2=80=9C= networked view of the world=E2=80=9D seen by any user who cannot or does no= t regularly travel internationally.

That doesn't seem to be the case, in practice.
=C2=A0

I disagree that we have no way to defe= nd against them; if you think so you=E2=80=99re giving up too quickly.=C2= =A0 Of course such an attacker can simply block or DoS all the user=E2=80= =99s communication in any case, but in practice most of these attackers wou= ld rather let the client think they=E2=80=99re communicating securely while= silently compromising them.=C2=A0 CT with gossip cannot even guarantee tha= t such silent, persistent MITM attacks will ever even be detected (by anyon= e), let alone prevented.=C2=A0 But the multi-signed STH approach I suggeste= d would do exactly that.

I don't see how - both are numbers games. There's nothing in= multi-signing that provides strong guarantees, just statistical ones.
=C2=A0
=C2=A0Since the pervasive MITM attacker would be u= nable to forge a single valid STH signature the client will accept without = compromising a large quorum of monitor/witness/co-signer servers as well, t= he attacker is left with the choice of remaining silent and leaving the cli= ent=E2=80=99s communication uncompromised, or denying/blocking the communic= ation entirely.=C2=A0 I claim that such a situation would be much, much pre= ferable to the current state of affairs even with CT deployed.
<= /div>

If we tone down your rhetoric t= o admit the fallibility of your scheme, then in principle I think its worth= exploring, but:

a) We still need gossip,

b) There are architectural issues I mention in my previous= email that need resolving.
=C2=A0

This applies to the CA system
absent CT, it requires to the = CA system with CT, and it applies to
software updates.=C2=A0 If you can = write exploits, but not find bugs - just
wait for a patch to come out, b= lock the update, take your leisurely
time reverse engineering, writing t= he exploit, and using it.

=
Of course client-s= ide software security is a huge and important problem in itself, but it=E2= =80=99s orthogonal to the design of CT.=C2=A0 I have plenty of thoughts on = how multi-signing or cothorities could be used to improve the situation the= re as well, but that=E2=80=99s another topic.

= I don't mean to dismiss this concern, but a) I don't believe SCTFeedback and STH Pollination cause privacy problems

See above.

b) This problem is
so hard= that no one is attempting to defend against it
I am; see above.

c) History
suggests such = attackers are not all-powerful. =C2=A0

Agreed, s= uch attackers are not all-powerful, but pretty much any compromised or stat= e-controlled ISP is certainly powerful enough to persistently MITM any clie= nt that always connects through that ISP

Eh? You have to also compromise a CA and some logs, a= s well as own the ISP. And you have to MITM all protocols (I am assuming th= at over time gossip will be a multi-protocol thing).
=C2=A0
- which is true at least of (a) desktop machines on a home or w= ork network always attached via the same connection, and (b) smartphones ro= aming within a country but always using a data plan through the same cellul= ar ISP.=C2=A0 These threat models do not seem unrealistic to me, but rather= quite ubiquitous.

Or at least, we've
c= aught a lot of folks who could have gotten away with it that
supposedly = had that capability and could have known better.

=
Yes, a lot of current attackers have been sloppy in one way or another= , but that doesn=E2=80=99t mean we should assume the they will not learn fr= om their past mistakes and adopt less sloppy attacks in the future.=C2=A0 T= hey will.
<= div>
Or are you= saying (contrary to my prior understanding) that Chrome requires
*all* = CT certs to have multiple SCTs signed by different log servers?

As Ben said, the end goal is to use it for everything.

What is the =E2=80=9Cit=E2=80=9D to be used for everything?= =C2=A0 CT?=C2=A0 Or CT with a mandatory minimum of >1 SCTs?=C2=A0 And ag= ain, what do you think a reasonable mandatory minimum number of SCTs would = be?=C2=A0 Two, five, ten, 100?=C2=A0 If it starts at 1 or 2 for pragmatic r= easons, will it ever increase or will it stay forever at 2 due to inertia?= =C2=A0 Is that good enough?

I don't knowwhen we'll get there, but in the interim there will probably be a
= period of opt-in:
https://ritter.vg/blog-require_certifi= cate_transparency.html

Nice blog post, but I = don=E2=80=99t see where it addresses the issue of how many independent SCTs= a browser should expect/require a cert to have even if it does decide to d= emand CT support.

The Comodo incident you= reference, was that the m= ozilla.com cert in
2008?=C2=A0 That was someone just trying a RA por= tal and getting a cert:
http://www.theregister.co.uk/2= 008/12/29/ca_mozzilla_cert_snaf/

Despite all the effort to find such certs manually, via MEKAI= ,
Perspectives, Convergence, Cert Patrol, and others - I'm not aware= of
anyone ever catching a CA-signed misissued cert manually.

=
I think it was the March 2011 incident, where a hacker was a= ble to obtain fraudulent certificates through Comodo and then apparently at= tempted to use at least one of them, for =E2=80=98login.yahoo.com=E2=80=99, in some way:=C2= =A0https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.= html=C2=A0 Comodo=E2=80=99s report and the other information I found do= n=E2=80=99t make it clear exactly in what way the login.yahoo.com=C2=A0cert was =E2=80=9Cseen= live on the Internet=E2=80=9D - perhaps it was Google pinning as well if G= oogle was pinning Yahoo=E2=80=99s certs at that time (were they?), or perha= ps it was manual forensics.=C2=A0 Perhaps you or someone else has better in= formation about this.=C2=A0 But this is all incidental: it=E2=80=99s great = that Google pinning has caught a lot of incidents, but nobody seems to be s= aying that means Google pinning is the best/final solution.

In this case, though, CT would hav= e caught the mis-issue.
=C2=A0

With the multi-SCT approach, the amount o= f bandwidth consumed during TLS
negotiation with every CT-supporting web= site increases linearly with n.
With the scalable multisignature approac= h, n can increase to arbitrarily
large size - a hundred, a thousand if n= eeded - e.g., including all the
public auditors, monitors, etc. - withou= t any increase in the size of
certificates, number of SCTs attached, or = ultimately the bandwidth/latency
overhead during TLS negotiation.

While we aim to keep SCTs small as Ben indicated - yes, sendi= ng 10
would be quite a bit.=C2=A0 I'm not sure of a great answer her= e.. I think
the onus is kind of on the community to curate and run a few= er number
of high-quality, mutually distrusting, different-juristictiona= l logs.

This is precisely my point: by arc= hitecturally relying on multiple SCTs per cert we=E2=80=99re tying ourselve= s into the same bad old security tradeoff of having to trust a few =E2=80= =9Chigh-quality, mutually distrusting, different-jurisdictional logs=E2=80= =9D - i.e., a few conventional centralized authorities.=C2=A0 How do you ch= oose them?=C2=A0 Who chooses them?=C2=A0 Do you let one of those 10 be run = by (say) Iran or Syria, in the interest of diversity (at least they=E2=80= =99re probably not colluding with the Five Eyes countries!) - even though t= heir governments have a record of trying to MITM their users (https://www.eff.org/deeplinks/2011/03/iranian-hackers-o= btain-fraudulent-https, https://www.eff.org= /deeplinks/2011/05/syrian-man-middle-against-facebook) and can probably= be expected to try to exploit their control over =E2=80=9Ctheir=E2=80=9D l= og server in any way the CT architecture allows them to (such as persistent= MITM attacks as discussed above)?

Now you seem to be claiming that it is possible to persiste= ntly MITM an entire nation. I find that difficult to swallow.
=C2= =A0

With the scalable multi signing, in contrast= , we could have 10 or 100 or 1000 monitor/co-signer servers contributing to= each STH signature with *no* cost to client verification time, client CPU = costs, TLS startup bandwidth consumed, etc.=C2=A0 One quite reasonable poli= cy might be that *every* country that is technically capable of running a m= onitor/co-signer server could join and participate in the signing process o= f every STH of every well-known log.=C2=A0 If you=E2=80=99re claiming that = it=E2=80=99s infeasible to decentralize trust in such a service beyond 10 o= r so well-known nodes, again I think you=E2=80=99re just giving up and conc= eding the field too quickly.

2. Our original design for CT did indeed have certs ser= ved along with an STH
and an inclusion proof. Unfortunately, CAs categor= ically rejected this
approach because of the latency it introduced in th= e certificate issuance
process. Personally, I think it would be a better= approach. Now CAs are more
accepting of CT, perhaps it would be worth r= evisiting the question with
them?


Agreed, that would be great= .

I am most excited about the prospect of sending an in= clusion proof to
a recent STH to the client - but I don't actually t= hink the cert is
the answer. I think it's a TLS extension or (better= ) an OCSP staple.
Doing this would eliminate what I think is the weakest= part of the
gossip document - the requirement to obtain a STH from a SC= T (well a
cert) via some 'privacy preserving manner'. =C2=A0(Whi= ch we, again,
theorize to be DNS, but I don't think that's the a= nswer for everyone.)

Agreed on this.=C2=A0 I= n fact, it=E2=80=99s increasingly unclear to me what security purpose SCTs = actually serve if it indeed ends up that the =E2=80=9Creal=E2=80=9D securit= y CT provides is eventually going to revolve mainly around STHs and inclusi= on proofs.=C2=A0 Out of curiosity, has anyone floated or elaborated on the = idea of what CT would look like if simplified not to rely on SCTs at all?

I believe I already = mentioned that the original plan was to use inclusion proofs, not SCTs. CAs= did not like the consequent delay in certificate issuance.

<= /div>
=C2=A0

If the STH was i= ncluded in the Cert, that doesn't really change the game for me.
1) = The STH could be a STH on the split view of the log, so the
immediate-de= cision security is no better that just sending a SCT.
2) The STH is too = old. I don't want clients pollinate old STHs,
because as time goes o= n, old STHs will be rarer and will be indicative
of what website you vis= ited. After 2.5 years there will only be 100?
1000? popular websites wit= h that STH in the cert. So the old STH needs
to be resolved to a recent = STH, and you pollinate _that_.

<= /div>
Agreed again.

B


-to= m

--94eb2c07e7267e6ca3051cf2710f-- From nobody Mon Aug 10 14:05:41 2015 Return-Path: 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 D4F5C1B3C60 for ; Mon, 10 Aug 2015 14:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 tAorbFiGru-I for ; Mon, 10 Aug 2015 14:05:37 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD341B3E88 for ; Mon, 10 Aug 2015 14:05:36 -0700 (PDT) Received: (qmail 4780 invoked by uid 1004); 10 Aug 2015 21:05:35 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 10 Aug 2015 22:05:35 +0100 Received: (qmail 28673 invoked by uid 1000); 10 Aug 2015 21:05:35 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 10 Aug 2015 22:05:35 +0100 From: Rob Stradling To: Ben Laurie , Bryan Ford , Tom Ritter References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com><7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> Message-ID: <55C9121E.4040107@comodo.com> Date: Mon, 10 Aug 2015 22:05:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 21:05:41 -0000 On 10/08/15 11:28, Ben Laurie wrote: > > On Sat, 8 Aug 2015 at 17:56 Bryan Ford > wrote: > > Hi Tom, > >> On Aug 6, 2015, at 11:46 AM, Tom Ritter > > wrote: >> The Comodo incident you reference, was that the mozilla.com >> cert in >> 2008? That was someone just trying a RA portal and getting a cert: >> http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ > >> Despite all the effort to find such certs manually, via MEKAI, >> Perspectives, Convergence, Cert Patrol, and others - I'm not aware of >> anyone ever catching a CA-signed misissued cert manually. > > I think it was the March 2011 incident, where a hacker was able to > obtain fraudulent certificates through Comodo and then apparently > attempted to use at least one of them, for ‘login.yahoo.com > ’, in some way: > https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html > Comodo’s report and the other information I found don’t make it > clear exactly in what way the login.yahoo.com > cert was “seen live on the Internet” - > perhaps it was Google pinning as well if Google was pinning Yahoo’s > certs at that time (were they?), or perhaps it was manual > forensics. Perhaps you or someone else has better information about > this. But this is all incidental: it’s great that Google pinning > has caught a lot of incidents, but nobody seems to be saying that > means Google pinning is the best/final solution. > > > In this case, though, CT would have caught the mis-issue. Had we (Comodo) been submitting all certs to CT logs at that time, then yes, CT would have caught these mis-issues. Had Chrome been doing certificate pinning at that time (which I don't think it was, given that https://www.imperialviolet.org/2011/05/04/pinning.html is dated a couple of months later), it would have caught these mis-issues too, if any Chrome users had actually been exposed to any of these certs "live on the Internet". The "seen live on the Internet" claim: Within a few hours of us noticing the mis-issuances, we'd analyzed our webserver logs looking for activity on the compromised account and we'd spotted some IP addresses allocated to Iran. One of my colleagues did a port 443 scan across the relevant IP subnets and found a server that was sending that login.yahoo.com cert. IIRC, that server wasn't up for long. Incidentally, this is pretty fair summary of the incident: https://www.chromium.org/Home/chromium-security/root-ca-policy "In March of 2011, Comodo issued fraudulent certs for a number of well-known internet sites including Microsoft, Yahoo and Google. This was not due to a compromise at Comodo, but rather at an authorized Registration Authority operating on Comodo’s behalf. In that case, Comodo immediately spotted the mis-issuance, revoked the certificates, notified the affected parties, and made a full and public disclosure of what had happened, albeit a week after the event. While the compromise itself cannot be minimized, Comodo mostly acted in a manner consistent with the trust placed in them as a Root CA (earlier disclosure would have been better)." My one complaint is the "mostly...earlier disclosure would have been better" part. We wanted to disclose ASAP, but one of the browser providers said they needed 9 days to produce and test patches. That may sound implausible now, but remember that this was before any of the browsers had introduced their certificate blacklisting mechanisms (i.e. Google's CRLSets, Microsoft's disallowed.stl, etc). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Aug 11 12:56:12 2015 Return-Path: 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 ABFC41B2A14 for ; Tue, 11 Aug 2015 12:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Sm32FLI3o9BQ for ; Tue, 11 Aug 2015 12:56:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E2E1B2A10 for ; Tue, 11 Aug 2015 12:56:10 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50756 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZPFeb-0003II-Kd for trans@ietf.org; Tue, 11 Aug 2015 15:56:09 -0400 To: trans@ietf.org References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> From: Stephen Kent Message-ID: <55CA5359.2090007@bbn.com> Date: Tue, 11 Aug 2015 15:56:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] TRANS Draft minutes for IETF-93 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 19:56:11 -0000 Rich, Sorry for the late comment, but I just returned from vacation after IETF. > Please send/post corrections. > > ... > > Steve Kent, attack model > Name changed on doc, even if filename can't easily be changed. Not a threat model, we don't know what the attackers are thinking, but we do know possible actions so it's an attack model. > Includes an intro to CT, he prefers it move into an arch document but if not it will stay. > "CT is a set of mechanisms, designed to detect, deter, and facilitate remediation of certificate mis-issuance" > Semantic mis-issuance: name in the cert refers to an entity incorrectly. > Syntactic mis-issuance: violation of certificate profile(s) that apply. > Reviewed a taxonomy of attacks. Read the doc. Discussion of additions and bigger picture needs. > Incorporated all (but one) comments. > Wants WG agreement via list on goals, definitions, attacks. > We have a half-dozen people commit to read and review the document. > Ben agrees about having an arch doc; Steve and Ben will collaborate on an arch doc I recall saying that I would be happy to author such a doc, starting by extracting some text from the attack model. I recall that Ben agreed that having an arch doc was a good idea, but I do not recall that we agreed to co-author the doc. BTW, I expected to see a message from our chairs raising this issue on the list, to see if there was general support for this new doc. I'm still catching up on e-mail, but did not see such a message. Steve From nobody Tue Aug 11 12:58:40 2015 Return-Path: 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 B00D21B2A21 for ; Tue, 11 Aug 2015 12:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5LftCueV_sn5 for ; Tue, 11 Aug 2015 12:58:37 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id C5F541B2A1B for ; Tue, 11 Aug 2015 12:58:37 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 04921740009; Tue, 11 Aug 2015 19:58:37 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E3063740004; Tue, 11 Aug 2015 19:58:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1439323116; bh=uera5FKq6B7DQ+r5LAuKFJRz/ZmwC2DjDdLHeGIRUEE=; l=369; h=From:To:Date:References:In-Reply-To:From; b=eugHrCNHPffxEFPnoMjJfYQ5dQ4sOp5UhWehYmP0cNW73KxLHWg9Ffwncr5032yjE 5nC9PS0pnt4oB0xwz4049R7jk36fCmWBxzszMWHeeN4SWXu8OHWMk771/mzfZG0gbc dhYHX8m3q5eM1lmv7M2Ypy1SdobrLQexjrU39LdM= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id E017198082; Tue, 11 Aug 2015 19:58:36 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 11 Aug 2015 14:58:36 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 11 Aug 2015 14:58:36 -0500 From: "Salz, Rich" To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] TRANS Draft minutes for IETF-93 Thread-Index: AdDFYP7WEeHyAUAfShqF+ALMT7NsEQPOK4WAAApopJA= Date: Tue, 11 Aug 2015 19:58:36 +0000 Message-ID: <8c0de87047964c0495dd285ed75e3ea8@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> <55CA5359.2090007@bbn.com> In-Reply-To: <55CA5359.2090007@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] TRANS Draft minutes for IETF-93 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 19:58:38 -0000 > I recall saying that I would be happy to author such a doc, starting by > extracting some text from the attack model. I recall that Ben agreed tha= t > having an arch doc was a good idea, but I do not recall that we agreed to= co- > author the doc. I am certain this is more accurate than what I wrote. I hope the chairs ca= n make the necessary update. From nobody Wed Aug 12 03:59:47 2015 Return-Path: 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 6195C1A039A for ; Wed, 12 Aug 2015 03:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 73z5jc0wngby for ; Wed, 12 Aug 2015 03:59:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D961A0399 for ; Wed, 12 Aug 2015 03:59:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mrp2Q10VBz3Qr; Wed, 12 Aug 2015 12:59:42 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ObJzfFSE X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4lD9QaKDtShL; Wed, 12 Aug 2015 12:59:40 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 12 Aug 2015 12:59:40 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1A5F78009F; Wed, 12 Aug 2015 06:59:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1439377178; bh=v3lr/NikA7vt3jpvHY1wGSpCrIfcOhM7raASkp2iUAA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ObJzfFSEqMyufFamJMtCGxpD+DySKcKKaSGwLdr4QZ/yZhxCGCV6sAANFRTyHoBUh S+MJXyjZQ0Sj35+5YALmbAeaQwmaHlb+OBIhA8BbDWgFJQnqIbakGTVkLAiGJXcPjP Dg8TInE1/oQsUWPfdK0ckSuz1kQR+X0h1Ywjg9ss= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7CAxbvD019378; Wed, 12 Aug 2015 06:59:37 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 12 Aug 2015 06:59:37 -0400 (EDT) From: Paul Wouters To: "Salz, Rich" In-Reply-To: <8c0de87047964c0495dd285ed75e3ea8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> <55CA5359.2090007@bbn.com> <8c0de87047964c0495dd285ed75e3ea8@ustx2ex-dag1mb2.msg.corp.akamai.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] TRANS Draft minutes for IETF-93 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 10:59:46 -0000 On Tue, 11 Aug 2015, Salz, Rich wrote: >> I recall saying that I would be happy to author such a doc, starting by >> extracting some text from the attack model. I recall that Ben agreed that >> having an arch doc was a good idea, but I do not recall that we agreed to co- >> author the doc. > > I am certain this is more accurate than what I wrote. I hope the chairs can make the necessary update. I will make the change and get the minutes out ASAP, Thanks everyone Paul From nobody Wed Aug 12 17:23:46 2015 Return-Path: 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 C6F791B2E67 for ; Wed, 12 Aug 2015 17:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 04HctMQMKSxU for ; Wed, 12 Aug 2015 17:23:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A2B0C1B2E60 for ; Wed, 12 Aug 2015 17:23:43 -0700 (PDT) Received: from localhost ([::1]:42475 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZPgJ4-0006dM-P7; Wed, 12 Aug 2015 17:23:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, tom@ritter.vg X-Trac-Project: trans Date: Thu, 13 Aug 2015 00:23:42 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/103 Message-ID: <053.e9003dacea4c2c6fe1887e8af07e16cf@tools.ietf.org> X-Trac-Ticket-ID: 103 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, tom@ritter.vg, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20150813002343.A2B0C1B2E60@ietfa.amsl.com> Resent-Date: Wed, 12 Aug 2015 17:23:43 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #103 (gossip): Evaluate if we need tighter requirements around STHs when we take into account multiple logs. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 00:23:44 -0000 #103: Evaluate if we need tighter requirements around STHs when we take into account multiple logs. We've been kicking this around a bit, but wanted to make sure we captured it concretely. Bryan mentioned this in his emails also, see https://mailarchive.ietf.org/arch/msg/trans/7FR3aRVwi4FZLhmJfy9UnAxQNuU -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- tom@ritter.vg | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Aug 12 17:34:55 2015 Return-Path: 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 B69491B2E77 for ; Wed, 12 Aug 2015 17:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 3wrMgbhlUEqr for ; Wed, 12 Aug 2015 17:34:52 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 2178A1B2E79 for ; Wed, 12 Aug 2015 17:34:52 -0700 (PDT) Received: by iodt126 with SMTP id t126so37356362iod.2 for ; Wed, 12 Aug 2015 17:34:51 -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=6hEhDpU0ZFBcYR7YTF62jnxqFMm75FTKHs+p22hQ4x8=; b=vdtWZC/WNMkSRr47gAVEheFFVitFcrIzQ80oETX2LzGQUrbiC/VHz37STITlzTCj9+ z4katvvAf0CrRwxtcYykS9xuNYYtICf1rOlQ4Kw0WqA+drfKBkE3Ze/hkCk05pDD7Atj 7JbYpWJM9COo6WWDGWo0/ebcjLxjxrg1Ebhhs= 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=6hEhDpU0ZFBcYR7YTF62jnxqFMm75FTKHs+p22hQ4x8=; b=VTQ9YnHYRyhzQ7MJdMbI1XwVWWyZGoerZCFtgsxWkq8k9ON8Rv9Ji0lkXYRPV80x9M ig7R+RqU/TUS3HJFLZFTl7W3HOMSEdz0Dj22i/8fuoaZzdAtjy5kDWLZF4mDyPvR1BlC e8lNzMdaBJ/zeECguJs9kuXKl8S4fBW6skRuwQphIZq/K/BVL3QTveagdTaFyNOEPA4w PHbbXliCQyeCl0i11UcHaHWtZdxmOH8o024bT0ZYlpJrYBEoorHRdS1e0i5iNnZ0UTaU sr6LVje2bgTu+m9QBbQVQpapVsqVuxUQvKa9lPeu/tMH9x7oYF58cLa8XVCfaglZUPNQ WS4Q== X-Gm-Message-State: ALoCoQnGn2AhY1cQiLfW496jqRbyizln5jedOgCRizDHjnzH97A8ootBSlsNquhzaZuWAYnY6PGp X-Received: by 10.107.131.168 with SMTP id n40mr40074380ioi.47.1439426090917; Wed, 12 Aug 2015 17:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.71.1 with HTTP; Wed, 12 Aug 2015 17:34:31 -0700 (PDT) In-Reply-To: <1AD5EA0D-5E8C-4C1D-B32C-24CB9375C8F2@gmail.com> References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> <1AD5EA0D-5E8C-4C1D-B32C-24CB9375C8F2@gmail.com> From: Tom Ritter Date: Wed, 12 Aug 2015 19:34:31 -0500 Message-ID: To: Bryan Ford Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 00:34:53 -0000 On 8 August 2015 at 12:25, Bryan Ford wrote: > [Many good things] Okay. If I simplify unfairly I think I agree with many of the root points of your email. 1) Yes, more logs plus even a weeks worth of STHs probably affords too much ability for tracking. Releasing a STH will have some sort of probability attached to it, but again 'statistics'[0]. I've open a ticket to make sure we don't lose this. 2) Yes, a multi-signer log is more resistant to attack than a single-signer log. I would note there's nothing that would stop someone from running a multi-signer log using distributed signing; and if you can work out the practicalities, your log would probably be seen as one of the more trustworthy ones. I'm doubtful of the likelihood of converting existing logs into this model, but since CT can evolve over time, and logs can be removed/added, there's no reason it can't be a long-term goal. -tom [0] I think there will be a revival (or at least a re-visit) of the research done for pooling strategies in remailers. There was a paper that summed up all the different pooling strategies. Don't remember the name, but I know it's on http://www.freehaven.net/anonbib/ From nobody Wed Aug 12 17:44:56 2015 Return-Path: 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 2D7751B2E6B for ; Wed, 12 Aug 2015 17:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 vjYxqh-a2b1i for ; Wed, 12 Aug 2015 17:44:54 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 D4AF21B2E69 for ; Wed, 12 Aug 2015 17:44:53 -0700 (PDT) Received: by igbjg10 with SMTP id jg10so54141952igb.0 for ; Wed, 12 Aug 2015 17:44:53 -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:content-transfer-encoding; bh=IphqOc0zO39M3wgq45I0S6VDn1/f1H0rxm2S8YVwBPg=; b=zkduWAz92ek2c1sszNk3Kl0L/60BP/g793dsDCU7OXUdM5DdqFnQ9ObqWUqGuAUoI+ l6RxAwskEu/KiCLpg8cNGbpc7+Pp8nX+wyUq2qU4UdpdouBo22y6EiaPuzBVHEztqLoJ EDmqCAWFUm+HJ3aWnKCRvh4XG7+eumVO4DLtc= 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:content-transfer-encoding; bh=IphqOc0zO39M3wgq45I0S6VDn1/f1H0rxm2S8YVwBPg=; b=Gjh6HE/v7xUcdAfqbRvqhihLanvVaiqBIt8ex1Dy1HrZ7GUCyVcw2vplQOCCyLoGH+ cZu6LnxLjZ7xvtZDPSOX5Xv4OMFlvM6moHKRLOe+bBnejq/ZhhpRlzcIBqVUGj9rrKx1 kjs3SafAvskHqW2rlYn0p+A/bCGqHUuVgABJTFSlvZru/VLaftSAa5JFr+sDzT5fcyH2 TytvYQFtRP03kQNhHpYk128YBish4R6z/zGjWB0N734ccc3pZCFm2JxDfBf4Uiw0EWlP ivL+KL4Zbp07e3pTl+f7O/kHVjReooaMY2woJsJ2TtjrXr9UStAh9ILD5BCB3aOqkzQV M9Bg== X-Gm-Message-State: ALoCoQnTOvphAKpgij5NZcKmylQ1+wY8191QzaxmSPg5IHtjV+FDMYMFMJ7rDtIZYMVhi0akSvf5 X-Received: by 10.50.59.180 with SMTP id a20mr513069igr.31.1439426693137; Wed, 12 Aug 2015 17:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.71.1 with HTTP; Wed, 12 Aug 2015 17:44:33 -0700 (PDT) In-Reply-To: <30A8C7DD-B87D-4095-AAFF-FB63EA01D292@gmail.com> References: <30A8C7DD-B87D-4095-AAFF-FB63EA01D292@gmail.com> From: Tom Ritter Date: Wed, 12 Aug 2015 19:44:33 -0500 Message-ID: To: Bryan Ford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip draft CFA closed X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 00:44:55 -0000 On 9 August 2015 at 08:41, Bryan Ford wrote: > I must object to your conclusion that the =E2=80=9Ctechnical issues=E2=80= =9D I brought up > during the discussion =E2=80=9Chave been resolved=E2=80=9D - at any rate,= I consider them > neither purely =E2=80=9Ctechnical issues=E2=80=9D nor having =E2=80=9Cbee= n resolved=E2=80=9D, as should be > eminently clear from my E-mails on the topic. I agree; not resolved. I'm not sure they will be, but I don't want to mischaracterize things. > As I stated clearly earlier, I feel that the entire gossip approach is > fundamentally flawed. It=E2=80=99s not just some technical issues within= the draft > that can be easily fixed, but the whole approach. My concerns are with t= he > strategy, not just minor =E2=80=9Ctechnical issues=E2=80=9D. > > And similarly, I do not see how it can be concluded from the E-mail > discussion that my concerns =E2=80=9Chave been resolved=E2=80=9D (or even= addressed). > > Any approach will add complexity to the system: a gossip protocol will, a= nd > a multisignature approach will. Have the advantages, disadvantages, and > relative complexities of each of these approaches been weighed and > considered in any way? Or was it somehow just =E2=80=9Cassumed as a give= n=E2=80=9D since > before I started participating that gossip was the right approach and no = one > is interested in questioning that now? I think "assumed as a given that some form of gossip was the path forward" is accurate. > I=E2=80=99ll grant that no one else on the list seems to be echoing my co= ncerns with > the gossip approach at the moment - so if you wish to close the call for > adoption anyway over my objections, please feel free to do so; I assume > that=E2=80=99s what the =E2=80=9Crough=E2=80=9D in =E2=80=9Crough consens= us=E2=80=9D is for. But please do not > mischaracterize my position as merely having raised =E2=80=9Csome technic= al issues=E2=80=9D > that =E2=80=9Chave been resolved.=E2=80=9D I think that even if every log had a 51 of 100 signers threshold scheme, we would still want some form of verification that logs are operating non-maliciously. While the bar for collusion or compromise is higher (at 51 instead of 1), the minimum and average technical operating level for the signers of 3 such multi-signer logs will be much lower than that of 3 single-signer logs. While each signer can act as an auditor _for the data it sees_, there is no guarantee that a signer might not be presented with a split-view of the log and never be able to catch the other signers acting on the other side of the merkle tree. So I still think verification is needed. And that verification would probably look something like gossip.... Whenever I've seen someone propose something to the effect of "And a different organization will be responsible for the uptime of your organization!" it tends not to get traction. So I'm skeptical that a multi-signer approach can be practically deployed. But I would love to be proven wrong. -tom From nobody Fri Aug 14 07:57:50 2015 Return-Path: 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 1F7821A8A3B for ; Fri, 14 Aug 2015 07:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 i6BndLmiICPU for ; Fri, 14 Aug 2015 07:57:46 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612781A8A1E for ; Fri, 14 Aug 2015 07:57:46 -0700 (PDT) Received: (qmail 1042 invoked by uid 1004); 14 Aug 2015 14:57:44 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 14 Aug 2015 15:57:44 +0100 Received: (qmail 3299 invoked by uid 1000); 14 Aug 2015 14:57:44 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 14 Aug 2015 15:57:44 +0100 From: Rob Stradling To: "trans@ietf.org" References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com><7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> Message-ID: <55CE01E8.2050604@comodo.com> Date: Fri, 14 Aug 2015 15:57:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] CT "Lite" idea (was Re: Call for adoption, draft-linus-trans-gossip-ct) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:57:49 -0000 On 10/08/15 11:28, Ben Laurie wrote: > On Sat, 8 Aug 2015 at 17:56 Bryan Ford > wrote: >> Out of curiosity, has anyone floated or elaborated on the idea of what >> CT would look like if simplified not to rely on SCTs at all? > > I believe I already mentioned that the original plan was to use > inclusion proofs, not SCTs. CAs did not like the consequent delay in > certificate issuance. Gossip seeks to strengthen CT, whereas the following idea proposes a weaker form of CT that could be much easier to deploy in the short-term. This could form part of an incremental deployment strategy towards "full" CT. PROBLEM The long-term goal is for TLS clients to be able to abort TLS handshakes if an insufficient number of valid SCTs (or inclusion proofs - see TRAC ticket #10) are provided. To achieve this goal, we will need the vast majority of the TLS servers on the planet to be upgraded and/or the vast majority of the CAs on the planet to embed SCTs in certs and/or OCSP responses. This could take years! While we wait... IDEA When a TLS server sends a cert accompanied by zero SCTs / inclusion proofs, let the TLS client attempt to fetch and verify an inclusion proof (from each known log?) for each certificate encountered. (This would require a new log API for looking up an inclusion proof by certificate hash). There are 3 possible outcomes: 1. If the TLS client obtains a valid inclusion proof, then all is well. 2. If the TLS client can't obtain any responses from any logs, it should act as if all is well (i.e. soft-fail). 3. If the TLS client receives responses from at least 1(?) log, indicating that there are zero inclusion proofs for the cert in question, it should flag the cert (to the browser vendor?) as potentially not logged. TLS clients could start behaving this way sooner rather than later, since the only prerequisite is that each cert must be logged. (And of course adding a cert to a log is something that can be done by the CA, the domain owner, or indeed anyone else that encounters the cert). If CAs are required (by browser root inclusion policies) to log all certs they issue, then any evidence of certs not being logged would prove CA misbehaviour. Ideally the "there are zero inclusion proofs for this cert" response from the log would be signed by the log, so that it's possible for anyone who has a valid and sufficiently old SCT for that cert to prove log misbehaviour. If there are a large number of logs, it might be impractical for TLS clients to try to fetch inclusion proofs from all of them, so there might need to be some sort of mechanism for figuring out which subset of logs should be checked. No doubt there are rough edges in this initial proposal, but is this idea worth pursuing? Or do folks feel that pursuing this idea would be too much of a distraction, and that we should instead focus on the long-term goal of getting "full" CT specified and deployed? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Aug 17 10:24:42 2015 Return-Path: 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 D13FD1ACD57 for ; Mon, 17 Aug 2015 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EpwQ_qLeIhjf for ; Mon, 17 Aug 2015 10:24:37 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 4496C1ACD49 for ; Mon, 17 Aug 2015 10:24:37 -0700 (PDT) Received: by ykbi184 with SMTP id i184so68795765ykb.2 for ; Mon, 17 Aug 2015 10:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=wkB5KQm1kMHcVlS23nIsh+2zTvga23tFg6lMZUBEsJ8=; b=lO5X7os+Sc9iL9Gpe1YlTVl8nnB2m4flMmXEKIvn7bri542U+0tMY98CQUkWwAcy0R BkqbCGT6V2aTqaDNj+WMm98wHgUncx6ey5frBH/wo9/bwWxFFc5cpXajJzgFPP9kPR+m /Cdetfrrmav44RHdTcC1olWQ55KH5eWEqZemFPx0XYxeCgj+kL5IfKLyPdp66ehYZZg9 KPi17F2fd26zYAkd+z8PL1ALBp19dkhrGYbYsyqAosRv7wGRZr+3rfuXngwHLwwkh3gr uj7U9f+bja53lnS+IW2hw1tNnEhPWh5E4SgRzPyo/St6PsGU88SjX9p4rph/MY6oHR6O oqyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=wkB5KQm1kMHcVlS23nIsh+2zTvga23tFg6lMZUBEsJ8=; b=joZK2OH3pHNdpRbL+h+1V+JWx7doDqmKiB4/dNfgQfUOIS2Jf7+WQyAz3o66+LwNSq 01r4QB0ops9Si56p6gGJhAOu0Z6B6L0lmO67OhqPctwAfllbBlIDIdClxD82ljsFPRFq F1CTi49EHLrONucN92xVEXlUKogfiu5keybvq7caUq7TbprQoY+lMil4Sv4xnQ60bZht 4kYnIFw1FzxcbyKztk5drXr1mluu3GQ6Gg2/hccYNvgIW43978WlSX6tt/LBp8UA/Ae9 05OfefU4InVyhL56HC3TA84JL5yO5SUspgyviQRZDIdJm1bDtKq5JdVanpen4EKejfL2 SoEw== X-Gm-Message-State: ALoCoQl6D3GWo/m+kQKnKqcjA385g/y70AuVGBW0qkTBwChFKlH/t20JtSZoeYg/4ssMgcaxZSTU X-Received: by 10.170.169.65 with SMTP id l62mr2617158ykd.88.1439832276585; Mon, 17 Aug 2015 10:24:36 -0700 (PDT) MIME-Version: 1.0 From: Adam Eijdenberg Date: Mon, 17 Aug 2015 17:24:26 +0000 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113a6680621e48051d85136b Archived-At: Subject: [Trans] Certificate Transparency Newsletter - August 2015 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:24:41 -0000 --001a113a6680621e48051d85136b Content-Type: text/plain; charset=UTF-8 (posted to certificate-transparency@googlegroups.com, trans@ietf.org and ct-policy@chromium.org) Hi CT watchers, We wanted to put an update out to summarize what the Certificate Transparency team at Google is working on as well as other efforts in the space that we are aware of. There are lots of other great contributions taking place from other organizations and individuals so we apologize for anything that we've missed and we'd also love to hear more about them. Standards work ============== Achievements: - Work continues on RFC6962-bis. Version 8 of the draft was published in July [1]. - IETF 93 was held in Prague in July, and the following CT presentations took place: - "trans" issues update [2] - Eran Messeri - CT Attack Model [3] - Steve Kent - draft-linus-trans-gossip-ct [4] - Daniel Kahn Gillmor and Linus Nordberg - CT for Binary Code [5] - Dacheng Zhang and Daniel Kahn Gillmor - Selective Logs [6] - Rich Salz - New version of Gossip Internet Draft published in July [7]. Lookahead: - We're very interested in exploring how we make it viable for a site-owner to be able to opt-in to requiring CT, ahead of any general browser-enforced deadlines. We would welcome participation in helping define what this might look like in a manner that would work well for both browsers and site-owners. [1] https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08 [2] https://www.ietf.org/proceedings/93/slides/slides-93-trans-3.pdf [3] https://www.ietf.org/proceedings/93/slides/slides-93-trans-0.pdf [4] https://www.ietf.org/proceedings/93/slides/slides-93-trans-2.pdf [5] https://www.ietf.org/proceedings/93/slides/slides-93-trans-1.pdf [6] https://www.ietf.org/proceedings/93/slides/slides-93-trans-4.pdf [7] https://tools.ietf.org/html/draft-linus-trans-gossip-ct-02 Log servers =========== Achievements: - Symantec's log successfully completed compliance testing in August and the process has begun to move this into Chrome's trusted logs store [1]. - Testing is underway for one other log server implementation, Venafi. - Design doc published for Google's open source log server [2]. - README updated with Quickstart instructions for building Google's open source log server [3]. Lookahead: - Google is planning to update the open-source implementation to track the changes made in RFC6962-bis. [1] http://www.certificate-transparency.org/known-logs [2] https://github.com/google/certificate-transparency/blob/master/docs/DesignDoc.md [3] https://github.com/google/certificate-transparency/blob/master/README.md Client implementations ====================== Achievements: - Apple's new App Transport Security for iOS 9 and Mac OS X 10.11 includes support for Certificate Transparency [1], although we're not sure exactly what it does yet. Does anyone reading this have details to share? - Chrome 41, released in March of this year, began enforcing the CT requirement for all EV certificates issued after 1 Jan 2015. Lookahead: - Google is working with the Mozilla Foundation and a contractor to build a patch to contribute to Firefox to provide Certificate Transparency support in Firefox. - Google is planning to launch a set of DNS servers to be able to handle inclusion proof checking over DNS. The primary motivation for doing so is so that a client (such as Chrome, or other browsers that wish to use this) can perform inclusion proof checks without directly revealing the browsing history of the user to any new parties, including Google. The intent is that the client will receive an inclusion proof by performing a DNS lookup for a TXT record for a specially crafted hostname, via the user's existing DNS resolver (typically an ISP) which in turn will resurse to eventually service the request from a Google DNS server. In this manner the client is only revealing the leaf hashes they see (and thus the sites they visit) to their existing DNS resolver, which already (in practically all cases) has just serviced a DNS request for that same site and thus already knows their browsing history. - Google is building out log mirrors for all logs included by Chrome, and the intent is that read-only requests from Chrome (for STHes, or inclusion-proofs (via the DNS mechanism above)) will be serviced by a log mirror, rather than the underlying logs. - Google is building out Chrome support to include STH fetching, and to use the DNS inclusion proof method outlined above. We intend to provide more information (including protocol details) as we make progress. - Google is working with the OpenSSL community on adding experimental support into OpenSSL client for retrieving and validating all SCTs associated with a TLS connection [2]. [1] https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/ [2] https://github.com/aeijdenberg/openssl/blob/add_get_peer_scts/crypto/ct/README.md Server implementations ====================== Achievements: - haproxy [1], nginx [2] and Apache [3] support serving SCTs via TLS extensions (thanks to Janusz Dziemidowicz, Graham Edgecombe and Jeff Trawick respectively). - New section added to Certificate Transparency site to demonstrate how to use these [4]. - (Apologies this is so specific to Google, but this was a big effort due to the scale of the organization/infrastructure) Google.com properties are now serving SCTs via the TLS Extension. Lookahead: - Google is looking at how to add SCT support to QUIC protocol, which is used to communicate between Chrome and many Google properties. [1] https://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.1-crt [2] https://github.com/grahamedgecombe/nginx-ct [3] https://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html [4] http://www.certificate-transparency.org/resources-for-site-owners Monitors ======== Achievements: - Both DigiCert [1] and Comodo [2] have implemented log monitors allowing interested parties to view certificates that are issued for a domain. - Matt Palmer released an open-source Ruby framework for building your own monitor [3]. Lookahead: - Google is also looking at adding a way to allow interested parties to search for and view certificates found in CT logs. - Comodo is planning to release their monitor as open-source. [1] https://www.digicert.com/certificate-monitoring/ [2] https://crt.sh/ [3] https://github.com/tobermorytech/certificate-transparency-monitor --001a113a6680621e48051d85136b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
Hi CT watchers,

We wanted to put an update ou= t to summarize what the Certificate
Transparency team at Google i= s working on as well as other efforts in
the space that we are aw= are of.=C2=A0 There are lots of other great
contributions taking = place from other organizations and individuals so
we apologize fo= r anything that we've missed and we'd also love to hear
m= ore about them.

Standards work
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Achievements:
- Work = continues on RFC6962-bis. Version 8 of the draft was published in
=C2=A0 July [1].
- IETF 93 was held in Prague in July, and the f= ollowing CT presentations
=C2=A0 took place:
=C2=A0 - &= quot;trans" issues update [2] - Eran Messeri
=C2=A0 - CT Att= ack Model [3] - Steve Kent
=C2=A0 - draft-linus-trans-gossip-ct [= 4] - Daniel Kahn Gillmor and Linus
=C2=A0 =C2=A0 Nordberg
=C2=A0 - CT for Binary Code [5] - Dacheng Zhang and Daniel Kahn Gillmor<= /div>
=C2=A0 - Selective Logs [6] - Rich Salz
- New version o= f Gossip Internet Draft published in July [7].

Loo= kahead:
- We're very interested in exploring how we make it v= iable for a
=C2=A0 site-owner to be able to opt-in to requiring C= T, ahead of any general
=C2=A0 browser-enforced deadlines.=C2=A0 = We would welcome participation in helping
=C2=A0 define what this= might look like in a manner that would work well for
=C2=A0 both= browsers and site-owners.

[= 4] https://www.ietf.org/proceedings/93/slides/slides-93-trans-2.pdf

Log servers
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Achievements:
- Symantec's= log successfully completed compliance testing in August and
=C2= =A0 the process has begun to move this into Chrome's trusted logs store=
=C2=A0 [1].
- Testing is underway for one other log se= rver implementation, Venafi.
- Design doc published for Google= 9;s open source log server [2].
- README updated with Quickstart = instructions for building Google's open
=C2=A0 source log ser= ver [3].

Lookahead:
- Google is planning= to update the open-source implementation to track
=C2=A0 the cha= nges made in RFC6962-bis.


Client implementations
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Achievements:
- Apple's new App Transport Security for iOS = 9 and Mac OS X 10.11
=C2=A0 includes support for Certificate Tran= sparency [1], although we're not
=C2=A0 sure exactly what it = does yet.=C2=A0 Does anyone reading this have details to share?
-= Chrome 41, released in March of this year, began enforcing the CT
=C2=A0 requirement for all EV certificates issued after 1 Jan 2015.=

Lookahead:
- Google is working with the Mozil= la Foundation and a contractor to
=C2=A0 build a patch to contrib= ute to Firefox to provide Certificate
=C2=A0 Transparency support= in Firefox.
- Google is planning to launch a set of DNS servers = to be able to handle
=C2=A0 inclusion proof checking over DNS. Th= e primary motivation for doing so
=C2=A0 is so that a client (suc= h as Chrome, or other browsers that wish to
=C2=A0 use this) can = perform inclusion proof checks without directly
=C2=A0 revealing = the browsing history of the user to any new parties,
=C2=A0 inclu= ding Google. The intent is that the client will receive an
=C2=A0= inclusion proof by performing a DNS lookup for a TXT record for a
=C2=A0 specially crafted hostname, via the user's existing DNS resolv= er
=C2=A0 (typically an ISP) which in turn will resurse to eventu= ally service
=C2=A0 the request from a Google DNS server.=C2=A0 I= n this manner the client is
=C2=A0 only revealing the leaf hashes= they see (and thus the sites they
=C2=A0 visit) to their existin= g DNS resolver, which already (in practically
=C2=A0 all cases) h= as just serviced a DNS request for that same site and thus
=C2=A0= already knows their browsing history.
- Google is building out l= og mirrors for all logs included by Chrome,
=C2=A0 and the intent= is that read-only requests from Chrome (for STHes, or
=C2=A0 inc= lusion-proofs (via the DNS mechanism above)) will be serviced by a
=C2=A0 log mirror, rather than the underlying logs.
- Google is= building out Chrome support to include STH fetching, and to
=C2= =A0 use the DNS inclusion proof method outlined above.=C2=A0 We intend to
=C2=A0 provide more information (including protocol details) as we= make
=C2=A0 progress.
- Google is working with the Ope= nSSL community on adding experimental
=C2=A0 support into OpenSSL= client for retrieving and validating all SCTs
=C2=A0 associated = with a TLS connection [2].


=C2=A0 to use these [4].

=
- Google is looking at how to add SCT support to QUIC protocol, which = is
=C2=A0 used to communicate between Chrome and many Google prop= erties.


Monitors
=3D=3D=3D= =3D=3D=3D=3D=3D
Achievements:
- Both DigiCert [1] and C= omodo [2] have implemented log monitors
=C2=A0 allowing intereste= d parties to view certificates that are issued for
=C2=A0 a domai= n.
- Matt Palmer released an open-source Ruby framework for build= ing your
=C2=A0 own monitor [3].

Lookahe= ad:
- Google is also looking at adding a way to allow interested = parties to
=C2=A0 search for and view certificates found in CT lo= gs.
- Comodo is planning to release their monitor as open-source.=

<= div>[2] https://crt.sh/ --001a113a6680621e48051d85136b-- From nobody Tue Aug 18 08:09:08 2015 Return-Path: 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 D78641A038C for ; Tue, 18 Aug 2015 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 lc_XjxHPrLZ0 for ; Tue, 18 Aug 2015 08:09:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EA62D1A010F for ; Tue, 18 Aug 2015 08:09:05 -0700 (PDT) Received: from localhost ([::1]:49442 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZRiVd-0005nA-97; Tue, 18 Aug 2015 08:09:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Tue, 18 Aug 2015 15:09:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/104 Message-ID: <055.1be5a0c40bdc51c705dc27f80af662f1@tools.ietf.org> X-Trac-Ticket-ID: 104 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150818150905.EA62D1A010F@ietfa.amsl.com> Resent-Date: Tue, 18 Aug 2015 08:09:05 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #104 (rfc6962-bis): Add SCT Inclusion Proof extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 15:09:07 -0000 #104: Add SCT Inclusion Proof extension If servers send inclusion proofs it reduces log load and increases client privacy. Add extensions to all three mechanisms (in-cert, TLS extension, OCSP extension) to allow this. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Aug 21 04:10:01 2015 Return-Path: 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 86BFF1A8879 for ; Fri, 21 Aug 2015 04:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 fPc7liSobwy7 for ; Fri, 21 Aug 2015 04:09:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A69521A8897 for ; Fri, 21 Aug 2015 04:09:57 -0700 (PDT) Received: from localhost ([::1]:60065 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSkCq-0002xe-UT; Fri, 21 Aug 2015 04:09:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 21 Aug 2015 11:09:56 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/104#comment:1 Message-ID: <070.8cb12bc558ba4197b77ba801f1dbb671@tools.ietf.org> References: <055.1be5a0c40bdc51c705dc27f80af662f1@tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <055.1be5a0c40bdc51c705dc27f80af662f1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150821110957.A69521A8897@ietfa.amsl.com> Resent-Date: Fri, 21 Aug 2015 04:09:57 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #104 (rfc6962-bis): Add SCT Inclusion Proof extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 11:09:59 -0000 #104: Add SCT Inclusion Proof extension Comment (by rob.stradling@comodo.com): Ticket #10 (particularly comment 6 and 8) covers this, but since that ticket is a bit hard to follow, let's keep this ticket open anyway. :-) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Aug 21 04:36:44 2015 Return-Path: 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 9061C1A8A67 for ; Fri, 21 Aug 2015 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 K2ZKSYZacdOk for ; Fri, 21 Aug 2015 04:36:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A4AD91A8A6A for ; Fri, 21 Aug 2015 04:36:41 -0700 (PDT) Received: from localhost ([::1]:33138 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSkch-0004hJ-DW; Fri, 21 Aug 2015 04:36:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 21 Aug 2015 11:36:39 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/81#comment:3 Message-ID: <079.988cef175b12cf8341fb0effb56a8d95@tools.ietf.org> References: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.com, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150821113641.A4AD91A8A6A@ietfa.amsl.com> Resent-Date: Fri, 21 Aug 2015 04:36:41 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 11:36:42 -0000 #81: OIDs and IANA Considerations Changes (by rob.stradling@comodo.com): * status: closed => reopened * resolution: fixed => * milestone: review => Comment: On the list discussion about this ticket, Melinda noted that, regardless of which OID arc we use, we will need to "add an OID section to the IANA considerations". We haven't done that yet, which is my first reason for reopening this ticket. My second reason... Once we've addressed ticket #10 (and #104), 6962-bis will no longer be using any of the OIDs from RFC6962. So there's no particular reason to continue to use the Google OID arc for any of the 6962-bis OIDs. Previously, Russ advised that "If new OIDs are needed, we ought to assign them from an IETF arc managed by IANA", but the consensus seemed to be that we don't have to do this if we don't want to. My preference would be to switch to using a "shorter" OID arc, to reduce the amount of "bloat" that CT adds to certificates and OCSP responses. We could save 6 or 7 bytes per OID by switching from the Google arc to a 1.3. arc. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Aug 21 07:06:26 2015 Return-Path: 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 BFAED1A90EC for ; Fri, 21 Aug 2015 07:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7rym8AYgdWHi for ; Fri, 21 Aug 2015 07:06:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 72C3A1A90E7 for ; Fri, 21 Aug 2015 07:06:23 -0700 (PDT) Received: from localhost ([::1]:39936 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSmxb-000414-AG; Fri, 21 Aug 2015 07:06:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 21 Aug 2015 14:06:23 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/105 Message-ID: <064.63d919d95b92ab76c7b87296ee93e7e2@tools.ietf.org> X-Trac-Ticket-ID: 105 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 14:06:24 -0000 #105: Shrink LogID SCTs currently contain... struct { opaque key_id[HASH_SIZE]; } LogID; That's 32 bytes (assuming SHA-256) just to give clients a hint about which log public key should be used to verify the SCT signature. Wasteful. Also, I don't see why it needs to be a "struct". There are various schemes we could use, but here's my proposal... 1. Redefine LogID to... opaque LogID<1..2^8-1>; 2. Change... '"key_id" is the HASH of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo.' ...to... '"LogID" is the DER-encoding of an OID, excluding the ASN.1 tag and length bytes, that the log operator has allocated for the purpose of uniquely identifying this log.' 3. Add the LogID OID to the log metadata. Any better ideas? -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Aug 21 07:08:57 2015 Return-Path: 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 15FCC1A9068 for ; Fri, 21 Aug 2015 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 la3CguVFehfk for ; Fri, 21 Aug 2015 07:08:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 12CCB1A90AB for ; Fri, 21 Aug 2015 07:08:54 -0700 (PDT) Received: from localhost ([::1]:39978 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSn01-0004Jy-W7; Fri, 21 Aug 2015 07:08:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 21 Aug 2015 14:08:53 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:1 Message-ID: <079.ec4cdf6321127b05aa27ca0517a40776@tools.ietf.org> References: <064.63d919d95b92ab76c7b87296ee93e7e2@tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <064.63d919d95b92ab76c7b87296ee93e7e2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 14:08:55 -0000 #105: Shrink LogID Comment (by rob.stradling@comodo.com): The ASN.1 tag byte can be omitted in my proposal because we'd know it's an OID from the context, and the length byte(s) can be omitted because <1..2^8-1> already tracks the variable length for us. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Aug 21 07:23:26 2015 Return-Path: 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 B42271A9170 for ; Fri, 21 Aug 2015 07:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NLAxmKcCoYlN for ; Fri, 21 Aug 2015 07:23:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C81AA1A9234 for ; Fri, 21 Aug 2015 07:23:18 -0700 (PDT) Received: from localhost ([::1]:40960 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSnDy-0001ZL-9Q; Fri, 21 Aug 2015 07:23:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 21 Aug 2015 14:23:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/106 Message-ID: <064.2240c8a2e053ac6bc447e8af544b690a@tools.ietf.org> X-Trac-Ticket-ID: 106 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #106 (rfc6962-bis): Include LogID in the STH structure (TreeHeadSignature) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 14:23:24 -0000 #106: Include LogID in the STH structure (TreeHeadSignature) Currently, STHs don't self-identify which log they are signed by. For RFC6962, this doesn't really matter: STHs are generally fetched directly from the log, so you implicitly know which log they are signed by. However, for ticket #10 (and #104) and for gossip, STHs (and inclusion proofs, which incorporate STHs) will be obtained from places other than the originating log. Some mechanism will be needed for specifying which log they are signed by. Therefore, I propose that we: 1. Add the LogID field to the TreeHeadSignature struct. 2. Bump TreeHeadVersion from v1 to v2. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: task | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Aug 25 01:56:18 2015 Return-Path: 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 461C01B2D0C for ; Tue, 25 Aug 2015 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 C1_EWIliBOKW for ; Tue, 25 Aug 2015 01:56:15 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 D3BC61B2D02 for ; Tue, 25 Aug 2015 01:56:14 -0700 (PDT) Received: by ykdt205 with SMTP id t205so149659267ykd.1 for ; Tue, 25 Aug 2015 01:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=0Ab0ahKchXr2f0oY7IdK6MyfZHJmtM5S9t6t5Q3rUyY=; b=WkGyxPoxhWL896kw1GQ62v2QEBKkXWRSVISCoLgVqKA4qaaeWMjd6Shgpka9wknB9S WKq9FDGswpQYhCn065TbJD0C+UftZ6uSFF0M8dAgszjKaKtSVEudTQ3/36EawHZQCNbB pKqbStk4WnE6i6T8iKCQBJRqurF0KZF3h9nOTj5clSAW1mLDqhx43jb9Iyo+/h1X5SIs U0mmQWBIEiji1ApfqpvLJoGuWx8YKXFQ8oN6C7+p8vH8tgd0Kj0R6Ua1lXaznoibHmbu VACVelmEoanjRXvi7DJ45Ux2lRYDsaFZy+53zWEMPGnqhKpol3bjEqm8tMbWSg+Q923D tKSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=0Ab0ahKchXr2f0oY7IdK6MyfZHJmtM5S9t6t5Q3rUyY=; b=Os3YjDev+DUUkJUKJQe8kScq4x/Y55uRN2y4FDhbJur4GwpbQC+3vwGQS/iLYiU3PV EV5uXhRxw8+ygWGFV3yLiitrYWAe44JYcCjpiTu/0Xzyu6kjJ06NWOxCXn2/3r07G9oa rP9hnPmrwGcToRFjUwjK5y/G1+1B08G3PeReHOPRbKTmh7Dg2Je1GAfBrtToZKJshggq Wi7lSNRMQuJVbVWiciZnpQ+N9tAiysg3vf7qvOCHRdsU8j09mmcNBTpy22XEHfA/KvVo YFrI7kRGU47Kv/WidVxQoqHE5tzlo0FQDKlNDGo9vLaQ+1Pwmn1QH7d4D/RrO0thDeER Yp9g== X-Gm-Message-State: ALoCoQmH9JPDsxX0iXLYNzRKcTUlJuQKWxx8NdI+zEpV+9Mi6pKO3EjvgOy+XIFk+sS9MBv5Vstl X-Received: by 10.13.204.208 with SMTP id o199mr34909142ywd.170.1440492974099; Tue, 25 Aug 2015 01:56:14 -0700 (PDT) MIME-Version: 1.0 References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com> <1AD5EA0D-5E8C-4C1D-B32C-24CB9375C8F2@gmail.com> In-Reply-To: From: Ben Laurie Date: Tue, 25 Aug 2015 08:56:04 +0000 Message-ID: To: Tom Ritter , Bryan Ford Content-Type: multipart/alternative; boundary=001a114e4fb606422a051e1ee85e Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 08:56:16 -0000 --001a114e4fb606422a051e1ee85e Content-Type: text/plain; charset=UTF-8 On Thu, 13 Aug 2015 at 01:34 Tom Ritter wrote: > On 8 August 2015 at 12:25, Bryan Ford wrote: > > [Many good things] > > Okay. If I simplify unfairly I think I agree with many of the root > points of your email. > > 1) Yes, more logs plus even a weeks worth of STHs probably affords too > much ability for tracking. Releasing a STH will have some sort of > probability attached to it, but again 'statistics'[0]. I've open a > ticket to make sure we don't lose this. > I've been thinking about this for a while now, and I'd like to know how this attack works. When a client communicates with a log, assuming it manages to do so completely anonymously, it reveals at most two STHs it knows (i.e. if it asks for an STH consistency proof). A week's worth of STHs gives me ~10,000 pairs. Assuming, say, 1B people who visit sites using CT in that week, that puts each person into an anonymity set of size 100,000, assuming the attacker has full control over STHs the user caches. Which he doesn't. Also, once the attacker has narrowed the user to this set, what has he learnt? Nothing, since he already knew the 2 STHs the user had cached (he supplied them). Those two STHs are correlated with nothing else. What's more, one of them is now going to be removed from the cache (the older one), moving the user into a really large anonymity set. In practice, the user will soon replace that STH with a more recent one, and different users will replace with different STHs, causing the set to become even larger over time. Anyway, now you can determine that one of at least 10M people visited some particular website. I find it hard to get excited about that. In order to further narrow the user down, or to learn anything correlated with the smaller (two STH) anonymity set, the attacker needs some other persistent marker so he can correlate other requests. But if he has that persistent marker, what is the STH marker for? In short: I am not seeing how this represents a privacy problem. Perhaps I'm missing something? --001a114e4fb606422a051e1ee85e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , 13 Aug 2015 at 01:34 Tom Ritter <tom@= ritter.vg> wrote:
On 8 Aug= ust 2015 at 12:25, Bryan Ford <brynosaurus@gmail.com> wrote:
> [Many good things]

Okay.=C2=A0 If I simplify unfairly I think I agree with many of the root points of your email.

1) Yes, more logs plus even a weeks worth of STHs probably affords too
much ability for tracking. Releasing a STH will have some sort of
probability attached to it, but again 'statistics'[0]. I've ope= n a
ticket to make sure we don't lose this.

=
I've been thinking about this for a while now, and I'd like to= know how this attack works.

When a client communi= cates with a log, assuming it manages to do so completely anonymously, it r= eveals at most two STHs it knows (i.e. if it asks for an STH consistency pr= oof).

A week's worth of STHs gives me ~10,000 = pairs. Assuming, say, 1B people who visit sites using CT in that week, that= puts each person into an anonymity set of size 100,000, assuming the attac= ker has full control over STHs the user caches. Which he doesn't.
=

Also, once the attacker has narrowed the user to this s= et, what has he learnt? Nothing, since he already knew the 2 STHs the user = had cached (he supplied them). Those two STHs are correlated with nothing e= lse. What's more, one of them is now going to be removed from the cache= (the older one), moving the user into a =C2=A0really large anonymity set. = In practice, the user will soon replace that STH with a more recent one, an= d different users will replace with different STHs, causing the set to beco= me even larger over time. Anyway, now you can determine that one of at leas= t 10M people visited some particular website. I find it hard to get excited= about that.

In order to further narrow the user d= own, or to learn anything correlated with the smaller (two STH) anonymity s= et, the attacker needs some other persistent marker so he can correlate oth= er requests. But if he has that persistent marker, what is the STH marker f= or?

In short: I am not seeing how this represents = a privacy problem. Perhaps I'm missing something?

<= /div>
--001a114e4fb606422a051e1ee85e-- From nobody Wed Aug 26 05:15:19 2015 Return-Path: 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 D4D2A1B2A7C for ; Wed, 26 Aug 2015 05:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Nj_FcFXYZWIk for ; Wed, 26 Aug 2015 05:15:17 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 21CF91B2A19 for ; Wed, 26 Aug 2015 05:15:17 -0700 (PDT) Received: by iodb91 with SMTP id b91so15747333iod.1 for ; Wed, 26 Aug 2015 05:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=7+q+2i9Zsvh4NvqnEOeNOo7iiOsLNOe0DBZAw93iDr4=; b=pgvhsSuLD8e6evix5XbRpa5QseYhiosV8qlpJ/+qiffutJnGjCaarQnjwt0J9C1QeX oE3jAZKW/QDT4UTMpNtu1HNeSpAkc9Syalx7eCsNvgGWK1Ad+olClzzeB5Y1+7E0Hx+j 4M3PH3f0g+fNwvD02sDCQlWlnIhzhbTAhIjTA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7+q+2i9Zsvh4NvqnEOeNOo7iiOsLNOe0DBZAw93iDr4=; b=Svv0MJ5jfG7bOEZRzGnOTb86DHX9x5LwsaBiQGMOf3TyT2oWDShnm3i9T3nHkbukMg 7CkvfJF0ECFrmrJWUBV5M0Da9vTKtFZ0oRACWs0fKLGUVHO0MK/wkwEKVtca9TApN17U K+i9tporZ1Je1QrDXBAScUJ5AqHwKkNMxj4v/Ml/OqTD1k8wlDDj8Cy2Q0djXXNUTLDS peU7ujat5aSgemlQCY2Qa2a25NjdN76L+OMPywwc3Tk1Jz8M3HZxF+HWkasm9GjI0z5j GtbEMsr3ySaIxZaG5TdxjgYsKY778JH9w5bI9kh9ia+JoVB6ehDxI75Yoj4HVs7ajwIy bT3w== X-Gm-Message-State: ALoCoQmrUbv+WD0aewAKlRFp1HypwoaCfbQe+sk2zKrnYB7ChcGVHfqteqxxe64qU98iWofjSO7P MIME-Version: 1.0 X-Received: by 10.107.131.168 with SMTP id n40mr3437430ioi.47.1440591316521; Wed, 26 Aug 2015 05:15:16 -0700 (PDT) Received: by 10.79.71.1 with HTTP; Wed, 26 Aug 2015 05:15:16 -0700 (PDT) Date: Wed, 26 Aug 2015 07:15:16 -0500 Message-ID: From: Tom Ritter To: Ben Laurie Content-Type: multipart/alternative; boundary=001a113ec430b033d4051e35cd78 Archived-At: Cc: "trans@ietf.org" , Bryan Ford Subject: [Trans] Tracking via multiple STHs (was Call for adoption, draft-linus-trans-gossip-ct) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 12:15:19 -0000 --001a113ec430b033d4051e35cd78 Content-Type: text/plain; charset=UTF-8 On 25 August 2015 at 03:56, Ben Laurie > wrote: > > > On Thu, 13 Aug 2015 at 01:34 Tom Ritter > wrote: >> >> On 8 August 2015 at 12:25, Bryan Ford > wrote: >> > [Many good things] >> >> Okay. If I simplify unfairly I think I agree with many of the root >> points of your email. >> >> 1) Yes, more logs plus even a weeks worth of STHs probably affords too >> much ability for tracking. Releasing a STH will have some sort of >> probability attached to it, but again 'statistics'[0]. I've open a >> ticket to make sure we don't lose this. > > > I've been thinking about this for a while now, and I'd like to know how this > attack works. > > When a client communicates with a log, assuming it manages to do so > completely anonymously, it reveals at most two STHs it knows (i.e. if it > asks for an STH consistency proof). > > A week's worth of STHs gives me ~10,000 pairs. Assuming, say, 1B people who > visit sites using CT in that week, that puts each person into an anonymity > set of size 100,000, assuming the attacker has full control over STHs the > user caches. Which he doesn't. > > Also, once the attacker has narrowed the user to this set, what has he > learnt? Nothing, since he already knew the 2 STHs the user had cached (he > supplied them). Those two STHs are correlated with nothing else. What's > more, one of them is now going to be removed from the cache (the older one), > moving the user into a really large anonymity set. In practice, the user > will soon replace that STH with a more recent one, and different users will > replace with different STHs, causing the set to become even larger over > time. Anyway, now you can determine that one of at least 10M people visited > some particular website. I find it hard to get excited about that. > > In order to further narrow the user down, or to learn anything correlated > with the smaller (two STH) anonymity set, the attacker needs some other > persistent marker so he can correlate other requests. But if he has that > persistent marker, what is the STH marker for? > > In short: I am not seeing how this represents a privacy problem. Perhaps I'm > missing something? So in your thought process the attacker is a log colluding with a website to track a user? I imagined in a different way. Two independent sites A and B want to collaborate to track a user cross-origin. A feeds a client Carol some N specific STHs from the M logs Carol trusts, chosen to be older and less common, but still in the validity window. Carol visits B and chooses to release some of the STHs she has stored, according to some policy. If we were able to model a representation for how common older STHs are in the pools of clients, then for a given policy of how to choose which of those STHs to send to B I think we could calculate some statistics about how likely it is that Carol looks like someone else when talking to B and how useful/accurate such a tracking mechanism is. That's the concern I had in my head, others may have different variants . -tom --001a113ec430b033d4051e35cd78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25 August 2015 at 03:56, Ben Laurie <benl@google.com> wrote:
>
>
> On Thu, 13 Aug 2015 at 01:34 Tom Ritter <tom@ritter.vg= > wrote:
>>
>> On 8 August 2015 at 12:25, Bryan Ford <bry= nosaurus@gmail.com> wrote:
>> > [Many good things]
>>
>> Okay.=C2=A0 If I simplify unfairly I think I agree with many of th= e root
>> points of your email.
>>
>> 1) Yes, more logs plus even a weeks worth of STHs probably affords= too
>> much ability for tracking. Releasing a STH will have some sort of<= br> >> probability attached to it, but again 'statistics'[0]. I&#= 39;ve open a
>> ticket to make sure we don't lose this.
>
>
> I've been thinking about this for a while now, and I'd like to= know how this
> attack works.
>
> When a client communicates with a log, assuming it manages to do so > completely anonymously, it reveals at most two STHs it knows (i.e. if = it
> asks for an STH consistency proof).
>
> A week's worth of STHs gives me ~10,000 pairs. Assuming, say, 1B p= eople who
> visit sites using CT in that week, that puts each person into an anony= mity
> set of size 100,000, assuming the attacker has full control over STHs = the
> user caches. Which he doesn't.
>
> Also, once the attacker has narrowed the user to this set, what has he=
> learnt? Nothing, since he already knew the 2 STHs the user had cached = (he
> supplied them). Those two STHs are correlated with nothing else. What&= #39;s
> more, one of them is now going to be removed from the cache (the older= one),
> moving the user into a=C2=A0 really large anonymity set. In practice, = the user
> will soon replace that STH with a more recent one, and different users= will
> replace with different STHs, causing the set to become even larger ove= r
> time. Anyway, now you can determine that one of at least 10M people vi= sited
> some particular website. I find it hard to get excited about that.
>
> In order to further narrow the user down, or to learn anything correla= ted
> with the smaller (two STH) anonymity set, the attacker needs some othe= r
> persistent marker so he can correlate other requests. But if he has th= at
> persistent marker, what is the STH marker for?
>
> In short: I am not seeing how this represents a privacy problem. Perha= ps I'm
> missing something?


So in your thought process the attacker is a log colluding with a website t= o track a user? I imagined in a different way.

Two independent sites A and B want to collaborate to tr= ack a user cross-origin.=C2=A0 A feeds a client Carol some N specific STHs = from the M logs Carol trusts, chosen to be older and less common, but still= in the validity window.=C2=A0 Carol visits B and chooses to release some o= f the STHs she has stored, according to some policy.

If we were able to model a representation for how common older STHs are = in the pools of clients, then for a given policy of how to choose which of = those STHs to send to B I think we could calculate some statistics about ho= w likely it is that Carol looks like someone else when talking to B and how= useful/accurate such a tracking mechanism is. =C2=A0

<= div>That's the concern I had in my head, others may have different vari= ants .

-tom
--001a113ec430b033d4051e35cd78-- From nobody Wed Aug 26 06:48:17 2015 Return-Path: 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 611A21A8725 for ; Wed, 26 Aug 2015 06:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jnxlRP6nZFVV for ; Wed, 26 Aug 2015 06:48:10 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 668941A1B81 for ; Wed, 26 Aug 2015 06:48:10 -0700 (PDT) Received: by wicne3 with SMTP id ne3so45554923wic.0 for ; Wed, 26 Aug 2015 06:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=7ei9p1e/SogGYbbUpeogYOnWRJgKi2RW2cFTAOHtHz8=; b=JGoXEULRMZ6Ws7FK0VmGIKM8/ZKxJqIR/YXZy9McvTjw6rJHwLD4KbCbfE1InkbSQb qSIYJGAUXwAUf/3g02r6BfcSG3sWaa55TxpU0mNo3wXP+bflC3WrUnSoNgru3ObWpHVs CpIP+uRW9Sw/c4Xz+ByFrhWgJD569eIJze+sdzPt4TWk336eCGEjaVIEMY0q3vpPU3pU SdRpr6a+NjpM9IoubR0vpMZpVb/8iHeytVBKPhi8swLXXK+ASdRFAa4ocrXXUDdcey4g n+oAwoshtR5CSrHFohgEK7wQnOGjDTUADW06xYKVYDoApDbVkg4yVtrPPcAvKoV6yP3i 0jbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=7ei9p1e/SogGYbbUpeogYOnWRJgKi2RW2cFTAOHtHz8=; b=NI5wN57pdGZGkZUWXc3LRoZA/l2TIj+rAhP2GLhRMgpuVMCKsevahjbMTgLG+N9yKM iOFnZZcZOmct1QB0GSpaG2FfxH0sotJ0FhbmO7X8QSIaYTGjgVDeXyRuob2IqOZfAdOU diepqsRaeBul2wLz2exlmcO99W72ubGKh2Z+VJllUPPsJ5lxygfORcGVaCZw1y/Emqw0 hHv3W2X4z2AQkR7fqURyS9O1WUQb11Vt+TXzxyN3rg3Vq84NzpfpC//FXe3kHtRmpEp8 8J2tRy6+RxypDPSlskkEKlisFg0HjvDPzL/i1uoWXUTOk9j/rWT1pzo7Rvba01Q0Q5VB v9Xw== X-Gm-Message-State: ALoCoQmqxa0TbIWbhmHGBrdynmcWDIG2r6Ql9hJlmomZF8Yk1ngKjOVcqONdKLD5qrzhSKCazJPd X-Received: by 10.180.219.101 with SMTP id pn5mr12245270wic.89.1440596888952; Wed, 26 Aug 2015 06:48:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Laurie Date: Wed, 26 Aug 2015 13:47:56 +0000 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=001a1135ee86d4eb65051e3719cd Archived-At: Cc: "trans@ietf.org" , Bryan Ford Subject: Re: [Trans] Tracking via multiple STHs (was Call for adoption, draft-linus-trans-gossip-ct) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:48:12 -0000 --001a1135ee86d4eb65051e3719cd Content-Type: text/plain; charset=UTF-8 On Wed, 26 Aug 2015 at 13:15 Tom Ritter wrote: > On 25 August 2015 at 03:56, Ben Laurie wrote: > > > > > > On Thu, 13 Aug 2015 at 01:34 Tom Ritter wrote: > >> > >> On 8 August 2015 at 12:25, Bryan Ford wrote: > >> > [Many good things] > >> > >> Okay. If I simplify unfairly I think I agree with many of the root > >> points of your email. > >> > >> 1) Yes, more logs plus even a weeks worth of STHs probably affords too > >> much ability for tracking. Releasing a STH will have some sort of > >> probability attached to it, but again 'statistics'[0]. I've open a > >> ticket to make sure we don't lose this. > > > > > > I've been thinking about this for a while now, and I'd like to know how > this > > attack works. > > > > When a client communicates with a log, assuming it manages to do so > > completely anonymously, it reveals at most two STHs it knows (i.e. if it > > asks for an STH consistency proof). > > > > A week's worth of STHs gives me ~10,000 pairs. Assuming, say, 1B people > who > > visit sites using CT in that week, that puts each person into an > anonymity > > set of size 100,000, assuming the attacker has full control over STHs the > > user caches. Which he doesn't. > > > > Also, once the attacker has narrowed the user to this set, what has he > > learnt? Nothing, since he already knew the 2 STHs the user had cached (he > > supplied them). Those two STHs are correlated with nothing else. What's > > more, one of them is now going to be removed from the cache (the older > one), > > moving the user into a really large anonymity set. In practice, the user > > will soon replace that STH with a more recent one, and different users > will > > replace with different STHs, causing the set to become even larger over > > time. Anyway, now you can determine that one of at least 10M people > visited > > some particular website. I find it hard to get excited about that. > > > > In order to further narrow the user down, or to learn anything correlated > > with the smaller (two STH) anonymity set, the attacker needs some other > > persistent marker so he can correlate other requests. But if he has that > > persistent marker, what is the STH marker for? > > > > In short: I am not seeing how this represents a privacy problem. Perhaps > I'm > > missing something? > > > So in your thought process the attacker is a log colluding with a website > to track a user? I imagined in a different way. > > Two independent sites A and B want to collaborate to track a user > cross-origin. A feeds a client Carol some N specific STHs from the M logs > Carol trusts, chosen to be older and less common, but still in the validity > window. Carol visits B and chooses to release some of the STHs she has > stored, according to some policy. > > If we were able to model a representation for how common older STHs are in > the pools of clients, then for a given policy of how to choose which of > those STHs to send to B I think we could calculate some statistics about > how likely it is that Carol looks like someone else when talking to B and > how useful/accurate such a tracking mechanism is. > > That's the concern I had in my head, others may have different variants . > Right, I was thinking (as a log operator!) about what clients reveal to logs, but you are right that they may reveal more to websites via gossip. I think you are right that we need to model to be able to reason about that variant. --001a1135ee86d4eb65051e3719cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , 26 Aug 2015 at 13:15 Tom Ritter <tom@= ritter.vg> wrote:
On 25 Au= gust 2015 at 03:56, Ben Laurie <benl@google.com> wrote:
>
>
> On Thu, 13 Aug 2015 at 01:34 Tom Ritter <tom@ritter.vg> w= rote:
>>
>> On 8 August 2015 at 12:25, Bryan Ford <brynosaurus@gmail.com= > wrote:
>> > [Many good things]
>>
>> Okay.=C2=A0 If I simplify unfairly I think I agree with many of th= e root
>> points of your email.
>>
>> 1) Yes, more logs plus even a weeks worth of STHs probably affords= too
>> much ability for tracking. Releasing a STH will have some sort of<= br> >> probability attached to it, but again 'statistics'[0]. I&#= 39;ve open a
>> ticket to make sure we don't lose this.
>
>
> I've been thinking about this for a while now, and I'd like to= know how this
> attack works.
>
> When a client communicates with a log, assuming it manages to do so > completely anonymously, it reveals at most two STHs it knows (i.e. if = it
> asks for an STH consistency proof).
>
> A week's worth of STHs gives me ~10,000 pairs. Assuming, say, 1B p= eople who
> visit sites using CT in that week, that puts each person into an anony= mity
> set of size 100,000, assuming the attacker has full control over STHs = the
> user caches. Which he doesn't.
>
> Also, once the attacker has narrowed the user to this set, what has he=
> learnt? Nothing, since he already knew the 2 STHs the user had cached = (he
> supplied them). Those two STHs are correlated with nothing else. What&= #39;s
> more, one of them is now going to be removed from the cache (the older= one),
> moving the user into a=C2=A0 really large anonymity set. In practice, = the user
> will soon replace that STH with a more recent one, and different users= will
> replace with different STHs, causing the set to become even larger ove= r
> time. Anyway, now you can determine that one of at least 10M people vi= sited
> some particular website. I find it hard to get excited about that.
>
> In order to further narrow the user down, or to learn anything correla= ted
> with the smaller (two STH) anonymity set, the attacker needs some othe= r
> persistent marker so he can correlate other requests. But if he has th= at
> persistent marker, what is the STH marker for?
>
> In short: I am not seeing how this represents a privacy problem. Perha= ps I'm
> missing something?


So in your thought process the attacker is a log colluding with a website t= o track a user? I imagined in a different way.

Two independent sites A and B want to collaborate to tr= ack a user cross-origin.=C2=A0 A feeds a client Carol some N specific STHs = from the M logs Carol trusts, chosen to be older and less common, but still= in the validity window.=C2=A0 Carol visits B and chooses to release some o= f the STHs she has stored, according to some policy.

If we were able to model a representation for how common older STHs are = in the pools of clients, then for a given policy of how to choose which of = those STHs to send to B I think we could calculate some statistics about ho= w likely it is that Carol looks like someone else when talking to B and how= useful/accurate such a tracking mechanism is. =C2=A0

<= div>That's the concern I had in my head, others may have different vari= ants .

Right, I was thinking (as a lo= g operator!) about what clients reveal to logs, but you are right that they= may reveal more to websites via gossip. I think you are right that we need= to model to be able to reason about that variant.

=
--001a1135ee86d4eb65051e3719cd-- From nobody Fri Aug 28 07:22:11 2015 Return-Path: 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 B96351A89AC; Fri, 28 Aug 2015 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8J9i_BjvIwbr; Fri, 28 Aug 2015 07:22:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E61A92F4; Fri, 28 Aug 2015 07:22:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150828142208.20328.89125.idtracker@ietfa.amsl.com> Date: Fri, 28 Aug 2015 07:22:08 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-gossip-00.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 14:22:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Gossiping in CT Authors : Linus Nordberg Daniel Kahn Gillmor Tom Ritter Filename : draft-ietf-trans-gossip-00.txt Pages : 17 Date : 2015-08-28 Abstract: This document describes three gossiping mechanisms for Certificate Transparency (CT) [RFC6962]: SCT Feedback, STH Pollination and Trusted Auditor Relationship. SCT Feedback enables HTTPS clients to share Signed Certificate Timestamps (SCTs) (Section 3.2 of [RFC6962]) with CT auditors in a privacy-preserving manner by sending SCTs to originating HTTPS servers which in turn share them with CT auditors. In STH Pollination, HTTPS clients use HTTPS servers as pools sharing Signed Tree Heads (STHs) (Section 3.5 of [RFC6962]) with other connecting clients in the hope that STHs will find their way to auditors and monitors. HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs with trusted auditors or monitors directly, with expectations of privacy sensitive data being handled according to whatever privacy policy is agreed on between client and trusted party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-gossip-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/