<br><br><div class="gmail_quote">On Mon Nov 24 2014 at 1:13:20 PM Sigbjørn Vik <<a href="mailto:sigbjorn@opera.com">sigbjorn@opera.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19-Nov-14 22:04, Ben Laurie wrote:<br>
><br>
> On Wed Nov 19 2014 at 7:51:18 PM Sigbjørn Vik <<a href="mailto:sigbjorn@opera.com" target="_blank">sigbjorn@opera.com</a><br>
> <mailto:<a href="mailto:sigbjorn@opera.com" target="_blank">sigbjorn@opera.com</a>>> wrote:<br>
><br>
>     Short answer: The client needs to securely download a single recent<br>
>     hash/timestamp combination. Most likely this would be done from a vendor<br>
>     server. All vendors have a lot of servers that the clients routinely<br>
>     connect to anyway, and trust in the client implies trust in those<br>
>     servers. Most likely the client would download the entire list from a<br>
>     trusted server, but a single combination is all that is required.<br>
><br>
> This is no better than saying that the client securely downloads the<br>
> current time - which would not only solve the original problem, but a<br>
> whole bunch of others.<br>
<br>
Downloading the current time and a three days old hash, is functionally<br>
equivalent to downloading a three days old hash along with its<br>
timestamp, agreed :)<br>
<br>
If you agree that this solves the original problem, then let's just<br>
conclude problem solved :) This is really a deep corner case of the<br>
original proposal, but I am glad we could resolve it anyhow. Snipping<br>
any further discussions about this.<br></blockquote><div><br></div><div>I don't agree its a deep corner case - its the core of the proposal's security.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[snip]<br>
<br>
> But the problem is: suppose I (the attacker) don't care that all your<br>
> other connections fail?<br>
><br>
> More seriously: if I am the victim of such an attack (not a log fork,<br>
> but a rollback), how would I prove it?<br>
<br>
If you are given a signed copy of a log by someone, and that signed copy<br>
doesn't match the actual log, then you have proof to incriminate the signer.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>I did think of a way (again involving a third party) but I'm not keen on it, because of load on the server: retrieve a signed timestamp from a third party, send a hash of it to the log server and ask for current head + hashed timestamp to be signed.</div><div><br></div><div>If the log lies, you can show the signed timestamp and the signed head + hashed timestamp. Then we get to argue about the honesty of the timestamp provider(s). :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Sigbjørn Vik<br>
Opera Software<br>
</blockquote></div>