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 89CE1129AB5 for ; Mon, 10 Apr 2017 19:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 LrruWJdDsNIw for ; Mon, 10 Apr 2017 19:02:44 -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 252DB12878D for ; Mon, 10 Apr 2017 19:02:44 -0700 (PDT) Received: from pps.filterd (m0102890.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3B1wJNK012735; Mon, 10 Apr 2017 19:02:40 -0700 Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com [148.163.153.234]) by mx0a-00000d04.pphosted.com with ESMTP id 29rfevsv1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Apr 2017 19:02:39 -0700 Received: from pps.filterd (m0102883.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3B22BNH009474; Mon, 10 Apr 2017 19:02:38 -0700 Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9]) by mx0a-00000d03.pphosted.com with ESMTP id 29rkb79jk6-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2017 19:02:38 -0700 Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen7.stanford.edu (Postfix) with ESMTP id 1FDBC42; Mon, 10 Apr 2017 19:01:47 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0183.outbound.protection.outlook.com [216.32.181.183]) by codegreen7.stanford.edu (Postfix) with ESMTP id E669842; Mon, 10 Apr 2017 19:01:46 -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=Ahe0BCgZVM6euIWDmazFQDhysptzG1fpbWwXju0oZ94=; b=xL+39yHCzKyQUQCSyAtg0O1qw2PqGm+XYXHyaE1n3GpTvzyJhXkv3Y+zbb3L4hGkHOpWMKcMB/ogqyPN8KnxhwbGnedtGevHvAt5dWVhRecxOS1WfJE6brs1jw5Jw+5VN+N5sB+yX+G6nDBqMsR30xNHXph8RO5F5r002bCxlrQ= Received: from MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) by MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Tue, 11 Apr 2017 02:02:35 +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.025; Tue, 11 Apr 2017 02:02:35 +0000 From: Saba Eskandarian To: George Tankersley CC: Ben Laurie , "trans@ietf.org" Thread-Topic: [Trans] Privacy-preserving proof of sct exclusion Thread-Index: AQHSpbii8uKV+c47g06WvQijP+zFvqGnVY2AgAC8FcqAAGFqgIAOkm1vgAhVHoCAACci+A== Date: Tue, 11 Apr 2017 02:02:35 +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: cloudflare.com; dkim=none (message not signed) header.d=none;cloudflare.com; dmarc=none action=none header.from=stanford.edu; x-originating-ip: [25.175.226.132] x-microsoft-exchange-diagnostics: 1; MWHPR02MB2861; 7:q7nxlAj3ly+VSiuyMJgSzSXnyK3DO5/4dyfBuQjuKnRhtk4PHZ4/9YqPqTQWeHXuTU3s5A4D+wo6NCtJ/VV4BJdt95vTp1ifmfkYUxzsBayR/gWZbTku9aDORZlAJIFAFPOIW9A/U9OQLqZ70nu/wPBxsPoDlH11ZceV1bdXRbBXOo0ocGcsZSWW6z3PbofFbetLCoe1U51s6+ZyD9ciqFuJGEg6hEEsuzn73xWvrbV4FfyV3RKmU0JU2RHsm+I2VZ3REWrG/giF7LQDE5HlX0I+riXXIDx8nWCgi4RrxIYQRwwPkntbuBoIxMY8v4a5m26PQqKuDmZQDDovMspYZQ== x-ms-office365-filtering-correlation-id: ab2d5369-94d6-4f01-2229-08d4807ed2b4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR02MB2861; 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)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR02MB2861; BCL:0; PCL:0; RULEID:; SRVR:MWHPR02MB2861; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39450400003)(39840400002)(24454002)(377454003)(51914003)(189998001)(229853002)(75432002)(236005)(16799955002)(53546009)(8936002)(88552002)(25786009)(122556002)(606005)(15188155005)(5660300001)(8676002)(66066001)(53936002)(3660700001)(54896002)(9686003)(6306002)(6246003)(19627405001)(4326008)(6116002)(3280700002)(102836003)(110136004)(38730400002)(7696004)(6506006)(77096006)(6436002)(3846002)(86362001)(99286003)(55016002)(54906002)(50986999)(54356999)(76176999)(7906003)(7736002)(81166006)(93886004)(74316002)(6916009)(33656002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR02MB2861; H:MWHPR02MB2861.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_" MIME-Version: 1.0 X-OriginatorOrg: stanford.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 02:02:35.3726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 396573cb-f378-4b68-9bc8-15755c0c51f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2861 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_01:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_01:, , 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-1704110015 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: Tue, 11 Apr 2017 02:02:51 -0000 --_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, Thanks for reading the paper! Yes, the signatures we use in our scheme are completely unrelated to the no= rmal operation of the log and only come into play in the event of log misbe= havior. Ordinary log behavior can continue to use standard signatures. The important property of the signatures we use in our scheme is the "proof= of knowledge of a signature." The idea is to use this proof to show that w= e have committed values that actually correspond to objects on the log. We = then use range proofs and other simpler zero knowledge proofs on commitment= s to show that they fulfill the relationships required to complete the proo= f. thanks and let me know if you have any more questions, ~saba ________________________________ From: George Tankersley Sent: Monday, April 10, 2017 4:34:37 PM To: Saba Eskandarian Cc: Ben Laurie; trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion Hey Saba, Read this paper with interest. Thanks for sharing! Am I correct that the range proof signatures are completely unrelated to no= rmal log operation? That is, the ordinary log behavior continue to use comm= only supported algorithms (RSA-PKCS1v15 or ECDSA) with only the intermediat= e range values being signed to admit proofs of signatures under commitment? On Wed, Apr 5, 2017 at 12:27 PM, Saba Eskandarian > wrote: 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 _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi George,


Thanks for reading the paper!


Yes, the signatures we use in our scheme are completely unrelated to the= normal operation of the log and only come into play in the event of log mi= sbehavior. Ordinary log behavior can continue to use standard signatures.


The important property of the signatures we use in our scheme is the &qu= ot;proof of knowledge of a signature." The idea is to use this proof t= o show that we have committed values that actually correspond to objects on= the log. We then use range proofs and other simpler zero knowledge proofs on commitments to show that they fulfill the= relationships required to complete the proof.


thanks and let me know if you have any more questions,

~saba

From: George Tankersley <= ;gtank@cloudflare.com>
Sent: Monday, April 10, 2017 4:34:37 PM
To: Saba Eskandarian
Cc: Ben Laurie; trans@ietf.org
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 
Hey Saba,

Read this paper with interest. Thanks for sharing!

Am I correct that the range proof signatures are completely unrelated = to normal log operation? That is, the ordinary log behavior continue to use= commonly supported algorithms (RSA-PKCS1v15 or ECDSA) with only the interm= ediate range values being signed to admit proofs of signatures under commitment?

On Wed, Apr 5, 2017 at 12:27 PM, Saba Eskandaria= n <sabae@stanford.= edu> wrote:
Since there wasn't time to present these privacy preserving proofs at th= e meeting last week, I thought it might be of interest to the list that I'l= l be presenting the idea at Stanford's annual security workshop next Monday. I believe it will be streamed on you= tube, and you may find the other presentations interesting as well (= http://forum.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@go= ogle.com>
Sent: Monday, March 27, 2017 2:48:11 AM

To: Saba Eskandarian
Cc: trans@ietf.o= rg
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@google.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




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


--_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_--