Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad

[Eran Messeri <[e-mail]>]

On Mon, May 22, 2017 at 6:38 PM, Linus Nordberg <[e-mail]> wrote:

> Gary Belvin <[e-mail]> 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.
>