[cabfpub] Pre-Ballot - Short-Life Certificates

[Ben Laurie]

On Wed Nov 19 2014 at 7:51:18 PM Sigbjørn Vik <sigbjorn at opera.com> wrote:

>
>
> On 19.11.2014 17:33, Ben Laurie wrote:
> >
> >     Q: What if the client clock is off?
> >     A: If the client thinks it is 1st of March, it downloads a hash, and
> >     stores its publication date as the 1st of March. Two days later, that
> >     hash is encountered in a certificate. The client thinks it is the
> 3rd of
> >     March, and thinks the certificate is valid till the 4th of March, so
> the
> >     certificate is allowed. What date it actually is is not relevant.
> >
> > This is the one I meant ... so:
> >
> > a) I'm not really sure I understand the protocol you are proposing here,
> > perhaps you could be a little more detailed?
>
> I am proposing certificates which can be proven not to be pre-issued.
> They could have issuance dates in them as well as the hash, I am just
> trying to save some bandwidth, to beat the original short-life proposal
> :) I just haven't managed to convince you that the issuance dates aren't
> actually needed yet.
>
> > b) It seems to rely on the client having some consistent offset from the
> > correct date ... to focus the difficultly a little more closely, let's
> > consider the case of a device that has just booted, has no memory from
> > previous runs, and sees a certificate of this new type: how does it
> > determine that the cert is currently valid?
>
> Short answer: The client needs to securely download a single recent
> hash/timestamp combination. Most likely this would be done from a vendor
> server. All vendors have a lot of servers that the clients routinely
> connect to anyway, and trust in the client implies trust in those
> servers. Most likely the client would download the entire list from a
> trusted server, but a single combination is all that is required.
>

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.


>
> Longer answer:
> What you are thinking of is how to bootstrap the dates. Note a few things:
> a) Logs can lie about timestamps of when certificates were logged
>

I don't think so - they log the timestamp alongside the certificate.


> b) Logs cannot lie about the order in which certificates were logged

c) The last entry in a log can be assumed to be the present time.
>

Logs are not required to log in time order.


> d) The motivation for logs/MiTM would be to make old hashes appear as
> new, so an old certificate could still be used. Making new hashes appear
> old would make the client block certificates.
>
> Without a single timestamp, a log could claim all certificates were
> logged within the last 5 minutes, and thus all valid. If the client
> knows a single hash/timestamp combination, it could counter this by
> offsetting log timestamps.
>
> Example: The client knows that cert A was logged 10 days ago, and the
> log claims it was issued 5 minutes ago. The client will then shift all
> timestamps from the log by 10 days, and all the certificates will have
> expired.


Actually, the effect is that they are not yet valid (the time at which they
were issued has not yet been reached).


> Note that the known hash/timestamp must be recent (=3 days
> old), in this example the log could claim that all certs before and
> including cert A were logged 10 days ago, and all certs since were
> logged 5 minutes ago, and thus present 9 day old certs as valid.
>

This would require forking the log, and so would eventually be revealed by
gossip.

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?


> In the case where such secure downloads are needed to bootstrap a
> device, a successful block of that download would achieve the same as a
> revocation check block today. It would be up to the client how to deal
> with such cases.
>
> --
> Sigbjørn Vik
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141119/b72615af/attachment.html