Adam,
On Mon, Sep 28, 2015 at 12:19 PM Stephen Kent <[email protected]
<mailto:[email protected]>> wrote:
On Fri, 24 Jul 2015 at 16:28 Stephen Kent <[email protected]
<mailto:[email protected]>> 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.
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.
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
