XO automatic clock setting

[Daniel Drake]

2009/8/31 C. Scott Ananian <cscott at laptop.org>:
> On Thu, Aug 27, 2009 at 7:30 AM, Daniel Drake<dsd at laptop.org> wrote:
>> The server will respond with: "time01: <TIMESTAMP> sig0x: xxx"
>
> I don't understand why this is necessary; there is already a 'time'
> field in the server response for this purpose:
>  http://wiki.laptop.org/go/Theft_deterrence_protocol#Theft-deterrent_server_response

This part was discussing and extending the port 191 protocol, not the
theft deterrence protocol. The port 191 client is in the initramfs,
and the theft deterrence protocol client is separated, on the rootfs
as part of olpc-update-query.

The port 191 protocol is currently as follows:
1. client opens connection, writes its own serial number to socket
2. server writes appropriate lease to socket
3. connections close

Now Martin's work extends that so that the client can send a time01
request on that socket.

>> Both sig01 and sig02 formats are accepted in the server response. One
>> important point is that the expiry date of any sig02 keys used in the
>> chain are *not* checked at all -- this is because we're assuming the
>> XO clock might not be accurate.
>
> Server time is trusted, because it is validated with a signature; the
> XO's local time should be updated if necessary, but validation should
> be done with the server's time to avoid races with another process
> updating the XO's clock.

Good point.

>> I would vote that time-publishing should be disabled by default on the
>> XS. However, in the case of the OATS protocol it is not an optional
>> field. Should we extend/amend the protocol?
>
> I'm not sure why you believe it should be disabled.  Hijacking an XS

2 reasons, neither related to attacks :

1. I've seen a lot of bad clocks in regular PCs, which jump around in
time. If you have one of these in your server, you're now likely to
kill all the XOs, even if they have good clocks.

2. The OATS server is not necessarily the same machine as the port 191
server. The machine that generated the leases is not necessarily the
XS, or the OATS server. We never used to rely on the XS having a
time-keeping and accurate clock (or at least one synced with the
contents of the leases), but this would change that. It might not be
totally unreasonable to ask for a good clock, but this is still
slightly tightening the requirements for deployments, which really
benefit from flexibility in the systems...


Sure, new features introduce new risk. And new features change the
trust model, as you describe.

The thing is, not all deployments will use these new features. And as
the code is right now, they will still be inversely affected by these
possible complications (which won't be overly common, but we're likely
to see a few) that are introduced even if they are not using the new
features.

Daniel