Subject: Re: [Trans] [trans] #95 (rfc6962-bis): The response size to get-entries should be a part of the log metadata

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Sep 2015 15:19:54 -0400

Ben,

> On Fri, 24 Jul 2015 at 16:28 Stephen Kent <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I am now convinced that the response size may have to vary
>     dynamically.
>     I suggest the log spec (aka 6962-bis) should mandate a minimum
>     size for
>     the get-entries query for all logs (to address privacy concerns).
>
>
> As I noted in response to the agenda writeup, I am not convinced by 
> this - the easy way to mitigate the privacy concern is for the client 
> to preselect the entries it wishes to fetch, and fetch all of them 
> regardless of reduced responses (through multiple requests, obviously).
This might impose a non-trivial burden on clients, but I'll defer to DKG 
on this
privacy issue.

Steve

---

From: Adam Eijdenberg <[email-masked]>
Date: Mon, 28 Sep 2015 22:52:46 +0000

On Mon, Sep 28, 2015 at 12:19 PM Stephen Kent <[email-masked]> wrote:

> On Fri, 24 Jul 2015 at 16:28 Stephen Kent < <[email-masked]>[email-masked]>
> wrote:
>
>> I am now convinced that the response size may have to vary dynamically.
>> I suggest the log spec (aka 6962-bis) should mandate a minimum size for
> As I noted in response to the agenda writeup, I am not convinced by this -
> the easy way to mitigate the privacy concern is for the client to preselect
> the entries it wishes to fetch, and fetch all of them regardless of reduced
> responses (through multiple requests, obviously).
>

I think it would be useful to describe the privacy concern that we're
trying to mitigate.  I remember being a bit puzzled by this when I saw this
thread in July.

That is, under what common circumstances do we think a client would want to
fetch a specific entry number, and want to hide (from the log) which entry
they are interested in? (or is it another scenario that I'm missing?)  The
scenarios that I know do cause privacy concerns are those that leak
browsing history to a log, but those don't seem to apply here since the
client already has the necessary data (certificate and SCT) for that entry,
and thus doesn't need to fetch it from a log.

> Steve
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Sep 2015 09:53:14 -0400

Adam,

>
> On Mon, Sep 28, 2015 at 12:19 PM Stephen Kent <[email-masked] 
>>     As I noted in response to the agenda writeup, I am not convinced
>>     by this - the easy way to mitigate the privacy concern is for the
>>     client to preselect the entries it wishes to fetch, and fetch all
>>     of them regardless of reduced responses (through multiple
>>     requests, obviously).
>     This might impose a non-trivial burden on clients, but I'll defer
>     to DKG on this
>     privacy issue.
>
>
> trying to mitigate.  I remember being a bit puzzled by this when I saw 
> this thread in July.
>
> That is, under what common circumstances do we think a client would 
> want to fetch a specific entry number, and want to hide (from the log) 
> which entry they are interested in? (or is it another scenario that 
> I'm missing?)  The scenarios that I know do cause privacy concerns are 
> those that leak browsing history to a log, but those don't seem to 
> apply here since the client already has the necessary data 
> (certificate and SCT) for that entry, and thus doesn't need to fetch 
> it from a log.
Perhaps I'm confused, but my concern was that a TLS client would fetch a 
specific log entry
to verify that the SCT it received corresponds to a real log entry. If 
so, then fetching this
specific entry would reveal to the log that the client was probably 
visiting the web site
on question, which would violate the privacy of the TLS client.

Steve

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 29 Sep 2015 10:59:58 -0400

On Tue 2015-09-29 09:53:14 -0400, Stephen Kent <[email-masked]> wrote:
> Perhaps I'm confused, but my concern was that a TLS client would fetch
> a specific log entry to verify that the SCT it received corresponds to
> a real log entry. If so, then fetching this specific entry would
> reveal to the log that the client was probably visiting the web site

Yes, this is the privacy concern i have in mind for this case as well.

     --dkg

---

From: Adam Eijdenberg <[email-masked]>
Date: Tue, 29 Sep 2015 16:02:07 +0000

> Yes, this is the privacy concern i have in mind for this case as well.

Thanks for clarifying.  If a client receives an SCT that they wish to
verify corresponds to a real log entry we expect them to use
/get-proof-by-hash - that returns an inclusion proof and a leaf index that
they can apply to the information that they already have in order to prove
that the certificate they see is incorporated into the signed tree head.
It isn't necessary to also call /get-entries for that leaf_index to verify
the server has the same data, as if that were not true, the inclusion proof
returned for /get-proof-by-hash (which is what actually supplies the
leaf_index) wouldn't compute correctly for the same STH.

I would agree that the same privacy concern exists for /get-proof-by-hash.
If called directly by the client to the log that would leak the clients
browsing habits.  For Chrome our current plan to mitigate this is as
follows:

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 recurse 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.

(Source: http://www.certificate-transparency.org/august-2015-newsletter)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Sep 2015 13:43:36 -0400

Adam,

> On Tue, Sep 29, 2015 at 8:00 AM Daniel Kahn Gillmor 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Tue 2015-09-29 09:53:14 -0400, Stephen Kent <[email-masked]
> /get-proof-by-hash - that returns an inclusion proof and a leaf index 
> that they can apply to the information that they already have in order 
> to prove that the certificate they see is incorporated into the signed 
> tree head.  It isn't necessary to also call /get-entries for that 
> leaf_index to verify the server has the same data, as if that were not 
> true, the inclusion proof returned for /get-proof-by-hash (which is 
> what actually supplies the leaf_index) wouldn't compute correctly for 
> the same STH.
thanks for the clarification. I'll make sure that the assumption about 
what log call
a TLS client makes is clearly stated in the arch doc.
>
> I would agree that the same privacy concern exists for 
> /get-proof-by-hash. If called directly by the client to the log that 
> would leak the clients browsing habits.  For Chrome our current plan 
> to mitigate this is as follows:
>
> 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 recurse 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.
Unless the use of a DNS servers in this fashion becomes a mandatory part 
of the CT architecture,
so that all log operators make use of it,  we can't assume that all logs
will adopt this privacy-preserving approach. Thus the attack/threat 
model will cite this
as a residual privacy issue for now.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 30 Sep 2015 11:38:51 +0000

On Tue, 29 Sep 2015 at 18:43 Stephen Kent <[email-masked]> wrote:

> will adopt this privacy-preserving approach. Thus the attack/threat model
> will cite this

One of the nice properties of CT is that anyone can mirror a log and still
retain the ability to prove correct operation, without access to the log's
private key.

Thus, we do not need to require log operators to support DNS in order to
take advantage of it. For example, we intend to provide DNS for all logs
Chrome trusts.

Not that this means you should not point out the potential problem, just
thought it was worth pointing out.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Sep 2015 10:00:23 -0400

Ben,

> One of the nice properties of CT is that anyone can mirror a log and 
> still retain the ability to prove correct operation, without access to 
> the log's private key.
sure, that's an obvious property of the Merkle tree design.
> Thus, we do not need to require log operators to support DNS in order 
> to take advantage of it. For example, we intend to provide DNS for all 
> logs Chrome trusts.
That's a subtly different statement from what I noted. It says that 
Google chooses
to provide this service for some set of logs, without those logs needing 
to do any
more work.
> Not that this means you should not point out the potential problem, 
> just thought it was worth pointing out.
We're in agreement on that point.

Steve