<br><br><div class="gmail_quote">On Wed Nov 19 2014 at 7:51:18 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"><br>
<br>
On 19.11.2014 17:33, Ben Laurie wrote:<br>
><br>
>     Q: What if the client clock is off?<br>
>     A: If the client thinks it is 1st of March, it downloads a hash, and<br>
>     stores its publication date as the 1st of March. Two days later, that<br>
>     hash is encountered in a certificate. The client thinks it is the 3rd of<br>
>     March, and thinks the certificate is valid till the 4th of March, so the<br>
>     certificate is allowed. What date it actually is is not relevant.<br>
><br>
> This is the one I meant ... so:<br>
><br>
> a) I'm not really sure I understand the protocol you are proposing here,<br>
> perhaps you could be a little more detailed?<br>
<br>
I am proposing certificates which can be proven not to be pre-issued.<br>
They could have issuance dates in them as well as the hash, I am just<br>
trying to save some bandwidth, to beat the original short-life proposal<br>
:) I just haven't managed to convince you that the issuance dates aren't<br>
actually needed yet.<br>
<br>
> b) It seems to rely on the client having some consistent offset from the<br>
> correct date ... to focus the difficultly a little more closely, let's<br>
> consider the case of a device that has just booted, has no memory from<br>
> previous runs, and sees a certificate of this new type: how does it<br>
> determine that the cert is currently valid?<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></blockquote><div><br></div><div>This is no better than saying that the client securely downloads the current time - which would not only solve the original problem, but a whole bunch of others.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Longer answer:<br>
What you are thinking of is how to bootstrap the dates. Note a few things:<br>
a) Logs can lie about timestamps of when certificates were logged<br></blockquote><div><br></div><div>I don't think so - they log the timestamp alongside the certificate.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b) Logs cannot lie about the order in which certificates were logged</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
c) The last entry in a log can be assumed to be the present time.<br></blockquote><div><br></div><div>Logs are not required to log in time order.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
d) The motivation for logs/MiTM would be to make old hashes appear as<br>
new, so an old certificate could still be used. Making new hashes appear<br>
old would make the client block certificates.<br>
<br>
Without a single timestamp, a log could claim all certificates were<br>
logged within the last 5 minutes, and thus all valid. If the client<br>
knows a single hash/timestamp combination, it could counter this by<br>
offsetting log timestamps.<br>
<br>
Example: The client knows that cert A was logged 10 days ago, and the<br>
log claims it was issued 5 minutes ago. The client will then shift all<br>
timestamps from the log by 10 days, and all the certificates will have<br>
expired.</blockquote><div><br></div><div>Actually, the effect is that they are not yet valid (the time at which they were issued has not yet been reached).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Note that the known hash/timestamp must be recent (=3 days<br>
old), in this example the log could claim that all certs before and<br>
including cert A were logged 10 days ago, and all certs since were<br>
logged 5 minutes ago, and thus present 9 day old certs as valid.<br></blockquote><div><br></div><div>This would require forking the log, and so would eventually be revealed by gossip.</div><div><br></div><div>But the problem is: suppose I (the attacker) don't care that all your other connections fail?</div><div><br></div><div>More seriously: if I am the victim of such an attack (not a log fork, but a rollback), how would I prove it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the case where such secure downloads are needed to bootstrap a<br>
device, a successful block of that download would achieve the same as a<br>
revocation check block today. It would be up to the client how to deal<br>
with such cases.<br>
<br>
--<br>
Sigbjørn Vik<br>
Opera Software<br>
</blockquote></div>