Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C2129487 for ; Wed, 5 Apr 2017 09:28:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=office365stanford.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x0MteYYBnz9 for ; Wed, 5 Apr 2017 09:28:03 -0700 (PDT) Received: from mx0a-00000d04.pphosted.com (mx0a-00000d04.pphosted.com [148.163.149.245]) (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 67BF21286CA for ; Wed, 5 Apr 2017 09:28:03 -0700 (PDT) Received: from pps.filterd (m0102889.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35GNHNm016071; Wed, 5 Apr 2017 09:28:00 -0700 Received: from mx0a-00000d03.pphosted.com (mx0a-00000d03.pphosted.com [148.163.149.244]) by mx0a-00000d04.pphosted.com with ESMTP id 29n14qgy38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 09:28:00 -0700 Received: from pps.filterd (m0102880.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35GQjmG006231; Wed, 5 Apr 2017 09:27:59 -0700 Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9]) by mx0a-00000d03.pphosted.com with ESMTP id 29jb0xcrqa-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Wed, 05 Apr 2017 09:27:59 -0700 Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen7.stanford.edu (Postfix) with ESMTP id 4747B4B; Wed, 5 Apr 2017 09:27:17 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) by codegreen7.stanford.edu (Postfix) with ESMTP id D999751; Wed, 5 Apr 2017 09:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=office365stanford.onmicrosoft.com; s=selector1-stanford-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GOvjF/vdNXtU3pDWfL/3m8GTNf9cG02YCXuztdkadMs=; b=p/4ZBNQwkVc3Wy159NSIdh5Q5IeZSrl6OoBzyia795nzodkc+BCCbucw0nnPSEf9Y3YMJao2vYdQqSuxnbqCDqj1Gy3dRMw2mwGs/RDsAUT/ZCnoXSw+aLlyWhonHp7B5kUxLEyRTWmoV6QfS58dG9kwQvDdnFUimLIukx7U/1g= Received: from MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) by MWHPR02MB2862.namprd02.prod.outlook.com (10.175.50.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Wed, 5 Apr 2017 16:27:57 +0000 Received: from MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) by MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) with mapi id 15.01.1019.019; Wed, 5 Apr 2017 16:27:57 +0000 From: Saba Eskandarian To: Ben Laurie CC: "trans@ietf.org" Thread-Topic: [Trans] Privacy-preserving proof of sct exclusion Thread-Index: AQHSpbii8uKV+c47g06WvQijP+zFvqGnVY2AgAC8FcqAAGFqgIAOkm1v Date: Wed, 5 Apr 2017 16:27:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stanford.edu; x-originating-ip: [25.175.226.132] x-microsoft-exchange-diagnostics: 1; MWHPR02MB2862; 7:0BW3Ff4KeRdTrAL2189cdRVJoRlhUFgQzXoY70cxFGI6D0GHOdZPGmlPIZrkQ4f/b444Y653eSVbvuTqzsAHKUj5oglnLiArjdx+ToFOvJHseZ3l82FzM34vZ+vNaVx63BKA+iL4iwz7QbSNmnCTsmDlKnNdI+dnaZBA9PWBjLH3e1oVYochQ3N+dfAgbiqCsVM/9jMo/2vcamSziPHZfq7/pREPz4eO8d76PFJBDH2JmmKE+Fq6vMGDMOBZIH/Vntzu+yFgTkTUzARn/xwwzDyVuz5537kUXmala3WQEgQMyt5crDOv7dL+cGwByP+5Q1lccBVy1Cp1mmi3b1+5uw== x-ms-office365-filtering-correlation-id: fb72c8af-bf3d-44de-ff5d-08d47c40b81a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR02MB2862; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127643986962959)(192374486261705)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR02MB2862; BCL:0; PCL:0; RULEID:; SRVR:MWHPR02MB2862; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(51914003)(24454002)(69226001)(63696002)(74876001)(74706001)(33656001)(76786001)(76796001)(81542001)(54356001)(93136001)(92566001)(46102001)(76576001)(81342001)(92726001)(15975445006)(15188155005)(59766001)(16236675002)(56816005)(66066001)(76482001)(74316001)(90146001)(65816001)(87936001)(56776001)(54316002)(74366001)(87266001)(54206007)(16799955002)(4396001)(47976001)(50986001)(95666003)(49866001)(47736001)(75432001)(51856001)(79102001)(85852003)(83072002)(97336001)(94946001)(93516002)(95416001)(94316002)(86362001)(97186001)(80976001)(81686001)(83322001)(81816001)(31966008)(74662001)(19580395003)(53806001)(74502001)(47446002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR02MB2862; H:MWHPR02MB2861.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_" MIME-Version: 1.0 X-OriginatorOrg: stanford.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 16:27:57.1708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 396573cb-f378-4b68-9bc8-15755c0c51f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2862 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_13:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050141 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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 Apr 2017 16:28:06 -0000 --_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since there wasn't time to present these privacy preserving proofs at the m= eeting last week, I thought it might be of interest to the list that I'll b= e presenting the idea at Stanford's annual security workshop next Monday. I= believe it will be streamed on youtube, and you may find the other present= ations interesting as well (http://forum.stanford.edu/events/2017security.p= hp). The workshop is aimed at a non-specialist audience, but I still hope t= o get to much of the content I meant to present at ietf. thanks, ~saba ________________________________ From: Ben Laurie Sent: Monday, March 27, 2017 2:48:11 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 27 March 2017 at 05:16, Saba Eskandarian > wrote: Thanks for the prompt feedback! I'll make sure to address these comments in= my talk, and I'm looking forward to discussing design options in person. I= suspect that the flexibility of the tools and techniques we use as well as= the associated engineering and privacy tradeoffs will make for an interest= ing discussion. Afraid I won't be there, but looking forward to hearing more. Thanks, ~saba ________________________________ From: Ben Laurie > Sent: Sunday, March 26, 2017 9:46:21 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 25 March 2017 at 22:39, Saba Eskandarian > wrote: Hello, I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago). My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxiv.org/abs/1703.02209 Thanks and looking forward to meeting you all next week! Cool, but I immediately see a problem - you require logs to be in timestamp= order, but they aren't. I can't immediately think of a way to get that pro= perty without also considerably increasing time to inclusion in the log. That seems undesirable - in fact, we're trying to go the other way, i.e. re= duce time to inclusion, in general. Also, engineering reality doesn't change, so increasing time to inclusion i= s also likely to increase MMD. Secondly, its interesting, but doesn't seem particularly useful: when an SC= T corresponds to a cert that has not been included, you want to reveal the = cert, not hide it. What you want to hide is who is revealing it. ~saba _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Since there wasn't time to present these privacy preserving proof= s at the meeting last week, I thought it might be of interest to the list t= hat I'll be presenting the idea at Stanford's annual security workshop next Monday. I believe it will be stre= amed on youtube, and you may find the other presentations interesting as we= ll (http://f= orum.stanford.edu/events/2017security.php). The workshop is aimed at a non-specialist audience, but I still hope to ge= t to much of the content I meant to present at ietf. 

thanks,
~saba
From: Ben Laurie <benl@g= oogle.com>
Sent: Monday, March 27, 2017 2:48:11 AM
To: Saba Eskandarian
Cc: trans@ietf.org
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 27 March 2017 at 05:16, Saba Eskandarian <sabae@stanford.= edu> wrote:

Thanks for the prompt feedback! I'll make sure to address these comments in my talk, and I'm looking forwa= rd to discussing design options in person. I suspect that the flexibility o= f the tools and techniques we use as well as the associated engineering and privacy tradeoffs will make for a= n interesting discussion.


Afraid I won't be there, but looking forward to hearing more.
 


Thanks,

~saba

From:= Ben Laurie <benl@g= oogle.com>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.= edu> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxi= v.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require logs to be in time= stamp order, but they aren't. I can't immediately think of a way to get tha= t property without also considerably increasing time to inclusion in the lo= g.

That seems undesirable - in fact, we're trying to go the other way, i.= e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to inclus= ion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: when = an SCT corresponds to a cert that has not been included, you want to reveal= the cert, not hide it. What you want to hide is who is revealing it.

~saba


_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans



--_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_--