[cabfpub] Pre-Ballot - Short-Life Certificates

Ben Laurie benl at google.com
Mon Nov 24 08:04:37 MST 2014


On Mon Nov 24 2014 at 2:05:23 PM Sigbjørn Vik <sigbjorn at opera.com> wrote:

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

Once more I am lost. Old data is useful if your clock is wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141124/cb695811/attachment.html 


More information about the Public mailing list