[cabfpub] Pre-Ballot - Short-Life Certificates

Sigbjørn Vik sigbjorn at opera.com
Mon Nov 24 14:05:20 UTC 2014

On 24-Nov-14 14:39, Ben Laurie wrote:
> I don't agree its a deep corner case - its the core of the proposal's
> security.
> Also, I can't agree that this solves the problem - in practice, clients
> do not have the correct time, so we can;t conclude that they can have
> the correct log head either.

Clients either need three days run-time (with history), or need to
bootstrap themselves by getting the equivalent from somewhere. In
practice, clients will thus have what they need. The client does not
need to change the clock on the device to achieve this.

>     > But the problem is: suppose I (the attacker) don't care that all your
>     > other connections fail?
>     >
>     > More seriously: if I am the victim of such an attack (not a log fork,
>     > but a rollback), how would I prove it?
>     If you are given a signed copy of a log by someone, and that signed copy
>     doesn't match the actual log, then you have proof to incriminate the
>     signer.
> Not really - I show the signed copy and what I claim the actual log sent
> me, only I captured that a week ago. How have I proved anything?

The log includes timestamps. Are those timestamps correct?
E.g. "Hash ABCD1234 was signed on 2014-11-17 08:00". If you have a
signed log saying ABCD1234 was signed on the 17th, and I have a signed
log saying ABCD1234 was signed on the 24th, we know the signer is a liar
(if we gossip).

Sure, the log could send me a week-old response today, and I couldn't
prove to anyone that it sent me stale data. Old data doesn't enable
anything though (it is just useless), so isn't a security risk. Even if
the latency is a week (rfc 1149), we still cannot blame the signer for
any problems encountered in-flight.

Sigbjørn Vik
Opera Software

More information about the Public mailing list