On Mon, May 22, 2017 at 6:38 PM, Linus Nordberg <[email protected]> wrote:
> Gary Belvin <[email protected]> wrote > Mon, 22 May 2017 15:16:24 +0000: > > >> return a different stream of bytes for the same ingoing parameters, for > SCTs > > and STHs. > > In addition to fixing signature randomization, wouldn't one also need to > > fix the inputs to the signature? Timestamps in particular and any server > > supplied data that wasn't directly tied to the leaves themselves would > seem > > to be a problem. > > Yes. My understanding is that they are all under control. > > For STH's: The log id is fixed. The number of timestamps, the tree size > and the root hash are limited by the STH frequency count. The extensions > field is unused. > (1) while the STH frequency is bound, a log is not required to produce STHs at that frequency - it can (and I suspect most operators will) issue STHs at a lower frequency. So it's still possible for the log to issue a few STHs which a few "select" clients will see - it all depends on the operational model of STH distribution / fetching. (2) while the extensions field is currently unused, clients are required to ignore any extension they do not understand, so a log may put arbitrary data there. > > For SCT's: The log id is fixed. Timestamps are limited by the visibility > in the log and the cost of storage forever. The extensions field is > unused. None of issuer key hash and (pre-) certificate in the > timestamped entry are server supplied. > The timestamp is chosen by the log, and a log may choose to create several entries, with different timestamps, for a single submission (useful if a log and server collude). Again, the usefulness of this for tracking a client depends on the SCT reporting/gossip model. My point is that even with fully deterministic signatures, it's very hard to defend against this vector of client fingerprinting, particularly in the face of unknown operational/threat model. Furthermore, there are other ways to track a client - even today, with 6962 and Expect-CT: A server may simply collect SCTs from multiple logs and serve a unique subset of SCTs to the client it wants to track, setting the Expect-CT header for reporting only. But a server that wants to track clients has many, many ways that are more straightforward. > > Please let us know if we're missing something. >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
